This repository contains some of the pipelines of Kogito project.
- Kogito Pipelines
- Kogito Repositories
- The different Kogito pipelines
- Configuration of pipelines
- Contributing / Opening issues
Apart from this repository, pipelines are also concerning those repositories:
Kogito has 2 main pipelines:
- Nightly pipeline
is a multibranch pipeline which is run daily on each active branch - Release pipeline
is a on-demand single pipeline job
More information can be found here.
This is a set of cleanup utils jobs.
The jenkinsfile run in those environments can be found in each repository, at path .ci/jenkins/Jenkinsfile.specific_nightly
.
The different environments can also be found into the dsl branch config file.
Here is some explanation:
native
Run the checks with native mode enabled and GraalVMmandrel
Run the checks with native mode enabled and Mandrelquarkus branch
Run the checks against current Quarkus released branchquarkus main
Run the checks against Quarkus main branchquarkus lts
Run the checks against Quarkus LTS branchmandrel lts
Run the checks against Quarkus LTS branch, with native mode enabled and Mandrel
As an experimentation, due to many conflicts with quarkus lts
and quarkus main
branches, it has been decided to try to use an integration branch for the those nightly checks, in order to be able to resolve conflicts that my occur, but which cannot be pushed directly to the tested branch.
The integration branch nightly will:
- Checkout the current integration branch
- Try to merge the last changes from the tested branch (with
-no-ff
)- If any conflict, raise an error and developers will have to correct the merge conflict on the integration branch
- If no conflict, run the tests !
Those new nightly jobs are currently set up as new jobs and won't replace the current ones without the integration branch.
Once we decide, we may remove the "old" jobs and use only the integration branch.
PR checks are using the build-chain for artifacts and its configuration can be found in .ci folder.
They are run on both Jenkins and GHA with some slight differences.
There is one check per downstream repository. This allows parallelization and more flexibility in restart of a specific downstream repo.
kogito-images
is run only on Jenkins and is using its own .ci/jenkins/Jenkinsfile
.
NOTE: PR checks are also available for the different environments listed above. Please read the PR template to know which one are available for a specific repository.
The jobs can be found into the {branch}/pullrequest
folder in Jenkins.
Each repository contains the needed DSL configuration (can be found in .ci/jenkins/dsl
) and will most of the time use the KogitoTemplate method createMultijobPRJobs
.
This will generate all the needed PR checks and make use of the Jenkinsfile.buildchain file.
Jenkins PR checks are of 3 different types:
- Simple build&test (automatic)
Regular testing - Native build&test (optional, can be launched with comment
jenkins run native
)
Test all native parts of the repository - Mandrel build&test (optional, can be launched with comment
jenkins run mandrel
)
Test against Mandrel builder image - Quarkus main build&test (optional, can be launched with comment
jenkins run quarkus-main
)
Test against quarkus main version - Quarkus branch build&test (optional, can be launched with comment
jenkins run quarkus-branch
)
Test against quarkus branch, corresponding to current used Quarkus released version - Quarkus lts build&test (optional, can be launched with comment
jenkins run quarkus-lts
)
Test against quarkus branch, corresponding to current used Quarkus LTS version
Each repository has a different yaml files in .github/workflows
folder to configure the workflow.
We are additionally using composite actions
to centralized most common steps used by the different Kogito repositories' jobs. You can check the different kind of composite actions we have available at .ci/actions
folder.
After the build, test results are parsed and logged using the action-surefire-report
action.
NOTE: test coverage analysis is executed only by Jenkins PR simple build&test and not while using GitHub action.
Note: Creating separate readme.md documenting how-tos and best practices for implementing pipelines might be useful
In this repository two types of pipelines can be found:
- Kogito pipelines (obviously) - located in the .ci/jenkins folder
- Seed jobs library - see Jenkins documentation
Apart from these pipelines, the jenkins-pipeline-shared-libraries
are also stored in this repository. Functions and classes contained in these libraries can be freely used in all pipelines located under KIE Jenkins folder. Just include correct import and annotation in your Jenkinsfile:
import org.jenkinsci.plugins.workflow.libs.Library
@Library('jenkins-pipeline-shared-libraries')_
For more details please see our Jenkins pipelines shared libraries documentation and Jenkins.io documentation
All KIE jobs (pipelines) can be found in KIE Jenkins folder
For this folder and all its descendants there is several useful things set at this folder level:
- Pipeline library - accessible in pipelines under name
jenkins-pipeline-shared-libraries
it gives access to some useful functions used throughout various KIE pipelines. More details can be found in our Jenkins pipeline shared libraries documentation and in the previous chapter - Environment Variables - Environment variables set here are inherited by all the folders and jobs located in the KIE folder tree in Jenkins. However, they can be overridden or extended. You can modify the variables by clicking
Configure
in the left menu (if you have necessary permissions). Currently present Environment Variables are:- FAULTY_NODES - Comma separated list of Jenkins execution nodes that are faulty in some way and cause KIE jobs to fail. This variable is expected by the pipeline-library function
util.avoidFaultyNodes(String label)
, which extends desiredlabel
by expression that ensures avoiding these faulty nodes. Use ofutil.avoidFaultyNodes()
(without parameter) is also possible for cases where no specificlabel
needs to be set. This way we can increase durability of KIE automation by the time the Apache CI team fixes the issue with faulty node.
- FAULTY_NODES - Comma separated list of Jenkins execution nodes that are faulty in some way and cause KIE jobs to fail. This variable is expected by the pipeline-library function
All pipelines from this repository can be found in kogito Jenkins folder.
More information can be found here.
Any message / error is sent to kogito-ci stream.
[branch] Project
The work on the pipelines has been separated into different epics:
- KOGITO-8034 Kogito Pipelines maintenance / small changes
- KOGITO-8037 Kogito Pipelines improvements for the release pipeline
- KOGITO-8038 Kogito Pipelines improvements for the PR and nightly checks
- KOGITO-8036 Kogito Pipelines infrastructure tasks
- KOGITO-8035 Kogito Pipelines pipelines ideas / nice to have
Please use one of those epics if you create any issue.