Build a draft release and then publish once complete #432
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
huonw
force-pushed
the
huonw/draft-release
branch
from
e2818c0 to
9e1534d
Compare
huonw
force-pushed
the
huonw/draft-release
branch
from
9e1534d to
7c5ca6e
Compare
huonw
force-pushed
the
huonw/draft-release
branch
from
7c5ca6e to
4516404
Compare
.github/workflows/release.yml
Outdated
|
|
||
| # Build up a draft release with the artifacts from each of these jobs: | ||
| - name: Create ${{ needs.determine-tag.outputs.release-tag }} Release | ||
| uses: softprops/action-gh-release@v1 |
There was a problem hiding this comment.
We use softprops/action-gh-release@v2 below, why @v1 here?
There was a problem hiding this comment.
Ooos, merge skew: I started working on this before bumping the actions. Thanks
| @@ -94,14 +94,37 @@ jobs: | |||
| ' | |||
| cargo run -p package -- --dest-dir dist/ scie \ | |||
| --scie-pants dist/scie-pants --tools-pex dist/tools.pex | |||
|
|
|||
| # Build up a draft release with the artifacts from each of these jobs: | |||
There was a problem hiding this comment.
If I'm reading correctly, this is a step in a matrixed job, so how do we not create this draft release multiple times? Is this action idempotent?
There was a problem hiding this comment.
Yes, it is idempotent.
As additional assurance it'll likely work as we hope: the old approach was doing the same thing of "creating" the release concurrently/multiple times, just not as a draft.
|
I tagged a v0.12.3-beta.0 to test. It needs The build was https://github.com/pantsbuild/scie-pants/actions/runs/12226797242 While that was running, there was a draft release: 🎉
... but then the publish and announce step created a whole new release: ❌
and the changelog is bad too. See #439 for my attempted fixes |
…og (#439) As observed in #432 (comment), after #432, release CI has two problems: - It creates two releases, one as a draft that the artifacts are uploaded too, and then one that's published. I'm guessing this is because the `name` key wasn't set on the draft uploads - The release notes couldn't be created, because the repo and its code (particularly `CHANGES.md`) wasn't available in the publishing step
Instead of publishing partial releases (even for a few minutes) as the matrix of builds adds their artefacts, create a draft release that we then publish in once the build has finished.
Background: the build process involves some set-up, then a matrix of building for different platforms, then some finalisation. This change is moving the "publish the release" from the matrix jobs to the finalisation job.
This has a few benefits:
get-pants.sh, and so running that on the broken platform will fail. (Example: Release CI fails to trigger CircleCI linux aarch64 build #430.)