- Aug 29, 2023
-
-
Tim Jaacks authored
Disable it locally instead, so that 1. new code additions are always checked, and 2. we can refactor one function at a time to make the check pass.
-
- Aug 28, 2023
-
-
Tim Jaacks authored
The old printf-style string formatting syntax using '%' is not recommended anymore. See for reference: https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting https://docs.sourcery.ai/Reference/Python/Default-Rules/replace-interpolation-with-fstring/ Python 3.6 introduced f-strings as a better alternative: https://docs.python.org/3/reference/lexical_analysis.html#f-strings Consequently switch to this new syntax for all strings.
-
- Aug 10, 2023
-
-
Tim Jaacks authored
When there are multiple open merge requests for a commit, we currently take the newest one to determine the integration branch name. This is not necessarily the correct one, we can have an open merge request with the commit being part of the commit history while the top commit is a different one. Add a check if the commit is the top commit of the merge request in order to get the correct integration branch name in these cases.
-
- Aug 03, 2023
-
-
Tim Jaacks authored
Move the main part of the action to the if branch. See for reference: https://docs.sourcery.ai/Reference/Python/Default-Rules/swap-if-else-branches/
-
- Jul 21, 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.
-
- Nov 28, 2022
-
-
Tim Jaacks authored
-
Tim Jaacks authored
-
- Aug 29, 2022
-
-
Tim Jaacks authored
We were passing the complete TemporaryDirectory object to the repo clone function instead of just the path string, resulting in the repo being cloned into a local dir "<TemporaryDirectory '/tmp/tmphwakypf8'>". Fix this to actually use the generated temp dir. This change makes it necessary to keep the TemporaryDirectory object reference until we don't need the directory anymore, otherwise it will be removed immediately.
-
Tim Jaacks authored
Branch can be implicitly determined via the repo.
-
Tim Jaacks authored
This makes it possible to integrate a project branch into different branches of the same manifest project.
-
- Jun 13, 2022
-
-
Tim Jaacks authored
BCS 746-000808
-
- May 24, 2022
-
-
Jonas Höppner authored
-
- May 20, 2022
-
-
Jonas Höppner authored
Prior to this change the integration stop when one of the projects had already the latest ref of gitlab-ci in to submodule.
-
- May 06, 2022
-
-
Jonas Höppner authored
The integration branch was reused even if there where new commits on the target branch, which could lead into reverting some changes. This adds a check, if the existing integration branch is directly based on the target branch and deletes it if not.
-
- Apr 12, 2022
-
-
Tim Jaacks authored
Rename variable JENKINSGUF_SSH_PRIVATE_KEY / SSH_PRIVATE_KEY to GITLAB_PRIVATE_KEY on this occasion, because it contains a private key that was generated exclusively for this use case. The according public key has been added as a deploy key in GitLab to all repositories that this repository needs access to. Add more detailed documentation concerning this configurationdirectly in the gitlab-ci files.
-
- Apr 01, 2022
-
-
Jonas Höppner authored
-
- Mar 31, 2022
-
-
Jonas Höppner authored
The deploy_gitlab_ci now creates the integration commit and branch in each passed subproject and create an integration commit in the manifest containing all these new revisions. A build is then triggered on this commit to test the functionality. Split the update_submodule functions to reuse them in different ways. Remove some previously used files. BCS 746-000740
-
- Mar 24, 2022
-
-
Jonas Höppner authored
-
Jonas Höppner authored
-
Jonas Höppner authored
As all projects are commited in the same branch the 'up-to-date' check may not only check if the first parent commit points to the master/dunfell branch. Now it is needed to loop through the history until the integration branch's commit is found. On fail a message is displayed which merge request needs to be retriggered manually. This can now also be the 'parent'-MR that triggered the complete chain. The check job is used pipeline again. The retrigger job also looks in the .gitlab-ci project for check jobs to retrigger.
-
Jonas Höppner authored
-
Jonas Höppner authored
Allow deploy_gitlab_ci to change multiple projects at once. Use it to create integration branches and merge requests in all projects. Add a python file to generate a job yml from jinja2 template. Add a template for the jobs to trigger. These execute the actual integration in all 'subprojects'. Create the yml file in the deploy job and trigger it in a new trigger job.
-
- Mar 18, 2022
-
-
Jonas Höppner authored
Add update gitlab-ci file with function to adapt the include ref to a given revision. Add a 'pre-commit-hook' to the update-submodule function. Adapt deploy_gitlab_ci to use these to update the include statement in the base project .gitlab-ci.yml to use the same ref as the submodule is set to. BCS 746-000646
-
- Mar 14, 2022
-
-
Jonas Höppner authored
This allows to increase the verbosity. Add --verbose in .gitlab-ci.yml when the python script is called to view the output in the jobs log.
-
- Mar 01, 2022
-
-
Tim Jaacks authored
-
- Dec 15, 2021
-
-
Tim Jaacks authored
Fix pylint errors introduced with new pylint version: * unspecified-encoding: explicitly set encoding when opening a file * assigning-non-slot: use "set_reference()" function instead of assigning a value to the "reference" attribute * unused-variable: remove "e" variable on exceptions when not referenced
-
- Jun 29, 2021
-
-
Tim Jaacks authored
If integration branch already existed and had to be replaced, the new commit was accidentally pushed on top of the already existing commit instead of replacing it. Fixed this by checking out the master branch again before creating the commit.
-
Tim Jaacks authored
The jobs in the deploy stage have to be triggered manually in GitLab. There is one deploy job for each project which uses the gitlab-ci scripts as a submodule, so that the deployment can be performed step by step. If executed within MR context, an integration MR is created and left open. The user can extend this integration MR, e.g. if CI scripts have been renamed, changed command line arguments or other changes requiring updates of the correspronding .gitlab-ci.yml file. Subsequent runs of this job will re-create the integration branch, so manual changes are lost in this case. If executed on the master branch (i.e. after the source MR has been merged), the job does exactly the same, plus the integration MR will be automatically merged. If this fails, the job will fail as well.
-