Public artifacts per commit?

[remexre]

It'd make Advancing The Nix Agenda much easier (and pinning to specific non-release versions, relatedly and probably more importantly) if we put build artifacts somewhere public after every commit. Options I can think of right now:

1. foundry -- We have plenty of space here (after shrinking a 64GB swap file that exists for... reasons I don't recall), major downside would be pointing scripts at a machine with a hostname that's not MELT-associated (though, silver-lang.org is $10/yr, and it could become infra.silver-lang.org or something). Manually specifying JARs to use could still be done the existing way (/export/scratch).
2. GitHub Releases -- We could start creating per-commit releases, e.g. v0.4.5-pre-322522f for 322522f, and have Jenkins use the JARs from the current commit if they exist (so people can manually upload JARs when necessary, and Jenkins will replace them after rebuilding).
3. Existing Website, "just know the path" -- This'd require a minor tweak to the Jenkins config to write what commit the build is for to custom-stable-dump, and a more major change to cron-job-publish-jars-from-foundry.py; instead of downloading new JARs to /web/research/melt.cs.umn.edu/downloads/silver-dev/jars, it'd download them to .../jars/$COMMIT_HASH, then symlink them to .../jars or .../jars/latest.
4. Existing Website, Fancy -- We could do the above, but have coldpress generate the website locally, and generate a nice-looking index page for seeing all the builds. Probably not worth the work, but might look nice, dunno.

[krame505]

A while back we talked about setting up Jenkins to automatically create monthly releases on Github (which has the ability to host release artifacts), but this never got done. I wouldn't be opposed to more permanently storing per-commit jars somewhere, though.

What are you thinking in terms of per-commit releases - would this include branches? How exactly would that work?

[remexre]

I think every commit Jenkins has built; I'd at least want every branch-tip of branches other than develop and master, and ideally every commit to those two. I think if we have pre or dev or something in the release name, it shouldn't be too non-obvious that the "release" is not final and possibly-not-of-release-quality, and if we put the hash in the name there shouldn't be conflicts.

I'd like per-commit more than monthly; my end-goal here is that a script that doesn't have Jenkins creds can build/fetch a working version of any commit of Silver that Jenkins was able to build.

[remexre]

melt-umn/jenkins-lib#19 is probably the only blocker to this being marked as resolved, I think?