Understanding the rationale of forcing dependabot target-branch to default on security updates #149760
Replies: 1 comment
-
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Select Topic Area
Question
Body
A good many of us use non-default branches to represent non-prod environments, like QA. We want to be able to test the code in these branches before merging those changes to the default main branch. Test before a release, it just makes horse sense.
Can I understand the rationale behind forcing security updates coming from Dependabot to target the default branch unconditionally? Do you not want us to test? Why are you trying to jam security updates? And why take this risk of being wrong and pushing a breaking change, do you not have a legal department? Nothing makes sense, the world is broken.
Out of protest, I will delete all dependabot security update pull requests, swatting them away as another example of bureaucratic busywork friction, until you allow us to choose a target-branch for security updates.
Thank you for your time and attention to this matter.
Beta Was this translation helpful? Give feedback.
All reactions