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.
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.
On GitHub Windows runners, trying to make build.yaml set PYTHON=python in the
environment doesn't work: integration tests still fail with "Access is denied"
because they're still trying to execute the interpreter's full pathname.
Instead, make llprocess_test and llleap_test detect the case of GitHub Windows
and override the environment variable PYTHON with a baked-in string constant
"python".
instead of a new value for each LLProcess::create() invocation.
Since the internal apr_log() function only looks at APR_LOG once per process,
the first test (which succeeded, hence no log file dump) left the log file
open with that same original pathname. Resetting the APR_LOG environment
variable for subsequent runs only made the new code in llprocess_test look for
files that were never created.
The claim is that the Windows Python interpreter is integrated somehow with
the OS such that a command line that tries to run Python with a script that
"looks suspicious" (i.e. in a system temp directory) fails with "Access
denied" without even loading the interpreter. At least that theory would
explain the "Access denied" errors we've been getting trying to run Python
scripts generated into the system temp directory by our integration tests.
Our hope is that generating such scripts into the GitHub RUNNER_TEMP directory
will work better.
As this test is specific to Windows, don't even bother running Mac builds.
Having observed installer upload failures, I discovered the warning in
actions/upload-artifact/README.md about multiple concurrent jobs trying to
post the same pathname to the same artifact name. Try to disambiguate
artifacts not only for different platforms, but for different jobs running on
the same platform.
This change also reflects my understanding that an artifact is (effectively) a
distinct zip file that can contain multiple uploaded files. Because we'll want
to download metadata without having to download enormous installers, create a
separate metadata artifact per platform. Similarly, symbol files can get large:
use a third distinct artifact for symbol files.
But with those artifacts defined, leverage actions/upload-artifact's ability
to upload multiple paths to the same artifact. In build.sh, define bash arrays
installer, metadata, symbolfile and set up so that, on exit, each is written
to a GITHUB_OUTPUT variable with the corresponding name. This involves a
little magic to get macOS bash 3 to indirectly access an array.
These multi-line output variables are then used to drive the upload-artifact
step for each of the defined artifacts.
and use them instead of codeticket addoutput to pass GitHub xxx_name, xxx_path
outputs to build.yaml.
Add upload steps to build.yaml to try to upload build products identified in
build.sh.
We suspect that autobuild incorrectly prioritizes AUTOBUILD_CONFIGURATION over
its command-line -c switch. The autobuild command to build the TPV package for
llphysicsextensions specifies -c Tpv (the configuration in the specified
config file), but with AUTOBUILD_CONFIGURATION=Release set, autobuild fails:
"ERROR: no configuration for build configuration 'Release' found"
That doesn't seem to be the distinction between TC builds and GH builds.
Instead, we'll try unsetting AUTOBUILD_CONFIGURATION.
This reverts commit d62e7039da.
Bug in autobuild 3.9.2? The TC viewer build can successfully build
llphysicsextensions/autobuild-tpv.xml, but the previous GH actions build
failed: "no configuration for Release found" despite -c Tpv. The difference
seems to be that we used 'pip3 install autobuild' from PyPI, whereas the TC
buildscripts setup clones secondlife/autobuild branch v3 and installs from
that repo.
The Python child processes used by llprocess_test.cpp and llleap_test.cpp need
the Python llsd module to communicate with the C++ parent process.
Also set LOGFAIL and BUGSPLAT_DB environment variables.
Cleanup build output to bring it under 2000 char limit for discord webhooks.
improve discord response reporting
requirements.txt updated to pickup latest versions, minimum set ready for PBR
need to fetch the script
Make script more tolerant of errors.
Fix extraction of build_type for GitHub layout
Need to ignore pre-existing folders
We have multiple artifacts that we are merging into a common tree.
despite the clash of folders the files are not going to clash.
revert the artifact collection to per platform.
Simplify 64/32 test to remove ReleaseType dependency
- make sure we use the latest bundles provided
- rearrange things a little.
- make some initial steps towards trying to make things fail when config/build fails.
Improve OS/SL config switch
always use latest package version (by timestamp)
try another method that deals with not found (looking at you linux havok)
oops
I hate shell bl@*&y scripts
fix pattern
revert the autobuild version
wth
this makes no sense
fs-variables must be imported after the code
add KDU from private repo
kdu is arch agnostic
modify for rclone
Add the fmodstudio
Switch to requirements.txt for python deps
workaround bad python in windows runner images.
Need to fetch full depth or we do not get our computed revision num
Try up to 10 times to detach HDI on Mac cos 5 was not always enough!
Fix bug on windows as side-effect of Mac cleanup doh
Nat Goodspeed