Continuous integration and deployment

As of now, the existing pipelines are divided in two categories:

Scheduled

Once a week, on saturday, runs a Static analysis analysis pipeline.
Event driven

Only on push events, two different workflows exist, depending on whether the build is executed for pull request or on main branch. They are responsible for check and deployments.

Static analysis

This pipeline is only executed on main branch and does the following for all modules:

Diagram

This build is purely informative and doesn’t trigger any deployments of any sort.

On push events

Those workflow are only trigger by push events on pull request.

Pull request pipelines

If the push event occurs on a pull request, it will walk the following path :

Diagram

Each activity is breaking, meaning that a failing activity will stop the pipeline.

If at least one of the file of the following list has changed, then everything is rebuilt, else a module is only built if it has been modified by the merge request :

  • provoly-common/*

  • provoly-common-test/*

  • provoly-parent/pom.xml

  • provoly-parent-build-quarkus/pom.xml

Merge pipelines

If the push occurs on the main branch, it can only be that this is the result of a pull request. In this case we need to deploy to the develop environment.

Diagram

Flyway migrations

Flyway verify and prevent modification on already executed migration. To prevent specific fix-only script and only on the development environment validation is set to false.

All migration must be applicable to all environments. If an environment requires a script (for example in case of a environment specific data-migration), a environment script will be set and versioned on a specific repository ({project}/src/main/resouces/db.onetime).