devel-docs: Remove outdated CI explanation in favor of gitlab-ci.yml
This is already documented and updated on gitlab-ci.yml's "There are five "TYPES" of pipelines on our CI" section so maintaining two explanations is pointless and not future-proof.
This commit is contained in:
Bruno Lopes
parent
db040ce9e0
commit
35bde24daa
2 changed files with 5 additions and 82 deletions
|
|
@ -19,15 +19,14 @@ spec:
|
|||
default: 'none'
|
||||
---
|
||||
|
||||
|
||||
# Our pipelines are auto cancelable when explicity set in 'rules'.
|
||||
# GitLab is quite sensitive about rules 'if' order so be careful.
|
||||
workflow:
|
||||
auto_cancel:
|
||||
on_new_commit: interruptible
|
||||
|
||||
|
||||
# There are five "TYPES" of pipelines on our CI:
|
||||
##################################################
|
||||
# There are five "TYPES" of pipelines on our CI: #
|
||||
##################################################
|
||||
|
||||
## 1. On MERGE REQUESTS, the following are triggered:
|
||||
## - Abbreviated Linux Clang build (base & fast)
|
||||
|
|
@ -39,7 +38,8 @@ workflow:
|
|||
variables: {}
|
||||
|
||||
## 2. LABELED MERGE REQUESTS (search for 'CI_MERGE_REQUEST_LABELS').
|
||||
#'interruptible: true' needs to be hardcoded on job
|
||||
#'interruptible: true' needs to be hardcoded on job rules
|
||||
# GitLab is quite sensitive about rules 'if' order so be careful
|
||||
|
||||
## 3. On COMMITS except tags.
|
||||
## - Linux Clang build (base & fast)
|
||||
|
|
|
|||
|
|
@ -175,83 +175,6 @@ information.
|
|||
|
||||
## TODO: GIMP extensions (*.gex*)
|
||||
|
||||
## Continuous Integration
|
||||
|
||||
For most of its continuous integration (macOS excepted), GIMP project
|
||||
uses Gitlab CI. We recommend looking the file
|
||||
[.gitlab-ci.yml](/.gitlab-ci.yml) which is the startup script.
|
||||
|
||||
The main URL for our CI system is
|
||||
[build.gimp.org](https://build.gimp.org) which redirects to Gitlab
|
||||
pipelines page.
|
||||
|
||||
Note that it is important to keep working CI jobs for a healthy code
|
||||
source. Therefore when you push some code which breaks the CI (you
|
||||
should receive a notification email when you do so), you are expected to
|
||||
look at the failed jobs' logs, try and understand the issue(s) and fix
|
||||
them (or ask for help). Don't just shrug this because it works locally
|
||||
(the point of the CI is to build in more conditions than developers
|
||||
usually do locally).
|
||||
|
||||
Of course, sometimes CI failures are out of our control, for instance
|
||||
when downloaded dependencies have issues, or because of runner issues.
|
||||
You should still check that these were reported and that
|
||||
packagers/maintainers of these parts are aware and working on a fix.
|
||||
|
||||
### Automatic pipelines
|
||||
|
||||
At each commit pushed to the repository, several pipelines are currently
|
||||
running, such as:
|
||||
|
||||
- Debian testing builds
|
||||
- Windows builds (cross compiled).
|
||||
|
||||
Additionally, we test build with alternative tools or options (e.g. with
|
||||
`GCC` instead of `Clang` compiler) or jobs which may take much longer,
|
||||
such as package creation as scheduled pipelines (once every few days).
|
||||
|
||||
The above listing is not necessarily exhaustive nor is it meant to be.
|
||||
Only the [.gitlab-ci.yml](/.gitlab-ci.yml) script is meant to be
|
||||
authoritative. The top comment in this file should stay as exhaustive
|
||||
as possible.
|
||||
|
||||
### Manual pipelines
|
||||
|
||||
It is possible to trigger pipelines manually, for instance with specific
|
||||
jobs, if you have the "*Developer*" Gitlab role:
|
||||
|
||||
1. go to the [Pipelines](https://gitlab.gnome.org/GNOME/gimp/-/pipelines)
|
||||
page.
|
||||
2. Hit the "*Run pipeline*" button.
|
||||
3. Choose the branch or tag you wish to build.
|
||||
4. Add relevant variables. A list of variables named `GIMP_CI_*` are
|
||||
available (just set them to any value) and will trigger specific job
|
||||
lists. These variables are listed in the top comment of
|
||||
[.gitlab-ci.yml](/.gitlab-ci.yml).
|
||||
|
||||
### Merge request pipelines
|
||||
|
||||
Special pipelines happen for merge request code. For instance, these
|
||||
also include a (non-perfect) code style check.
|
||||
|
||||
Additionally you can trigger flatpak standalone packages, Windows
|
||||
installer or Microsoft Store/.msixbundle to be generated
|
||||
with the MR code as explained in [gitlab-mr.md](gitlab-mr.md).
|
||||
|
||||
### Release pipeline
|
||||
|
||||
Special pipelines happen when pushing git `tags`. These should be tested
|
||||
before a release to avoid unexpected release-time issues, as explained
|
||||
in [our release procedure](https://developer.gimp.org/core/maintainer/release/).
|
||||
|
||||
### Exception: macOS
|
||||
|
||||
As an exception, macOS is currently built with the `Circle-CI` service.
|
||||
The whole CI scripts and documentation can be found in the dedicated
|
||||
[gimp-macos-build](https://gitlab.gnome.org/Infrastructure/gimp-macos-build)
|
||||
repository.
|
||||
|
||||
Eventually we want to move this pipeline to Gitlab as well.
|
||||
|
||||
## Core development
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue