Leaving issue comments was broken in #9482, which changed gh api's -F to
-f for security reasons. However, gh issue comment doesn't have -f, only
-F, and this is distinct from gh api's problematic -F.
This reverts back to -F for gh issue comment.
Workflows using gh api should always use -f (raw field) instead of -F
(field including special characters) because a crafted message could be
used to read files from the host, which could lead to things like leaked
keys or other private information.
There is no known exploit, because these messages were not yet
controllable by an attacker as far as we know, but better safe than
sorry.
Discovered during a careful review of #9422, which adds new usage of gh
api.
The method of running old versions of Safari no longer works.
Apple no longer hosts all Safari installers. The one we referenced
before for Safari 15 is no longer available. We should probably be on
Safari 17 as our legacy version now, since the latest is Safari 18.
I found currently-available installers via
[mrmacintosh.com](https://mrmacintosh.com/macos-safari-full-installer-database-download-directly-from-apple/),
but the latest Safari 17 no longer runs on the latest macOS version. (At
least, not on my Google corporate mac.)
So it seems that the best thing to do is to just stop testing on old
versions of Safari.
----
Appendix:
Browser usage share of Safari versions according to
https://caniuse.com/usage-table as of 2025-08-25
| Safari iOS version | Usage share |
| ---- | ------ |
| 15.x | 0.47% |
| 16.x | 0.83% |
| 17.x | 0.86% |
| 18.x | 10.74% |
| Safari macOS version | Usage share |
| ---- | ------ |
| 15.x | 0.17% |
| 16.x | 0.27% |
| 17.x | 0.38% |
| 18.x | 1.59% |
The current version of Safari in macos-latest on GitHub is Safari 18.5.
- Bump to Java 21 to support the new compiler.
- Removes externs now included in the compiler.
- Removes compiler flag no longer supported.
- Adds onkeystatuseschange to MediaKeySession polyfills (now in compiler
externs).
- This new compiler now triggers a warning in the Closure Library, which
will get fixed in a follow-up to update the library.
- Make Java version explicit (11) in workflows
- Update/sync required Java version (11) in all docs and scripts
- Update/sync required Node version (18) in all docs and scripts
- Update/sync required Python version (3.5) in all docs and scripts
Naive use of google-github-actions/auth and
google-github-actions/deploy-appengine can lead to leaked credentials.
In particular, uploading static content from the workspace root leads to
servable copies of the credentials file written by
google-github-actions/auth. This is exactly what the Shaka Player Demo
did. Making matters worse, google-github-actions/auth logs credential
filenames for all to see.
All uploaded credentials were expired before I uploaded this PR.
This fixes the leak by installing a gcloudignore file which prevents the
credentials from being uploaded.
If a maintainer requests screenshot updates in a new PR, but there are
no changes, simply don't create a PR.
Also adds logs to make it clear which path was taken.
Native text layout in Safari renders differently on different devices,
OS versions, and with different OS a11y settings. Because this is so
inconsistent across devices, we now have a flag to explicity enable
native text layout tests on Safari. This flag will be used in our lab
only. Our lab tests on Safari will be the source of canonical results
for Safari layout tests.
The `workflow_call` trigger is required to allow calling a workflow from
another with "uses:". The `schedule` trigger was always a workaround,
and should now be removed.
See also PR #7892.
This is meant to fix errors like "Failed request: (409) Conflict: an
artifact with this name already exists on the workflow run" which occur
when more than one instance of a browser fails tests in the same run.
The change in behavior that led to the error likely began after updating
actions/upload-artifact.
This workflow, triggerable only by maintainers, had some potential
security issues. This is a big refactor, and makes several changes:
- Clean up description text (non-critical)
- Add granular permissions to set status (without this, the workflow was
broken since we changed default permissions)
- Split the update-pr job into commit-new-screenshots (unprivileged) and
update-pr (privileged as @shaka-bot)
The commit-new-screenshots job runs code that the PR author controls,
such as "npm ci" (controlled through package.json and
package-lock.json), and "./build/updateScreenshots.py" (easily edited to
do whatever). These steps could be used to do literally anything,
including modify tools in /usr/bin on the workflow VM that are needed by
the privileged steps.
By moving the privileged steps into a completely separate job, we can
ensure a clean slate without worrying about the VM's state. We only
transfer the .git/ folder between the two jobs. So the
commit-new-screenshots job will create the commit, and the update-pr job
will actually push that commit from a clean VM.
The job is once again functional, and for the first time, actually safe.
Now that default permissions are read-only, we must enable specific permissions for certain workflow jobs.
This fixes every job except "update screenshots", which has unresolved permissions issues.
This uses very explicit ref names for both source and destination, to
fix this error during branch creation:
> TAG=v4.12.0
> BRANCH=$(echo "$TAG" | sed -e 's/\.0$/.x/')
> git push origin HEAD:"$BRANCH"
>
> error: The destination you provided is not a full refname (i.e.,
> starting with "refs/"). We tried to guess what you meant by:
>
> - Looking for a ref that matches 'v4.12.x' on the remote side.
> - Checking if the <src> being pushed ('HEAD')
> is a ref in "refs/{heads,tags}/". If so we add a corresponding
> refs/{heads,tags}/ prefix on the remote side.
>
> Neither worked, so we gave up. You must fully qualify the ref.
> hint: The <src> part of the refspec is a commit object.
> hint: Did you mean to create a new branch by pushing to
> hint: 'HEAD:refs/heads/v4.12.x'?
> error: failed to push some refs to
'https://github.com/shaka-project/shaka-player'
> Error: Process completed with exit code 1.
To report commit status on a PR, the head commit must be used, not the
merge of that head back into the target (e.g. into main).
I would prefer to make status reporting special, so that we can run
tests and other operations against the merge (for more realistic results
and to avoid test failures that only show up after a merge). But this is
the quickest way for me to fix this critical feedback.
Álvaro Velad Galván
Wojciech Tyczyński
Joey Parrish
Shaunak
Shaka Bot
Gary Katsevman