This should (!) allow us to generate full release notes relative to the
previous viewer release, instead of letting action-gh-release guess
incorrectly.
Also try again to add to the release page a back-link to the specific build.
(cherry picked from commit 88ebb92f05)
Using github.ref as action-gh-release's target_commitish produces:
⚠️ GitHub release failed with status: 422
[{"resource":"Release","code":"invalid","field":"target_commitish"}]
(cherry picked from commit c6a6db8488)
in viewer's autobuild-package.xml.
Ensure that AUTOBUILD_VCS_BRANCH is set before the build.
(cherry picked from commit b782ab73e6)
(cherry picked from commit 6e8d4f4846)
The release job has been dependent on sign-and-package-windows and
sign-and-package-mac, each of which depends on build. But that indirect
dependency doesn't convey access to ${{ needs.build.outputs.xxx }}. Add the
build job to direct dependencies so release can access its outputs.
(cherry picked from commit 819604d2ce)
For a tag build that generates a release page, try to deduce the git branch to
which the tag we're building corresponds and add that to release notes.
(cherry picked from commit 9e99bb04a3)
This should (!) allow us to generate full release notes relative to the
previous viewer release, instead of letting action-gh-release guess
incorrectly.
Also try again to add to the release page a back-link to the specific build.
Using github.ref as action-gh-release's target_commitish produces:
⚠️ GitHub release failed with status: 422
[{"resource":"Release","code":"invalid","field":"target_commitish"}]
We're currently building every single commit pushed to Github. This is
racking up $20k in build charges a month and is generally superfluous.
This changeset alters build triggers so that builds automatically run if
they are committed to a **shared branch**:
- `release/*` - A release stabilization branch
- `project/*` - A project viewer branch
- `main/*` - The default/stable branch
PR commits are also automatically built.
...need to build another commit? Developers can trigger one using a
manual workflow run.
The fix we wanted was on the pr-branch branch of the viewer-build-util repo.
Now that it's been published as v1.1.2, the updated v1 tag references the fix,
so revert mention to @v1.
Switch the build workflow from targeting the `main` branch of
viewer-build-util (which may receive breaking changes) to the stable
`v1` major version tag.
Only download and publish installers on public releases. This simplifies
the release process, as the flatten_files utility from
viewer-build-utils is not necessary this way. More importantly, it
doesn't clutter public releases with files that shouldn't be published
such as debug symbols.
The release job has been dependent on sign-and-package-windows and
sign-and-package-mac, each of which depends on build. But that indirect
dependency doesn't convey access to ${{ needs.build.outputs.xxx }}. Add the
build job to direct dependencies so release can access its outputs.
Bennett Goble