Introduce automated code changes with OpenRewrite
(BUILD-1004)
|
|
| Status: | Closed |
| Project: | Build |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Sub-task | Priority: | Neutral |
| Reporter: | Michael Duerig | Assignee: | Michael Duerig |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Team: |
| Description |
Use casesThe refactoring bot has broadly two use cases:
For both cases we need to find a way for SOC2 compliant approvals. AnalysisIn the first case the PRs created by the bot are routine updates and we should have a blanked approval from them. Changes to the respective refactoring spec OTOH affect all upcoming PRs and should thus undergo an approval. In the second case the PRs created by the bot are specific and individual an we need to individually approve them. Changes to the respective refactoring should be easily possible as in this case the refactor bot is used as a tool for ongoing development. These should be covered by one blanked approval. Proposed SolutionRequire a ticket reference per refactoring and optionally one per module. The ones on the modules take precedence over the one from the refactoring. The refactor bot uses that ticket reference within the title of the PRs it creates. If no such ticket exists yet, it adds a tasks to the PRs for creating one. When creating tickets we add a note to the approver on the kind of refactoring and specify the scope of the approval. For example:
Initial discussion on Slack: https://magnolia-cms.slack.com/archives/C03B6DXN2KS/p1681208674400999 |