web.dev
web.dev copied to clipboard
GoogleChrome
Unconditionally run presubmit workflow for all PRs
Fixes #8385
As per recent discussion, the build time is short enough and the risk of breakage is high enough that we do want to go ahead and run presubmits for all PRs, without having to remember to add in the $-presubmit label.
Deploy Preview for web-dev-staging ready!
| Name | Link |
|---|---|
| Latest commit | 67e184691fa99251f63613167f4f95f7dac6648c |
| Latest deploy log | https://app.netlify.com/sites/web-dev-staging/deploys/62e29e6fbd057e000851f045 |
| Deploy Preview | https://deploy-preview-8419--web-dev-staging.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
Historically we've been running staging in our presubmit, so I just left that as-is. Staging takes 6 minutes.
I'll add a commit to flip it to production and we can see how long it takes.
So, it's 18 minutes for the prod build, vs. 6 minutes for the staging build.
A staging build will be sufficient to catch any of the 11ty-related errors we've run into lately. A prod build would be most useful if you were actually examining the output of, e.g., the HTML minifier, but you can't do that for the GitHub Actions build anyway.
I would say we should just stick with a staging build for the presubmit check. What do you think, @devnook?
A staging build will be sufficient to catch any of the 11ty-related errors we've run into lately.
I did want to acknowledge that a staging build would not have caught the HTML minifier error addressed in https://github.com/GoogleChrome/web.dev/pull/8374, though. So it's a tradeoff.
Yes, this should re-run each time there's an additional commit.
It's configured for on: pull_request, and as per the docs:
Runs your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated.