[ci skip] not respected

[flawedmatrix]

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

[concourse-bot]

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:

• #107331382 [ci skip] not respected

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[xoebus]

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.

[MatthiasWinzeler]

@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?

[xoebus]

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

[MatthiasWinzeler]

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.

[MatthiasWinzeler]

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>
    ...

[krishicks]

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.

[xoebus]

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 ***@***.***> 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.

[krishicks]

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.

[youngm]

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.

[xoebus]

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

[youngm]

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>
    ...

[giner]

Can we reopen this issue? This is still a problem which requires workaround.

[dazigna]

@giner I have the same issue, and this is a major set back. Any progress on it?

[chrishiestand]

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

[swtch1]

I have "re-opened" the issue on 221.

[jacek-rzrz]

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