| Age | Commit message (Collapse) | Author |
|---|
|
This is referenced after running the packaging.
|
|
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.
|
|
We were creating the tarball with the app bundle stored as the whole
'Users/someone/.../newview/Release/Second Life Mumble.app' path. Don't.
|
|
|
|
actions/upload-artifact doesn't preserve symlinks, which are important for our
Mac viewer and its embedded frameworks. But tar does, so pack up the whole
bundle as a tarball before posting as a GitHub artifact.
|
|
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.
|
|
|
|
If they do, NSIS takes it as line continuation.
|
|
|
|
That is, make LLManifest.run_command() accept and forward subprocess keyword
arguments.
|
|
|
|
|
|
|
|
Since we need to run NSIS in a separate job step, allow the Windows-app build
artifact to include the temporary .nsi file prepared by filling in our
template.
Also tweak the logic that finds and runs NSIS.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Move hexdump() and hexmix() stream formatters to new hexdump.h for potential
use by other tests.
In toPythonUsing() helper function, add a temp file to receive Python script
debug output, and direct debug output to that file. On test failure, dump the
contents of that file to the log.
Give NamedTempFile::peep() an optional target std::ostream; refactor
implementation as peep_via() that accepts a callable to process each text
line. Add operator<<() to stream the contents of a NamedTempFile object to
ostream -- but don't use that with LL_DEBUGS(), as it flattens the file
contents into a single log line. Instead add peep_log(), which streams each
individual text line to LL_DEBUGS().
|
|
(cherry picked from commit fd73b6e5cf6341d606628646b73a0d05223b74bc)
|
|
This reverts commit 6cb906c44908a304af26e3ea95de88ff34ef46f7.
|
|
This reverts commit 46bd102e80178abb094b5dac6fe9c476e044eaed.
|
|
|
|
LLAudioEngine added a new abstract virtual method that wasn't yet implemented
for LLStreamingAudio_OpenAL.
|
|
|
|
|
|
|
|
|
|
|
|
in the path passed as the macOS viewer_exe GitHub output.
|
|
On Mac, in the CMake USE_BUGSPLAT logic, we created both xcarchive.zip (which
is what BugSplat wants to see) and secondlife-symbols-darwin -64.tar.bz2 (which
we don't think is used for anything). The tarball was posted to codeticket --
but why? If the point is to manually re-upload to BugSplat in case of failure,
we'll do better saving xcarchive.zip to codeticket.
For SL-19243, posting xcarchive.zip directly supports the goal of breaking out
the upload to BugSplat as a separate step.
Anyway, since xcarchive.zip is a superset of the tarball, the tarball can be
recreated from the zip file, whereas the zip file can't be recreated from the
tarball without opening the .dmg installer and extracting the viewer executable.
If the xcarchive.zip file exists (that is, on Mac), post that to codeticket or
GitHub, as applicable, instead of the tarball. In fact, in the USE_BUGSPLAT
case, don't even bother creating the tarball since we're going to ignore it.
Make the new build.sh logic that insists on BUGSPLAT_USER and BUGSPLAT_PASS
conditional on BUGSPLAT_DB.
|
|
|
|
|
|
Use a retry loop very like the code-signing retry loop.
|
|
A test executable on a GitHub Windows runner failed with C00000FD, which
reports stack overflow.
(cherry picked from commit aab7b4ba3812e5876b1205285bcfd8cff96bcac9)
|
|
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.
|
|
Add DEBUG log output to try to diagnose.
|
|
following promotion of DRTVWR-582
|
|
|
|
simulator
|
|
to try to avoid "Resource busy" errors from hdiutil.
|
|
LL_USE_SYSTEM_RAND has been disabled since June 2008; that code only clutters
the implementation we actually use.
|
|
DRTVWR-577 (#232)
|
|
|
|
|
