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.
Since upgrading the deployment action from v0 to v2, and stumbling into
google-github-actions/deploy-appengine#361, new versions were not
properly promoted. However, our promotion setting in the workflow was
actually ignored the whole time due to a missing "echo".
Closes#6502
Upgrading release-please-action to v4 requires some changes:
- Move some settings from the action inputs to a manifest file (release-type, extra-files)
- Rename default-branch to target-branch
Additionally:
- There is an example in the new release-please-action docs that covers our exact use case for upload-release-action, but with the official GitHub CLI app. So we drop upload-release-action and use the GitHub CLI instead.
- There is an output in release-please-action that gives access to the patch version from semver. We should use this instead of running endsWith() over tag_name.
- Update mxschmitt/action-tmate@v3.6 => v3.17. This is a trivial update on an action that I missed in my last audit.
I missed some before. I only updated actions from GitHub "actions/..."
This updates all other actions except google-github-actions/release-please, which has some breaking changes we would need to absorb and test.
- Link CI status to specific jobs, not just the run
- Split selenium job status flag away from ignore_test_status (which is for getting screenshots)
- Remove redundant status setting step in update-screenshots
- Fix final status computation in update-screenshots to account for edge cases and old typo
This eliminates warnings about outdated node runtimes in GitHub Actions.
actions/download-artifact and actions/upload-artifact are the only ones
with any potential breaking changes, and adjustments have been made and
tested.
See
https://github.com/actions/upload-artifact/blob/main/docs/MIGRATION.md
- Fix wrong index variable in loop ("i" vs "INDEX") that prevented
detection of commands at arbitrary places in a comment.
- Fix parsing of comments with newlines.
- Normalize commands to lowercase before checking them.
- Enhance debugging of command parsing.
- Allow the user to say "please" because it just feels nicer to me, even
when I'm talking to a robot.
lib/player.js was being updated separately because:
1. Originally, we didn't have support for updating arbitrary files with
release-please.
2. When we did get that support in release-please, it would trash the
"-uncompiled" tag we have in uncompiled mode.
By separating the uncompiled version string into two parts and using the
extra-files feature of release-please, we can get the updater to
preserve the "-uncompiled" tag and simplify the release workflow to only
update the PR once per change instead of twice.
In #5588 we switched off one part of using a fork for release PRs, but
not every part. That caused player.js not to be updated in release PRs,
which broke NPM releases.
This fixes the issue by removing other references to the shaka-bot fork.
Closes#5599
This enables workflows to be triggered automatically on release PRs,
instead of requiring maintainers to edit the PR description on every
release to trigger required PR workflows.
This uses a separate token from the other shaka-bot token, because it
requires additional permissions to make releases.
Now maintainers can send commands to Shaka Bot via PR comments.
Initially, Shaka Bot understands the following commands from anyone:
- `@shaka-bot help`: Show this help message
And the following commands from maintainers only:
- `@shaka-bot test`: Start lab tests on all devices
- `@shaka-bot test ce`: Start lab tests on CE devices only (no desktop
browsers)
This reverts commit 18ffa2cbbc.
So long as we make feature releases with a reasonable (< 100 PRs)
granularity, we won't need to keep doing this. Let's try to keep v4.4 an
anomaly.
Álvaro Velad Galván
Joey Parrish
theodab
Shaka Bot