ci: add automatic tip (nightly) prerelease workflow#391
ci: add automatic tip (nightly) prerelease workflow#391scroix wants to merge 1 commit intomuseumsvictoria:devfrom
Conversation
|
I think this is going to be key in allowing organisations to test "dev" builds at their own leisure in controlled circumstances (temporary exhibitions, lab spaces, etc) without needing to build from source. |
There was a problem hiding this comment.
Pull request overview
Adds a GitHub Actions workflow to publish an always-up-to-date tip prerelease build from dev after CI passes, providing a downloadable jar without requiring local builds.
Changes:
- Introduces a new
Tip Releaseworkflow triggered by successfulBuild and Testruns ondev(and manual dispatch). - Builds and uploads the standalone
nodelhost-*.jar, then publishes/updates a prerelease namedtip. - Moves the
tiptag after a successful release update.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Delete old release assets | ||
| uses: actions/github-script@v7 | ||
| with: | ||
| script: | | ||
| const { data: release } = await github.rest.repos.getReleaseByTag({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| tag: "tip", | ||
| }).catch(() => ({ data: null })); | ||
| if (!release) return; | ||
| for (const asset of release.assets) { | ||
| await github.rest.repos.deleteReleaseAsset({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| asset_id: asset.id, | ||
| }); | ||
| } |
There was a problem hiding this comment.
Release assets are deleted before the new jar is uploaded. If the upload step fails (transient API error, rate limit, etc.), the tip release will be left without assets until the next successful run. Consider uploading the new asset first (or only deleting the specific previous jar asset after a successful upload) to avoid temporarily breaking the download link.
| (github.event_name == 'workflow_run' | ||
| && github.event.workflow_run.conclusion == 'success' | ||
| && github.event.workflow_run.head_branch == 'dev') | ||
| || github.event_name == 'workflow_dispatch' |
There was a problem hiding this comment.
workflow_dispatch runs are allowed unconditionally, which means a user can publish/move the tip release from any branch/commit. If tip is intended to always reflect dev, consider restricting manual dispatch runs to refs/heads/dev (or add an input SHA/branch and use it consistently for checkout/tagging/release notes).
| || github.event_name == 'workflow_dispatch' | |
| || (github.event_name == 'workflow_dispatch' | |
| && github.ref == 'refs/heads/dev') |
| name: Nodel Tip ("Nightly") | ||
| prerelease: true | ||
| body_path: release_notes.md | ||
| files: ${{ needs.build.outputs.jar_name }} | ||
| make_latest: false |
There was a problem hiding this comment.
softprops/action-gh-release is configured to upload ${{ needs.build.outputs.jar_name }}, but the downloaded artifact will typically preserve the original directory structure from the upload (e.g. nodel-jyhost/build/distributions/standalone/...). This can cause the release step to fail to find the file. Consider outputting the jar path from the build job and using that here, or copying/renaming the jar to a known flat location before uploading/downloading so files: points at an existing path.
| if: >- | ||
| (github.event_name == 'workflow_run' | ||
| && github.event.workflow_run.conclusion == 'success' | ||
| && github.event.workflow_run.head_branch == 'dev') | ||
| || github.event_name == 'workflow_dispatch' | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
Because this is triggered by workflow_run, successful runs can complete out of order (an older commit’s CI run may finish after a newer one). In that case this workflow can move the tip tag backwards. To keep the tag always-current, add a guard before releasing/tagging that verifies the triggering SHA is still the HEAD of dev (e.g., fetch origin/dev and compare), and exit early if it isn’t.
| cache: gradle | ||
|
|
There was a problem hiding this comment.
This workflow uses actions/setup-java’s cache: gradle, but the repo’s main CI workflow standardizes on gradle/actions/setup-gradle@v4 for Gradle setup/caching (see .github/workflows/build.yml). For consistency and to match the existing CI behavior, consider using the same setup-gradle action here (and drop the cache: setting).
| cache: gradle | |
| - name: Setup Gradle | |
| uses: gradle/actions/setup-gradle@v4 |
Adds an always-current "tip" prerelease that rebuilds on every green push to
dev— so there's always a downloadable jar for anyone who wants to test the latest without building from source.The workflow chains three jobs (build → release → tag) so the release only publishes after a successful build, and the tag only moves after a successful release. Old assets are cleaned up before uploading, so the release page stays tidy.
Also supports
workflow_dispatchfor manual re-runs.Inspired by Ghostty's tip release.