Open KekSfabrik opened 7 years ago
@KekSfabrik there are a couple of other issues filed about ci-skip, which is making me think that our implementation of it has some bugs. But it's not a workflow I use and I don't have a lot of free time to test/reproduce things right now.
Can you confirm if a workflow similar to what you've described works with other job types, such as regular Pipeline or Freestyle?
@omehegan can confirm it works with "regular" pipeline
job (with the same Jenkinsfile on the same repo) but not multibranch pipeline (haven't tested with a freestyle job but i'd guess that works aswell)
this shows up in jenkins.log:
Feb 03, 2017 1:04:30 PM com.dabsquared.gitlabjenkins.webhook.GitLabWebHook getDynamic
INFO: WebHook called with url: /project/pipeline-test
Feb 03, 2017 1:04:30 PM com.dabsquared.gitlabjenkins.trigger.handler.AbstractWebHookTriggerHandler handle
INFO: Skipping due to ci-skip.
Hi, we're facing this issue too - the scenario is when we automate release processes e.g. with the maven unleash plugin. This will update the next development version - and we can configure it to include [ci-skip] in the comment - but it is still ignored.
Also tested the [ci-skip] in a non multi branch project in the same Jenkins instance and it skips the build with the log @KekSfabrik mentioned above.
Is this bug scheduled to be looked at soon?
I think I just realized why this doesn't work. It's because the plugin ignores the JSON payload when it's sent to multibranch jobs. See the note at https://github.com/jenkinsci/gitlab-plugin#pipeline-multibranch-jobs I would like to find a way to fix this, but I didn't author the multibranch support.
Hey all,
Was there any update on this issue? We're facing the same problem, and it's painful to handle the auto-triggered builds avec a maven release step (maven commits back to the repo with a tag and next dev version).
Thanks
We are also struggling with this. This is preventing us from having Jenkins update some of the metadata in the repo and pushing it back to gitlab without creating an infinite build loop.
We are observing the same behaviour. After digging into code we've found a wrong code block in com/dabsquared/gitlabjenkins/trigger/handler/pipeline/PipelineHookTriggerHandlerImpl.java:59
if (ciSkip && isCiSkip(hook)) { LOGGER.log(Level.INFO, "Skipping due to ci-skip."); return; } .... @Override protected boolean isCiSkip(PipelineHook hook) { //we don't get a commit message or suchlike that could contain ci-skip return false; }
Because isCiSkip() will always return false, then the (ciSkip && isCiSkip(hook)) is always false, thus the pipeline is always started.
Same is true for com/dabsquared/gitlabjenkins/trigger/handler/AbstractWebHookTriggerHandler.java:43
If "[ci-skip]" tag is not present, then the ciSkip flag is ignored.
Simply changing from "ciSkip && isCiSkip(hook)" to "ciSkip || isCiSkip(hook)" makes it work properly.
Any news on that?
May be we have news now?
Issue
Multibranch Pipelines ignore the ciSkip field and trigger themselves if they push changes back to GitLab
Context
Logs & Traces
Problem description
After the
git push
instruction a new Build is triggered which should be ignored because of the[ci-skip]
bit in the commit message yet it's executed like it weren't there.Possible other problem
A (possibly completely unrelated) Problem is that the jenkins.log is filled with this sort of stuff:
that is probably because i use
gitlabCommitStatus
over my entirenode
block and have a customstage
block that wrapsupdateGitlabCommitStatus
around the code