- Jul 13, 2023
-
-
Jonas Höppner authored
-
- Jun 02, 2023
-
-
Jonas Höppner authored
We had timeouts during the upload of the artifacts so I increase it to 90 minutes.
-
- Apr 24, 2023
-
-
Tim Jaacks authored
Since the changes of 939ade2b we observe that pipelines are executed on non-protected branches, which is not what we want. GitLab's documentation was a bit unclear on the according CI variables CI_COMMIT_REF_PROTECTED and CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED, as stated in this stack overflow answer: https://stackoverflow.com/a/59023344/3018229 We need to explicitly check for the variable values to be "true" instead of just checking whether they are set.
-
- Apr 04, 2023
-
-
Tim Jaacks authored
Previously we had the master branch hard-coded in a variable in order to determine whether to run the integration pipeline (on non-master branch) or the merge pipeline (on master branch). This variable had to be adapted everytime we copy a branch, which can potentially be forgotten and lead to problems. Remove the hard-coded branch and use the branch protection state for this decision instead in order to make this more flexible.
-
- Apr 03, 2023
-
-
Tim Jaacks authored
The rules for the yamllint jobs have been defined in the .yamllint class before. They were overridden in the manifest pipeline's yamllint job, though, which has its own rules, so we don't need them to be inherited in this case. And in the manifest integration pipeline the rules can be much easier, so define them there instead of at the class-level.
-
- Mar 27, 2023
-
-
Tim Jaacks authored
-
- Mar 21, 2023
-
-
Tim Jaacks authored
Usually project name and path are identical after project creation. It is possible, though, to change the name of a project without changing its path. When triggering a pipeline on the integration branch, we are using the CI_PROJECT_NAME variable to reference the project. Unexpectedly, this variable contains the *path*, not the *name* of the project (see https://gitlab.com/gitlab-org/gitlab/-/issues/20030). Hence we have to use the project path in all other places where the integration branch name is constructed in our Python code.
-
- Mar 20, 2023
-
-
Tim Jaacks authored
-
- Mar 07, 2023
-
-
Tim Jaacks authored
-
- Feb 28, 2023
-
-
Tim Jaacks authored
-
Tim Jaacks authored
This will make the manifest project support the "skip build" label.
-
- Feb 20, 2023
-
-
Tim Jaacks authored
This reverts commit 4db257d3. It does not work on the manifest, because we do not run merge request pipelines there, so CI_MERGE_REQUEST_LABELS is not set at all.
-
Tim Jaacks authored
-
Tim Jaacks authored
-
- Feb 14, 2023
-
-
Tim Jaacks authored
GitLab API has changed: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/94164/diffs#diff-content-c201dae00b72426693ddcb40edf6005e7702e935
-
- Feb 10, 2023
-
-
Jonas Höppner authored
-
- Feb 06, 2023
-
-
Tim Jaacks authored
-
Tim Jaacks authored
Instead of hard-coding the project list in the changelog generator script, make them passable via arguments. This way we can have different changelogs in different envrionments. Hence we're adding the changelog job in the ci-test environment as well.
-
Tim Jaacks authored
-
Tim Jaacks authored
This case should trigger a new pipeline instead of reporting an error.
-
Tim Jaacks authored
-
Tim Jaacks authored
This fixes older releases not appearing in the changelog.
-
- Jan 10, 2023
-
-
Tim Jaacks authored
-
Tim Jaacks authored
-
Tim Jaacks authored
-
Tim Jaacks authored
Refactor three scripts into one in order to support triggering a new pipeline in the case of a skipped MR pipeline. This was not possible to implement with the previous three-script design. The single scripts were not used in other places anyway.
-
- Jan 09, 2023
-
-
Tim Jaacks authored
The dynamic job was only necessary because GitLab did not expand variables in the "trigger:project" keyword: https://gitlab.com/gitlab-org/gitlab/-/issues/347469 This has been fixed in GitLab 15.3, so we don't need it anymore: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92346
-
- Jan 03, 2023
-
-
Tim Jaacks authored
-
Tim Jaacks authored
Everytime we push a new commit to a branch, a new pipeline is created. Often the pipeline for the previous commit has not finished yet, and GitLab does not automatically cancel it. It consumes valuable build time, even if we don't need the results anymore. Adding a MR pipeline job to search for previous pipelines on the same branch and cancel them explicitly.
-
Tim Jaacks authored
-
- Dec 21, 2022
-
-
Jonas Höppner authored
For a given project all artifacts may be deleted. This was needed due to space limitations on the gitlab server.
-
- Dec 20, 2022
-
-
Tim Jaacks authored
-
Tim Jaacks authored
Otherwise the parent pipeline is stuck in "running" state until the manual action has been performed. See for reference: https://gitlab.com/gitlab-org/gitlab/-/issues/361574
-
Tim Jaacks authored
-
- Dec 19, 2022
-
-
Tim Jaacks authored
-
Tim Jaacks authored
-
Tim Jaacks authored
-
Tim Jaacks authored
-
Tim Jaacks authored
-
Tim Jaacks authored
-