Conversation
|
|
||
| env: | ||
| CARGO_TERM_COLOR: always | ||
| # if changed, dont forget to update the env var in release-nightly.yml |
There was a problem hiding this comment.
In theory the nightly release should just have different commit inputs right? Then no actual build logic needs to be duplicated. I see a lot of duplicated code in release-nightly.yml - for maintainability I'd appreciate making release.yml more modular (maybe as it's own GH actions or even a couple ones). WDYT?
There was a problem hiding this comment.
In theory the nightly release should just have different commit inputs right?
In theory, yes, and the build jobs are the same, but the logic for working with artifacts differs. I tried to keep everything in one pipeline. However, there were too many rules about whether a job or step should run, which made the pipeline definition difficult to read.
We could merge this one so it starts producing nightly builds and do the refactor later. WDYT?
There was a problem hiding this comment.
Maybe the rules could be modularized too?
I am fine with merging it to simplify trying it out - if you promise to improve it afterwards :)
There was a problem hiding this comment.
AFAIK no, it's not applicable to the rules. I'll create a separate issue then for the refactor.
PR adds a nightly release pipeline.
Since the logic for the nightly build and release differs significantly from the usual pipeline, I decided to put it in a separate file. The same applies to the Python script that generates JSON files.
The nightly pipeline runs at 01:00 UTC every day, producing artefacts and retaining them for 40 days if commits are made the day before it runs.
cc #355
cc https://github.com/paritytech/devops/issues/4141