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.
When we have two jobs queued for FirefoxWindows, for example, we want
one of them to wait, not cancel each other. The only time you would
cancel one is if the other is from the same branch/PR after an update.
Right now, only the browser name is used in the key, so we should never
cancel another job with the same key.
This fix lets us start tests for multiple release PRs at once.
In #6811, I introduced a bug into the lab workflow. This came to my
attention through the GitHub Actions warning: "Unexpected input(s)
'sha', valid inputs are ...". This came from the "actions/checkout" step
of the "matrix config" job. The correct input is "ref", not "sha".
This bug meant that any changes to the matrix config were not being
properly tested. It's likely we haven't had any PRs that touched the
matrix config since the bug was introduced in June.
Using arm (macos-latest) wherever possible reduces build times by 3
minutes.
We have a limited number of macos runners, so if we save time even on
Firefox alone (all we can do pending #6508), we can speed up the queue
of pending jobs across PRs.
Always compute sha1 in lab and screenshot workflows in advance. A symbolic ref can change mid-workflow if the repo changes.
Co-authored-by: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com>
When tests occasionally timeout (as is currently happening with
IndexedDB hangs on Mac), we should stop the test run after 30 minutes
and allow the "deflake" workflow to rerun them. Without this timeout,
the test run can takes hours.
A successful test run takes 15-20 minutes currently.
The condition for tagging the main branch was inverted after v4.7.11.
The main-branch tags for v4.6.16, v4.6.17, v4.7.12, v4.7.13, and v4.8.1
all had to be created and pushed by hand to correct this.
Álvaro Velad Galván
Joey Parrish
Shaka Bot