Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • otb otb
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 207
    • Issues 207
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Main Repositories
  • otbotb
  • Wiki
  • OTB Continuous Integration platform

OTB Continuous Integration platform · Changes

Page history
Create ci platform authored Jun 27, 2019 by Guillaume Pasero's avatar Guillaume Pasero
Hide whitespace changes
Inline Side-by-side
OTB-Continuous-Integration-platform.md 0 → 100644
View page @ 41743110
The role of the Continuous Integration platform is to validate the different
commits pushed to OTB repository. When commits are pushed, either on the main
repository or on a fork, the platform triggers a pipeline with several jobs to
build and test OTB on different configurations.
Depending on where your commit was pushed, different pipelines are created:
* push on a feature branch -> `wip` pipeline
* push on a feature branch with a merge request (not in WIP) -> `mr` pipeline
* push on `develop` branch -> `develop` pipeline
* push on a release branch `release_X.Y` -> `release` pipeline
The `wip` pipeline is the fastest, with only one build job on Linux. The `mr`,
`develop` and `release` pipeline are more exhaustive and build on several platforms.
The different pipeline stages are:
* `precheck` : fast build on Linux, no test
* `prepare` : for configuration using a XDK, update it if SuperBuild has changed
* `build` : compile, test and package OTB on various platforms
* `qa` : analyse code quality
* `report` : send quality reports to SonarQube
* `deploy` : upload generated binaries and documentation to OTB website
* `external` : contains the links to CDash submissions
When a pipeline ends, there are two cases:
* if all the jobs succeed, you see a green pipeline, which means no problem was
found on your commit.
* if one job fails, you see a red pipeline, which means something is broken in
your commit. The pipeline widget on Gitlab will tell you which job failed. You
will also find special jobs "cdash:..." in the stage `external` that provide
a link to the [Dashboard](https://cdash.orfeo-toolbox.org/index.php?project=OTB)
where you can look more in details into compilation errors and failed tests.
Failed jobs can be retried if you think the failure was not bound to your commit.
What about baseline files? They are now stored in the main OTB repository, under
`Data` folder. You can update them with a plain commit on your feature branch.
Note that the data files are tracked with [Git LFS](https://git-lfs.github.com/)
, so you need to install this extension.
\ No newline at end of file
Clone repository
  • Deprecated Info
  • Help for release actions
  • How to contribute to QGIS related to OTB processing provider
  • How to deprecate
  • List of publications mentioning OTB
  • Migration guide OTBv8
  • OTB Continuous Integration platform
  • OTB Users Day 2018
  • PSC meetings
  • Remote Modules
  • Remove OSSIM
  • Home
  • uploads
    • d7dcea8f9f7385fc40a5cc8328f02520
      • filterRefactoring