Details
-
Task
-
Resolution: Unresolved
-
Neutral
-
None
-
None
-
None
-
-
Empty show more show less
-
Empty show more show less
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
Checklists
Attachments
Issue Links
- is related to
-
BUILD-680 Run japicmp correctly with permanent SNAPSHOTs (in pipelines)
-
- Closed
-
-
BUILD-860 Old GroupIds Alerter Maven plugin
-
- Open
-
-
BUILD-705 Let the pipeline rather than the webapp publish its status to Bitbucket when done
-
- Closed
-
-
BUILD-716 Block PR integrations when CE/dx-core aren't building
-
- Closed
-
- links to