|
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
|