Roman Azarenko (73750b51) at 20 Dec 13:58
Update common image version
Vivek Kumar Dutta (73750b51) at 20 Dec 13:57
Roman Azarenko (73750b51) at 20 Dec 13:57
Update common image version
We've agreed for now that it's okay that the pipeline displays "$COMPILE
is undefined. In this case I'm okay with this change.
Thanks @roman.azarenko, for the detailed explanation and examples!
Lets go through the use cases we want to cover, idea here is to detect and provide an early feedback to the user.
If we define workflow in the template, then that workflow will be available for all ci/cd stages defined in repos.
If we define rules in static analysis stages, then we are only considering the statics analysis stages for the merge pipeline.
Now, if we consider my change, it removes the 'rule' and usages if [ -n "${COMPILE}" ]; then ${COMPILE}; fi
in 'script' directly, which means merge pipeline will run the branch pipeline, right?
Here's an example of the workflow-based autoswitching: roman.azarenko/branch-vs-mr-pipeline!3 (closed)
The issue with that is, the template user can redefine the workflow
, and we're likely back to square one.
Not quite.
rules
for a job, that job will not run in a merge request pipeline (see https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html#use-rules-to-add-jobs).workflow:rules
.I made a demo repo (roman.azarenko/branch-vs-mr-pipeline>) to demonstrate the behaviour:
rules
section and it doesn't prohibit running for MR pipelines, an MR pipeline will run, and only those jobs will run in the MR pipeline: roman.azarenko/branch-vs-mr-pipeline!1 (closed)
rules
section, and you don't have an explicit workflow:rules
, no MR pipeline will spawn, and the MR will display the results of a branch pipeline instead: roman.azarenko/branch-vs-mr-pipeline!2 (closed)
I see one problem with this approach. Given that we're working on a template, if the including CI file defines any MR-pipeline-eligible job, or defines the relevant workflow:rules
, an MR pipeline will spawn, $CI_PIPELINE_SOURCE == "merge_request_event"
will evaluate to true
, and that job won't run in the resulting MR pipeline.
The "solution" would be to define a workflow
in the template, either prohibiting MR pipelines altogether, or automatically switching to MR pipelines when an MR is open for that branch. The latter could be an interesting option, as long as we're okay with defining the workflow for the whole pipeline from a static analysis template, which doesn't sound like the best idea abstraction-wise.
References:
does this mean, that the compilation test won't be running in merge request?
@vivek.dutta Can we do this instead?
script:
- "${COMPILE}"
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: never
- if: $COMPILE
This should prevent running a dedicated MR pipeline altogether, the branch pipeline will be used instead.
Seems to be related to a difference in "branch pipelines" vs "merge request pipelines". I see that all jobs run in branch pipelines, but MR pipelines only include the run_compilation_test
job. Ideally we don't want to run a separate MR pipeline at all, a branch pipeline should cover all the necessary jobs by default.
This is likely due to the rules
section in that job, I'm investigating the effects of that atm. This would explain why a separate MR pipeline spawns, but it doesn't explain why only one of the three jobs runs there.
Your suggested change has a problem that I had the test team complain about in relation to system testing: if $COMPILE
is undefined, this job would be marked as "passed", even though it didn't run anything.
If I can't figure out the MR pipeline thing, my suggested alternative would be: if $COMPILE
is undefined, exit with a fixed known exit code, and add that to allow_failure:exit_codes
.
Great, thanks!
Hi @roman.azarenko,
I updated the tag to 0.32, please check
Vivek Kumar Dutta (ff2863cc) at 11 Dec 13:11
Update common image version
yes, sure. Is it possible to use the same version tag as its been referenced in include
include:
- project: 'iopsys/gitlab-ci-pipeline'
file: '/static-code-analysis.yml'
ref: '0.31'
currently its hard coded, so it requires to be updated manually.
I think, because of when: always condition, sometimes it only executes compilation test and skip the rest of the tests if defined, example: https://dev.iopsys.eu/voice/tr104/-/jobs/353678
0.31
is an existing tag, and there has been two commits on top of that, maybe it makes sense to tag a 0.32
then?
Can you explain this change, please? What does this fix?