`[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