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.
for Mac and Windows. That's now done by subsequent jobs in the GitHub build.
Remove workflow step to upload installers before signing and packaging jobs.
Remove from viewer_manifest.py conditionals for 32-bit Windows or Mac.
Also bump to actions/checkout@v4, per dependabot.
"ASC Provider" was a credential accepted by altool, but switching from altool
to notarytool requires a Team ID instead.
Expect to find TEAM_ID in our repository secret NOTARIZE_CREDS_MACOS. Extract
it and pass it to sign-pkg-mac.
Add a Mac signing step to unpack the credentials bundled into
NOTARIZE_CREDS_MACOS so viewer-build-util/sign-pkg-mac need not know about
that peculiarity of our secrets formatting.
The viewer_manifest.py logic to determine the name of the viewer installer
.dmg is a little convoluted. Make it tell viewer-build-util/sign-pkg-mac that
name, rather than passing it all the relevant inputs and composing it
redundantly.
sign-pkg-mac also wants the viewer channel to determine the application name.
instead of trying to checkout viewer-build-util (which doesn't work) and then
reference action subdirs from the filesystem.
Also engage (initial placeholder) actions to sign and package the
platform-specific application artifacts.
In a Windows build tree, we don't actually have an app-named top directory, so
don't package its containing directory -- just the app dir itself, e.g.
"newview/Release".
In a Mac build tree, though we do have "Second Life Mumble.app", its parent
directory also contains other large stuff. Try posting a temp directory
containing a symlink to the .app.
Ditch the "!*.bat" exclusion: the presence of a second path (even an
exclusion) changes how upload-artifact nests its contents.
Previously we posted Windows-exe, macOS-exe artifacts that were a little
inconsistent: Windows-exe contained just the Windows executable, whereas
macOS-exe contained the whole .app tree (but without the .app directory).
Change to post Windows-app, macOS-app artifacts that each contain the whole
viewer install image, including the top-level application name directory. This
is what we'll need to codesign and notarize.
The initial viewer-post-bugsplat-mac is just a placeholder so far, but we can
flesh it out while the viewer builds necessitated by this change are running,
and then we can iterate on viewer-post-bugsplat-mac without having to rebuild
the viewer.
Upload a new Windows-exe artifact containing just the executable (needed by
BugSplat) separately from the artifact containing the whole NSIS installer.
This requires a new viewer_exe step output set by viewer_manifest.py.
Define viewer_channel and viewer_version as build job outputs.
Set viewer_channel in build.yaml when tag is interpreted.
Set viewer_version in build.sh at the point when it would have posted
viewer_version.txt to codeticket.
Add a post-windows-symbols job dependent on the build job that engages
secondlife/viewer-post-bugsplat-windows, which in turn engages
secondlife/post-bugsplat-windows. We keep the actual upload code in a separate
repo in case we need to modify that code before rerunning to resolve upload
errors. If we kept the upload code in the viewer repo itself, rerunning the
upload with modifications would necessarily require rerunning the viewer
build, which would defeat the purpose of SL-19243.
Because of that new upload job in build.yaml, skip Windows symbol uploads
in build.sh.
Use a simple (platform name) artifact name for metadata because of
flatten_files.py's filename collision resolution.
Use hyphens, not spaces, in remaining artifact names: apparently
download-artifact doesn't much like artifacts with spaces in their names.
Only run the release job when in fact there's a tag. Without that, we get
errors. We need not create flatten_files.py's output directory beforehand
because it will do that implicitly.
in release job to reference outputs from the build job.
Also mark the release as prerelease, and fail the release action if we still
can't find the files we're trying to post.
This clarifies that the matrix.include entry is intended to supplement an
existing runner configuration, rather than adding a new configuration for the
same runner.
but only when building viewer-private.
Also re-fix SL-19942 workaround by deleting AUTOBUILD_CONFIGURATION before
trying to build llphysicsextensions-tpv.
Signal Linden