I’m looking at a way to build Elm code on a CI machine that has no Internet access. I can hit an Artifactory machine that can proxy an upstream repository but Artifactory doesn’t understand Elm packages yet.
Anyone else facing the same issue?
2 Likes
I’ve had this problem when trying to develop on long airplane flights.
On the Slack in #beginners @aparent gave this advice:
You CAN compile without access to the internet, but you won’t be able to fetch dependencies if you don’t have access to the internet. To be able to do that, though, you can use
elm-github-install(Which can be installed through npm), and it will keep a cache of all packages you install with it, which will allow you to use and fetch those packages even if your PC goes offline, as long as you already installed them before while your PC was online.
Hope that helps!
Can you give some more details about the scenario? If it can hit an Artifactory machine, it sounds like it has some Internet access, right? 
Is it that everything is firewalled except for a specific list of allowed hosts?
The Artifactory machine itself has access outside of the firewalled corporate environment to a list of whitelisted upstream repos which it will proxy-cache. However Artifactory doesn’t know Elm so it can’t emulate the Elm repository.
The CI always starts from scratch. It can get npm packages from artifactory (which can be fetched from the Internet if required).
Is it that everything is firewalled except for a specific list of allowed hosts?
Everything is firewalled except for specific hosts but only on the artifactory machine.
Can I ask Artifactory to treat http://package.elm-lang.org/ as a dumb HTTP site to mirror or is there a more complex protocol at work for communicating with the client. And if so, how would I tell the client that it has to hit there to fetch packages?
I have the same problem. Our CI does not have access to the Internet so I need to manually log in every time I need internet access. I ended up putting all packages in elm-stuff under version control. This works mostly ok but makes installing new packages a tad more complicated. Also, be wary of version bumps: elm will automatically upgrade the minor version in the yaml file as soon as it’s connected to the internet.
1 Like
I’ve faced a similar problem when building my project with a tool called Nix, which is designed to ensure “pure” builds by requiring all internet-fetched dependencies to be declared and managed explicitly.
If you take a look at my elm-package.json and the corresponding elm-srcs.nix, you can see that each dependency’s exact URL and checksum are declared. (These are plain https URLs that could presumably be cached for you by artifactory.)
These artifacts are fetched by nix, then the elm-stuff directory is created from them: elm-stuff/exact-dependencies.json is constructed here and then the elm-stuff/packages/ subdir is populated here.
The elm2nix project automates the derivation of default.nix and elm-srcs.nix from your elm-package.json.
This obviously requires some reverse-engineering of elm-stuff, so it’s definitely not robust across releases of Elm. (Indeed, from what I’ve heard of 0.19 I’d say it’s pretty much guaranteed to stop working in that release. 
) However, elm2nix is built on top of elm-package, and I’ve found it useful enough over the past several months to make the tradeoff of future breakage worthwhile.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.