Integrate gitlab-ci/revert-trigger-pipeline and 8 more
deploy_gitlab_ci: revert trigger pipeline on integration branch
Explicitly triggering a pipeline in the target repository does not work easily from this place because we would have to distinguish between the manifest (which uses branch pipelines) and the sub-projects (which use merge request pipelines). This separation should not be hard-coded here, so we move the decision whether or not to run a pipeline to the .gitlab-ci.yml file of the target. Reverting these two commits:
63279799336fa99bb8bbb908084017173ed44802 deploy_gitlab_ci: trigger pipeline only if it has not run before
dfc6204abcdfce7f7ee51ee2127500f8aecfaafa deploy_gitlab_ci: trigger pipeline on integration branch
--
md5: Fixed invalid encoding in open
--
deploy_gitlab_ci: trigger pipeline only if it has not run before
--
wait_until_merge_status_is_set: always query merge request
The function used to rely on the given merge request object without checking its current state. If the given object was not in one of the "unchecked" states, it returned immediately. The state, however, could have changed between its last query and the call of this function, so it now checks the state first before deciding anything.
--
deploy_gitlab_ci: trigger pipeline on integration branch
--
gitlab-ci: upgrade python image to 3.9
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
--
accept_merge_request: explicitly remove source branch
A bug in python-gitlab > 2.7.0 1 brought this up: In the past we relied on the merge request's setting, whether the source branch should be deleted or not after a merge. Since we're using the API's merge function in a fully automated task, however, the branch should always be deleted. Add the according argument explicitly.
--
accept_merge_request: refactoring
- Combine two return statements into one.
- Switch if statement order to remove else branch.
--
gitlab-ci: update bool values to YAML 1.2 spec
The outdated YAML 1.1 specification allowed values like 'yes' or 'no' for boolean fields 1. The newer spec 1.2 allows only 'true' and 'false' 2, so we update them to be conform with it.