-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: create nightly builds #369
Conversation
This doesn't handle any specific publishing logic for nightlies. I haven't tested but I expect that one nightly build for each day will be published. How do we want to handle clean up of old nightlies? What is the best mechanism for keeping track of how many nightlies have been built so we can restrict to a given number, e.g. 7. |
Number of nightlies per package can be calculated by I imagine dropping of the oldest nightlies over the limit could happen in |
No, since I think the simplest place to do it is in
|
this tests build without any new releases
This is a small refactor that makes sure we only add meaningful files to ./releases dir (it is important for signing etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ensures that "nightly-2020-01-01" won't have any commits that happened on "2020-01-02" – enabling us to build historical nightlies.
this makes nightly do exactly what release build does, but allows us to tweak some behaviors, for example do pins that expires after 7 days, or report each preview separately
This runs cleanup only when we have anything to clean up
ae80100
to
db09ba3
Compare
db09ba3
to
843feda
Compare
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ready for review.
.github/workflows/nightly.yml
Outdated
on: | ||
push: | ||
## Allow manual invocation | ||
#workflow_dispatch: | ||
#schedule: | ||
# - cron: '0 5 * * *' # UTC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ we will remove push
and restore schedule
for cron trigger + workflow_dispatch
for running nightly builds on-demand
- run: cd ./dists/${{ matrix.dist_name }} && make nightly | ||
- run: ./dockerized make publish | ||
- name: Create issue if build failed | ||
uses: actions/github-script@v4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ Third-party turn-key solutions exists, but I decided to give actions/github-script
a try. It is an official action provided by GitHub, provides JS porcelain for running arbitrary API calls.
Debugging is a bit painful, but being written in JS could make it more dev friendly than bash+curl, allowing more people to maintain/extend. actions/github-script
is extremely powerful, only caveat is that it needs a personal access token to do anything outside the current repo.
We may leverage it even more for developer flow automation tailored to our needs. For example, it could automatically create/label issues and add them to specific column in specific project.
env: | ||
PIN_CID: ${{ steps.cid-reader.outputs.CID }} | ||
PIN_NAME: "ipfs/distributions/nightly/${{ matrix.dist_name }}" | ||
PIN_ADD_EXTRA_ARGS: "--expire-in 168h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ this pins nightly artifacts only for a week
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
One small idea is to consider the comments you left in the PR to inline them into the code for discoverability.
Closes #363
High level summary
./dists
nightly.yml
workflow is built on top of modernizedmain.yml
(feat: macos signing and notarization #367) and runs the same builds scriptsBuild scripts changes
./dist.sh add-version <dist> nightly
will add a nightly version to the versions file using the current date (@lidel is this still useful?)make nightly
add a nightly version to every dist versions file using the current datecd dists/<package> && make nightly
to add it only to specific package - we use it on CI to run builds in paralllel (@lidel)make dist
will build nightly versions by checking out the latest version of the default branch and producing a build artifact named using the patternnightly-yyyy-mm-dd-hash
where hash is the starting 7 (at least) characters of the commit hash. It may be more than 7 if a shorter length would be ambiguous.make all_dists
is unchanged but will build a nightly version in the course of runningmake dist
abovenightly-yyyy-mm-dd
version will be committed to the repo. It's an ephemeral version that is generated to produce a nightly build.versions
file is normally added to ipfs mymake publish
. This will now include the most recent nightly version. This allows the build system to ignore it on subsequent runs until a new day is reached.TODO
nightly-*
versions using existingmake publish
pipeline (@iand)./nightly
(@lidel)TODO: explore checking out the last commit in the default branch before arbitrary date:
git rev-list -1 --first-parent --before="2021-07-27" "$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')"
– makes nightlies more deterministic (at the revision level)fs-repo-migrations/fs-repo-0-to-1
) (@lidel)main.yml
(@lidel)main.yml