Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add workflow job to deduplicate dependabot pull requests #14845
Add workflow job to deduplicate dependabot pull requests #14845
Changes from 1 commit
49e2230
9974559
555c43c
2fdb6f1
de03c96
7c1b2e0
bb6fb5f
6ba567c
f7e2fb5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Why is this even needed?
Why is this not solved by dependabot or even yarn?
I find it strange that every project that relies on dependabot would need some workaround like this?
This also breaks the auto rebase feature that dependabot does as it refuses to change a PR that someone else has messed with, which means that we would need to comment
@dependabot recreate
for all PRs.This is not great from a resource perspective (we should also add concurrency with cancel to the CI workflow but that's a separate topic.)
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.
Yarn certainly can't control what dependabot does, but yeah I totally agree dependabot should handle it. Hopefully this would be temporary. Here's the issue: dependabot/dependabot-core#5830
Yeah I agree, although not "all" PRs will need the deduplication step. Theoretically, there would be less and less commits required as dependencies are brought up to date.
I was going to add that but didn't want to go off-topic.
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 don't see the direct need for it to run and push in this workflow at all.
We are trying to do all kinds of weird things to make this happen. IMHO we can just make this a maintenance task, or let a task run every day or week on a schedule to clean this up.
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 existing CI checks for duplicates via
yarn dedupe --check
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 thats all that this is really for, we can just remove that check and do this as general maintenance and/or on a separate schedule?
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 don't think that's wise. The check is run to minimize what packages get bundled and sent to the browser. Leaving duplicates can affect frontend results. It's not just maintenance.
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 make a separate action, that checks if a dedupe is needed and creates a PR if it is and run that daily, it might be an easier fix? Or even run it after a merge of a dependabot PR.
We can still have the dedupe check in CI for manual PRs and skip it for dependabot?
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 personally wouldn't be a fan of that because you'd be degrading any validation and testing on the original bump, only to make more work for yourself on the subsequent deduplication. It would also be arguably more work than this change, especially to automate opening the PR.
I honestly didn't expect push back over "skipped" messages, but since this is getting no love, what's the problem with making a separate workflow (only to run on dependabot branches) and using a GitHub app to authenticate?
I could setup a new app and transfer ownership to HA (or use an existing bot?). Then use a 3rd party action like this one to authenticate and commit as the app. Someone above my pay grade just needs to add the credentials as secrets.
The only downside to that approach is that if the app commits, then CI runs twice and wastes resources.
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.
Here's an example from a recent PR to support keeping the check (and moving it up before the others):
https://github.com/home-assistant/frontend/actions/runs/4022152029
The CI failed during the types check, but the actual problem was the imports getting mangled with a duplicate. Simply running the dedupe was the fix.