-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
feat: set up auto prs for snapshot metafile changes #25052
Conversation
Thanks for taking the time to open a PR!
|
on: [workflow_dispatch] | ||
on: | ||
schedule: | ||
# Run every Wednesday at 00:00 UTC |
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 chose this so it'll be after the release. I'm ensuring to run from scratch then, so any changes will be caught early rather than right before the release.
Co-authored-by: cypress-bot[bot] <2f0651858c6e38e0+cypress-bot[bot]@users.noreply.github.com> Co-authored-by: Ryan Manuel <[email protected]>
What's the advantage in generating this from scratch in the job, rather than updating the existing one? |
Mainly performance improvements. Generally the way this works is that dependencies can go to a "worse" category, but can't go back the other way. Thus, over time, there may end up being more and more dependencies that could be optimized better but are not. This is a challenging problem to do iteratively, and I have not been able to figure out a way to solve it other than regenerating from scratch periodically. |
Looks like this adds several empty yarn.lock files? (because they're empty, I can't comment on them directly from the files tab). |
type: boolean | ||
default: false | ||
commit_directly_to_branch: | ||
description: 'Commit directly to branch' |
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.
When would we want to set this true?
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 you're wanting to commit something to your feature branch but don't want to go through the rigmarole of a PR to your feature branch.
@@ -3930,8 +3930,8 @@ | |||
"./packages/types/src/util.ts", | |||
"./packages/types/src/video.ts", | |||
"./packages/types/src/warning.ts", | |||
"./tooling/v8-snapshot/cache/prod-darwin/snapshot-entry.js" | |||
"./tooling/v8-snapshot/cache/darwin/snapshot-entry.js" |
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.
Love to see the reduced duplication. 👍
forceNoRewrite: this.forceNoRewrite.size, | ||
auxiliaryData: auxiliaryDataKeys, | ||
}) | ||
} | ||
|
||
private _addGitignore () { | ||
const gitignore = 'snapshot.js\nbase.snapshot.js.map\nprocessed.snapshot.js.map\nesbuild-meta.json\nsnapshot-meta.json\nsnapshot-entry.js\n' | ||
const gitignore = 'snapshot.js\nbase.snapshot.js.map\nprocessed.snapshot.js.map\nesbuild-meta.json\nsnapshot-entry.js\n' |
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.
This should limit the day to day concerns that people have with respect to the cache file (i.e. you won't ever have to check this file in unless you are explicitly wanting to)
I'm not sure I follow this. When you say won't have to check it in - will the cache file still show up in the git diff
output? I haven't been clear on when I should be checking in changes or not, and therefor also not sure how this PR changes 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.
The key bit happens here. Basically when you're developing locally, V8_UPDATE_METAFILE
won't be set and so the cache files won't be written. The only time they will be written is with the github action (or if you explicitly set that environment variable locally for some reason).
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.
Looks good, please verify that we are not using a soon-to-be-deprecated CircleCI API. My other comments are just ideas/questions, not blockers.
- cron: '0 0 * * 3' | ||
push: | ||
branches: | ||
- ryanm/feature/v8-snapshots-auto-pr |
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.
Just to check is this a scheduled PIPELINE or a scheduled WORKFLOW? The reason I ask https://circleci.com/docs/configuration-reference/#schedule
The scheduled workflows feature is set to be deprecated. Using scheduled pipeline.
This is in a workflows
file and called schedule
- just want to verify we are not using a soon-to-be-deprecated feature.
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.
Ah yeah. That's circle ci. I'm using it in a github action where it is not deprecated.
branchName: '${{ env.BRANCH_NAME }}', | ||
description: 'Update v8 snapshot cache', | ||
body: 'This PR was automatically generated by the [update-v8-snapshot-cache](https://github.com/cypress-io/cypress/actions/workflows/update_v8_snapshot_cache.yml) github action.', | ||
reviewers: ['ryanthemanuel'] |
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.
🙌
@@ -0,0 +1,86 @@ | |||
const { expect } = require('chai') |
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.
Random q, I wonder if a better way to test if this is working would be to just have a local check in the monorepo. Eg, when you run yarn install
, we would (somehow) check the last time the snapshot metadata was updated. If it's been more than , we could either error or warn "snapshot hasn't been updated in a week; is the automation working?"
Just an idea - if this GHA stopped working, or we changed to use another VCS service, we'd need to remember to do this. Not a requirement for this PR, specifically - just floating an idea to make the monorepo more self maintaining.
hashFilePath != null, | ||
`Unable to find hash file inside ${projectBaseDir}`, | ||
) | ||
healthy.forEach((dependency) => { |
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.
Going to admit I don't fully grok the finer details of some parts of this PR (like this). I get the general idea though, and it looks like this makes sense.
- cron: '0 0 * * 3' | ||
push: | ||
branches: | ||
- ryanm/feature/v8-snapshots-auto-pr |
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.
Remove before merging?
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 could. But I also sort of see this as similar to what we do in the circle ci file. If you're working on it on your branch, update it with your branch, and so on and so on.
…napshots-auto-pr # Conflicts: # tooling/v8-snapshot/cache/darwin/snapshot-meta.json
Co-authored-by: cypress-bot[bot] <2f0651858c6e38e0+cypress-bot[bot]@users.noreply.github.com>
Co-authored-by: cypress-bot[bot] <2f0651858c6e38e0+cypress-bot[bot]@users.noreply.github.com> Co-authored-by: Ryan Manuel <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
User facing changelog
n/a
Additional details
This PR offers several quality of life improvements for local development with V8 snapshots
develop
andrelease/**
branches and will issue a PR against the respective branchesdev
was always a subset ofprod
anyway, so I updated logic to read onlynode_modules
from the file if we're indev
mode and the whole file if we're inprod
modeV8_UPDATE_METAFILE
is set to true and we're running inprod
mode. This happens automatically on the GitHub action. This should limit the day to day concerns that people have with respect to the cache file (i.e. you won't ever have to check this file in unless you are explicitly wanting to)Steps to test
You can trigger the workflow and run it against a branch to test it:
How has the user experience changed?
n/a
PR Tasks
cypress-documentation
?type definitions
?