@Sridhar Ratnakumar I was thinking that the build instructions of nix-env -if https://github.com/srid/neuron/archive/master.tar.gz is kind of fragile, primarily for two reasons:
If the current CI is not finished yet, it will needlessly build locally, instead of using the prebuilt binaries. (race condition)
If the current master is broken for some reason, it will try and fail to install that version.
I know that pinning is one option, but that is kind of annoying and requires manual updating.
As an alternative, I'm thinking that we could make a branch that automatically updates whenever CI on master successfully builds (or use a dev branch that automatically pushes to master on successful builds).
I guess we don't really need it. It was mostly a neat feature in the name of reliability. The PRs only approach would certainly work, but might be more tedious sometimes and I was hoping that automatic merging on successful build could be a nice "set up once and then forget" feature that could save work in the long run.
I think I have once run into problem number one, so it's not a purely hypothetical issue. The only question is if it is worth the effort.
I'm also thinking of this from the perspective of "What would be a good setup for nix projects in general?" and if something like this would be worth adding to Github nix templates.
Looks like you are pulling directly from master? Pinning would avoid these troubles. Tools like niv will make it easier to update periodically the pinned rev.
@Sridhar Ratnakumar I was thinking that the build instructions of
nix-env -if https://github.com/srid/neuron/archive/master.tar.gzis kind of fragile, primarily for two reasons:I know that pinning is one option, but that is kind of annoying and requires manual updating.
As an alternative, I'm thinking that we could make a branch that automatically updates whenever CI on master successfully builds (or use a dev branch that automatically pushes to master on successful builds).
Do you think that makes sense?
Yes, but do we really need to do this though?
masterenters broken state very rarely.Incidentally, the install page now links to static binary: https://neuron.zettel.page/install.html
I could make a rule so that master never gets (code) commits without a PR. So we can wait for the PR CI to pass before merging it.
This way the cache gets uploaded during the PR CI, and when the
masterCI runs no new build actually happens.I guess we don't really need it. It was mostly a neat feature in the name of reliability. The PRs only approach would certainly work, but might be more tedious sometimes and I was hoping that automatic merging on successful build could be a nice "set up once and then forget" feature that could save work in the long run.
I think I have once run into problem number one, so it's not a purely hypothetical issue. The only question is if it is worth the effort.
I'm also thinking of this from the perspective of "What would be a good setup for nix projects in general?" and if something like this would be worth adding to Github nix templates.
Are you not using the static bundle in CI? https://github.com/srid/neuron-template/blob/fa6e87b02d1bdacd6d16748806d5b387729ec056/.github/workflows/publish.yaml#L14-L16
If CI is still running on the
HEADrev, then this curl command will just get the last available bundle. There is no compilation involved.I'm not thinking of CI. I'm on mac, so the static bundle is not available here.
But yes, the static bundle for CI is really neat!
Looks like you are pulling directly from
master? Pinning would avoid these troubles. Tools likenivwill make it easier to update periodically the pinned rev.