[BUILD-682] Composable PR health Created: 09/Feb/22  Updated: 27/Oct/22

Status: Selected
Project: Build
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Neutral
Reporter: Maxime Michel Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: foundation_team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screenshot 2022-03-01 at 08.47.23.png     File merge-checks.mmd     File merge-checks.svg    
Issue Links:
relation
is related to BUILD-680 Run japicmp correctly with permanent ... Closed
is related to BUILD-860 Old GroupIds Alerter Maven plugin Open
is related to BUILD-705 Let the pipeline rather than the weba... Closed
is related to BUILD-716 Block PR integrations when CE/dx-core... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Team: Foundation

 Description   

Whether with Bitbucket Server or Cloud, some of the restrictions we have to deal with are the following:

  • if any part of the monolithic PR build fails, the whole pipeline must be run again
  • because so much is happening inside the pipelines, those get harder to maintain
  • Groovy pipelines are an inconvenient way to write business requirements other than Maven goals (integration with Lokalise for instance)

Because Bitbucket's merge checks are either obsolete (Server, see DEV-1593), or lacking in flexibility (Cloud), the solution is to write such a framework ourselves.

As done with the dependency bot (see screenshot), the goal is to automatically trigger atomic jobs when a PR gets created / updated, and report their status back to Bitbucket. Bitbucket can then compute whether the PR should be merged.

Corner cases, how to handle?

  • CVEs do not make sense at PR-level, rather every day on master
  • i18n changes do not necessarily require to be validated by a build

Generated at Sun Feb 11 23:44:10 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.