-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pin Chromium revision for binary installs #33855
Pin Chromium revision for binary installs #33855
Conversation
@DanielRyanSmith what I suggested was based on my understanding of what https://github.com/puppeteer/puppeteer/blob/main/utils/check_availability.js does. Running To help judge if this is good enough, could you list the mutually available revisions in the past week? Does it happen every day, or less often? |
662146a
to
f536b64
Compare
I checked all revisions that were added in a roughly 1-week span from April 25th to March 2nd (995555-998216) and found 33 revisions that had a download available for every platform. That's a larger number than I expected, and perhaps the previous period we tested for had an unusually low number of viable revisions. If it is the case that we cannot find a new revision for a few days, will that be a significant problem? Also, if it's of interest, these are the numbers that were found to be viable:
|
090b799
to
c87408e
Compare
tools/ci/run_tc.py
Outdated
revisions_path = os.path.join(os.getcwd(), "tools", "wpt", "latest_chromium_revision.txt") | ||
with open(revisions_path) as f: | ||
revision = f.read().strip() | ||
dest = os.path.join("/tmp") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this the same as just "/tmp"?
tools/ci/run_tc.py
Outdated
f"{revision}/chrome-linux.zip") | ||
resp = get(url) | ||
with open(installer_path, "wb") as f: | ||
f.write(resp.content) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this end up reading the whole file into memory and then to disk? Can it be streamed to disk, or unzipped directly from the network? Given how big the archives are it seems like it could make a measurable difference. Worth timing this before doing too much work optimizing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a look into it. Additionally, I think it might be worth it to remove this CI installation change entirely from this PR so that we can implement everything in a separate PR involved in changing to using Chromium for the CI.
894e5bd
to
641f0c1
Compare
Is the plan here to get daily PRs to update Chromium? Unless those are merged automatically it feels like it's going to be quite spammy. |
@jgraham Yes, we'll start with merging them manually and then look at making wpt-pr-bot approve them and merge if CI passes. Would it address the spamminess if we make wpt-pr-bot not assign any human reviewers for these PRs? |
with: | ||
token: ${{ secrets.GITHUB_TOKEN }} | ||
author: wpt-pr-bot <[email protected]> | ||
title: "Update latest available Chromium revisions" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update the commit/PR wording to match recent changes? For this line, maybe:
title: "Update latest available Chromium revisions" | |
title: "Update pinned Chromium revision" |
I think the commit message should also be the same as the PR title.
641f0c1
to
3e41678
Compare
Maybe? I expect I'll see it a bit anyway, and it creates a bunch of extra churn for syncs (that we also get from frequently updated deps like hypothesis, but still). In theory it could be avoidable if you could instead get the latest revision written to an external artifact at a knowable URL (I assume the GH API enables this kind of thing, but I haven't looked in detail). The disadvantage would be that there's a race where different CI systems could test the same revision with different versions of Chromium (that's solveable within a specific CI system by making the testrunning jobs depend on a revision-fetching job, like we do for Firefox in taskcuster). Assuming we go ahead with this approach, what's the tradeoff between the pr-bot merging the PR and the GH action itself merging the PR? It seems like the latter would be simpler, but maybe has worse security properties? |
@jgraham, @foolip and I were speaking about this earlier and explicitly brought up the idea of keeping this revision as an external artifact like you mentioned. The initial hesitance there is that we want to ensure that the revision chosen will pass the CI before being changed. I have not looked into the possibility of having the GH action merge the PR, but if we can ensure there will be no issues with the CI when this revision is changed, then that is a probable approach. |
8efe8c9
to
597f808
Compare
9532c3d
to
68c2a06
Compare
Hey all, I dropped work on this change but now I've updated it: I've implemented this to reference an external artifact in GCP. It uses cloud functions to check for revisions daily and run the new revisions against the CI in this draft PR using the GitHub API. The new revision will be pinned if everything looks good. The draft PR is just for the tests to run and there should be no need anymore for daily PRs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we could have a --revision=latest
that uses the current behavior, I think this is good to go.
The pinned Chromium revision now lives in cloud storage. Updates will be checked for it daily via a cloud function.
6b87fa0
to
10d2f64
Compare
Part of #14456
This change allows the pinning of a Chromium revision that has been tested against the WPT GitHub check suite.
Cloud Functions are run on WPT's GCP account that identifies the most recent Chromium revision that is mutually available to all major platforms (Linux, Mac, Windows). This revision is updated as an external artifact, and a test run is initiated on this draft PR. If all checks are successful, the revision is pinned as an an additional external artifact. When a user installs Chromium via
./wpt install
, The revision installed will use this revision unless specified otherwise.The
--revision
flag is now available for invocations of./wpt install
. This will allow the user to specify which Chromium revision to install. This flag allows forpinned
andlatest
arguments, which install the pinned revision or latest available revision respectively.Chromium binaries are now installed noting the revision they are associated with. If a webdriver is installed to match a Chromium binary, or vice versa, this revision will be referenced and used to match.
This change does NOT switch any testing to use Chromium instead of Chrome. The code for installing Chromium has been added to
tools/ci/run_tc.py
but should not be part of the CI process.