I am seeing the following stack trace in my ci/cd pipeline when installing elm packages.
2:08:33 PM: Starting downloads...
2:08:33 PM: ✗ Skinney/murmur3 2.0.8
2:08:33 PM: ● elm/random 1.0.0
2:08:33 PM: ● elm/regex 1.0.0
2:08:33 PM: ● elm/time 1.0.0
2:08:33 PM: ● elm/html 1.0.0
2:08:33 PM: ● elm/parser 1.1.0
2:08:33 PM: ● truqu/elm-base64 2.0.4
2:08:33 PM: ● elm/browser 1.0.2
2:08:33 PM: ● elm/virtual-dom 1.0.2
2:08:33 PM: ● elm/bytes 1.0.8
2:08:33 PM: ● elm/url 1.0.0
2:08:33 PM: ● rtfeldman/elm-hex 1.0.0
2:08:33 PM: ● elm/svg 1.0.1
2:08:33 PM: ● elm/http 2.0.0
2:08:33 PM: ● elm/json 1.1.3
2:08:33 PM: ● elm/core 1.0.5
2:08:33 PM: ● elm/file 1.0.5
2:08:33 PM: ● elm-explorations/test 1.2.2
2:08:33 PM: ● pablohirafuji/elm-syntax-highlight 3.3.0
2:08:33 PM: ● rtfeldman/elm-css 16.0.1
2:08:33 PM: Verifying dependencies (19/20)
2:08:33 PM: Verifying dependencies (20/20)-- CORRUPT PACKAGE DATA --------------------------------------------------------
2:08:33 PM: I downloaded the source code for Skinney/murmur3 2.0.8 from:
2:08:34 PM: Failed during stage 'building site': Build script returned non-zero exit code: 1
2:08:33 PM: https://github.com/Skinney/murmur3/zipball/2.0.8/
2:08:33 PM: But it looks like the hash of the archive has changed since publication:
2:08:33 PM: Expected: 81a0bada79740ae806df04b1bb14a7d64f763ac5
2:08:33 PM: Actual: 931398ec656078e26b2e29520cd283ffe6e8e441
2:08:33 PM: This usually means that the package author moved the version tag, so report it
2:08:33 PM: to them and see if that is the issue. Folks on Elm slack can probably help as
2:08:33 PM: well.
Is anyone else running into this?
I believe the root issue is a user name change on GitHub, from
robinheghan, which ends up changing the hashes for releases.
I sent some chats to @robin.heggelund of possible paths and how I can help if needed, but in the meantime, you can get your CI unstuck by placing the following directory on it:
You should have this on your local development system.
Zip it up, and add a temporary line before you run any Elm stuff to place this directory on the CI machine.
CI Note: I very highly highly highly encourage people with CI to cache your
~/.elm directory from build to build. This will make you immune to DNS issues, GitHub downtime, or things like this scenario! That directory just contains (1) static files that have been downloaded and (2) the build artifacts they produce deterministically. The one thing that can go wrong is acquiring the files over HTTP!
Hashing Note: The current design for hashing was chosen under the assumption that hashes of GitHub zip files would be based strictly on the content of the files, but it appears that incidental information about how GitHub hosts things also makes its way into these hashes. It is stable in general, but certain things can knock it out of whack. So I’d like to switch how hashes are generated to an approach that takes longer, but cannot be tripped up by these details. This is an infrastructure that’s much larger than it sounds, but it is highest priority for any package work.
It looks like there’s some discussion of work arounds on Slack as well. I’m copying the content of this message from turbo_mack (with some edits for weird formatting issues)
Some of you who depend on great work of @Robin might experience some issues due to package.elm not liking the fact he changed his name on Github. While this issue is being resolved you can use this workaround to make CircleCI pass:
# within home
$ cd $HOME
# create tarball of ~/.elm
$ tar -czvf elm-cache.tar.gz .elm
# copy tarball to project
$ cp elm-cache.tar.gz my-project/directory
# commit tarball
in our case we use circle-ci but it should be easy to port
name: patch cache
tar -xzf elm-cache.tar.gz
mv -f .elm $HOME/.elm
The important parts are these two commands:
tar -czvf elm-cache.tar.gz ~/.elm # create tarball
tar -xzf elm-cache.tar.gz # unpack taraball
Any CI system could probably make a work around with some form of these commands.
It appears that Robin has republished the packages under the new name, so it should now be possible to swap
robinheghan/murmur3 in your
elm.json as well.
For transparency, this was the fix for me:
Which included elm-css’s change.
murmur3 was an indirect dependency via elm-css. I had to manually update my elm.json to remove the stale reference to murmur3.
Ouch. I saw Robin’s PSA about the name change, but I didn’t consider that his projects could be indirect dependencies. Luckiy elm.json is flexible enough to make those deps into proper deps, at least temporarily.
Totally subjective, but it seems, like we currently get this every week. I think I saw three people mention in slack, that they renamed themselves on github, not sure why that’s so popular right now.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.