Closed flawedmatrix closed 8 years ago
Hi there!
We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.
The current status is as follows:
[ci skip]
not respectedThis comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.
IIRC this was caused by the commit being created from a put
step which skips that check. Please re-open if this was not the case.
@xoebus Can you clarify this for others running into the same problem - so if a commit with [ci skip]
is pushed from a put
step, it will still trigger other jobs (when defined as trigger there)?
I have a job that triggers from a certain repo, does some changes to the repo and then commits & pushes these changes back to the repo. Because the push triggers again, I'm caught in an endless loop. I tried with [ci skip]
in the commit message, but the job still triggers.
Do you know a solution for this? Should I somehow use ignore-paths
?
Try pushing to a different but identically configured resource.
On Apr 12, 2016, at 08:46, Matthias Winzeler notifications@github.com wrote:
@xoebus Can you clarify this for others running into the same problem - so if a commit with [ci skip] is pushed from a put step, it will still trigger other jobs (when defined as trigger there)?
I have a job that triggers from a certain repo, does some changes to the repo and then commits & pushes these changes back to the repo. Because the push triggers again, I'm caught in an endless loop. I tried with [ci skip] in the commit message, but the job still triggers.
Do you know a solution for this? Should I somehow use ignore-paths?
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub
Thanks, that did the trick!
How the relevant parts of my working pipeline look like:
jobs:
- name: create boshrelease
public: false
serial: true
plan:
...
- get: boshrelease-trigger
trigger: true
...
- task: create-final-boshrelease
...
- put: boshrelease-put
params:
repository: boshrelease-repo-output
rebase: true
...
resources:
- name: boshrelease-put
type: git-resource
source:
uri: <boshrelease-repo-url>
...
- name: boshrelease-trigger
type: git-resource
source:
uri: <boshrelease-repo-url>
...
Note that the task
copies the modified repo from the input
to boshrelease-repo-output
which the put
then uses.
I found out that with the above solution, triggering the job manually after a successful run will fail. This is because boshrelease-put
will commit and push the change with [ci skip]
which the separate boshrelease-trigger
resource will not pick up. When a manual job is triggered now, the last commit will not exist in boshrelease-trigger
and the put at the end of the job fails because of a merge conflict.
To solve this, I include the resource we're pushing boshrelease-put
also as get
. This repo will contain the latest commits and serves as starting repo for the new changes. boshrelease-trigger
is only used for triggering and is no longer used by the jobs.
My final job looks like this:
jobs:
- name: create boshrelease
public: false
serial: true
plan:
...
- get: boshrelease-trigger
trigger: true
- get: boshrelease-put
...
- task: create-final-boshrelease
...
- put: boshrelease-put
params:
repository: boshrelease-repo-output
rebase: true
...
resources:
- name: boshrelease-put
type: git-resource
source:
uri: <boshrelease-repo-url>
...
- name: boshrelease-trigger
type: git-resource
source:
uri: <boshrelease-repo-url>
...
I don't like this solution because it is not obvious that Concourse will in some cases disregard the rules that the user has configured on a resource.
I have configured a resource such that new resources should not be discovered given it is tagged as such. Still, Concourse decides to ignore that rule when doing a dependent get, which isn't what I want in any case here.
This is a not-easily-discoverable bug.
This behavior is core to how Concourse reasons about the semantics of streams of resource versions flowing through a pipeline.
I would advise against any use of [ci skip]
. It leads to nonsense and headaches that resemble the need for a disable_ci_skip
parameter.
On Mar 14, 2017, at 16:46, krishicks notifications@github.com wrote:
I don't like this solution because it is not obvious that Concourse will in some cases disregard the rules that the user has configured on a resource.
I have configured a resource such that new resources should not be discovered given it is tagged as such. Still, Concourse decides to ignore that rule when doing a dependent get, which isn't what I want in any case here.
This is a not-easily-discoverable bug.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
The headache here was me discovering that I have to configure an additional resource to model this, and that it leaves me in a state where I'm using a hack to achieve my goal.
I want to be able to say in a very clear way that an arbitrary put
is put-only, i.e. no dependent get. Having to define a separate resource for that is unfortunate because this secondary resource can be used as a get
resource when that is not what I want to describe.
I attempted to follow the final pattern put forth by @MatthiasWinzeler and that didn't work for me because the triggered resource version frequently came up as different than the non triggered version. So, if I committed new code the trigger would detect the commit but the non triggered that I was supposed to be using wouldn't have the same commit version. I assume this is because of differences in check cycle. So, this isn't a viable workaround for me.
Although I no longer work on the Concourse team I want to apologize for the curt answers I gave above.
The behavior is confusing but at the moment put
is defined as always creating a new version which sidesteps the filter on the get
. Maybe this could be addressed in the new version of the resource interface? /cc @vito
FWIW, I worked around my latest issue by doing a pull and a push back as the first step in my triggered job. Which works for me because I only want [ci skip] to skip auto triggered builds. We'll see how long this hack works. Probably not long since this issue seems to be a pretty big rat hole. :)
So here is the pseudo config for what worked for me in case it is useful for anyone else:
jobs:
- name: create boshrelease
public: false
serial: true
plan:
...
- get: boshrelease
trigger: true
- task: pull-latest-boshrelease
config:
platform: linux
image_resource:
type: docker-image
source:
repository: alpine/git
inputs:
- name: boshrelease
outputs:
- name: boshrelease-latest
run:
path: sh
args:
- -exc
- |
cd boshrelease
git pull
cd ..
git clone boshrelease boshrelease-latest
- put: boshrelease
params:
repository: boshrelease-latest
...
- task: create-final-boshrelease
...
- put: boshrelease-put
params:
repository: boshrelease-repo-output
rebase: true
...
resources:
- name: boshrelease
type: git-resource
source:
uri: <boshrelease-repo-url>
...
- name: boshrelease-put
type: git-resource
source:
uri: <boshrelease-repo-url>
...
Can we reopen this issue? This is still a problem which requires workaround.
@giner I have the same issue, and this is a major set back. Any progress on it?
I'm having a problem with one pipeline not respecting [ci skip]
, even though a nearly identical pipeline does seem to respect it. However my issue is with only a single job in the build/pipeline, and a single git resource, so I'm not sure if it is related to this issue.
More details about my problem (help requested please) here: https://discuss.concourse-ci.org/t/git-resource-infinite-loop-with-ci-skip/524
For those still running into this issue now: @MatthiasWinzeler workaround of introducing a separate put
resource does work, however I learned the hard way that put
and trigger
resource configurations mustn't be identical.
When they are identical, resource cache treats them as one resource, resulting in an unconditional new version of the trigger resource on each put 😤.
So for example:
- name: repo-trigger
type: git
source: &git
uri: git@github.com:example/example.git
private_key: ((deploy-key))
branch: main
- name: repo-put
type: git
source:
<<: *git
ignore_paths: [ make-it-different ] # this is the magic line
commits with
[ci skip]
are now showing up inside our git resources and triggering builds looking at the repo in question is public should allow reproduction of the issue.Local git version:
git version 2.5.0
Version of git inside container which made commit:git version 1.9.1