Gocd: Bug in trigger with options

[arvindsv]

Issue Type

• Bug Report

Summary

Basic environment details

• Go Version: 18.2.0 (latest code)
• JAVA Version: 1.8.0_144
• OS: Mac OS X 10.13.3
• Browser vendor and version (if relevant): Firefox 58

Steps to reproduce:

1. Intialize a couple of git repos:

(mkdir /tmp/test.git; cd /tmp/test.git; git init; date >>hello; git add hello && git commit -m "$(date)")
(mkdir /tmp/test2.git; cd /tmp/test2.git; git init; date >>hello; git add hello && git commit -m "$(date)")

1. Use a config such as this:

<pipeline name="Test">
  <materials>
    <git url="/tmp/test.git" dest="abc" autoUpdate="false" />
    <git url="/tmp/test2.git" dest="def" autoUpdate="false" />
  </materials>
  <stage name="defaultStage">
    <jobs>
      <job name="defaultJob">
        <tasks>
          <exec command="ls" />
        </tasks>
      </job>
    </jobs>
  </stage>
</pipeline>

1. Force trigger (auto update is off):

Result: Everything goes fine. The commit in each repo is seen.

1. Make two more commits:

(cd /tmp/test.git; date >>hello; git add hello && git commit -m "$(date)")
(cd /tmp/test2.git; date >>hello; git add hello && git commit -m "$(date)")

Scenario 1:

1. Use trigger with options:

Don't select any material revisions. You will see the old commits in the dropdown, since polling is turned off. That's ok.

Trigger.

Expected Results

Triggers once with the newest commits.

Actual Results

The pipeline triggers twice. Once with the old commits and once with the newest commits.

Scenario 2:

1. Change auto update to true and make the pipeline manual.

<pipeline name="Test">
  <materials>
    <git url="/tmp/test.git" dest="abc" />
    <git url="/tmp/test2.git" dest="def" />
  </materials>
  <stage name="defaultStage">
    <approval type="manual" />
    <jobs>
      <job name="defaultJob">
        <tasks>
          <exec command="ls" />
        </tasks>
      </job>
    </jobs>
  </stage>
</pipeline>

1. Use trigger with options:

Don't select any material revisions. You will see the new commits, since polling is turned on.

Trigger.

Expected Results

Triggers once with the new commits.

Actual Results

The pipeline triggers once with the old commits (from previous run).

Extra info:

This is what gets sent as a part of the params to the schedule call:

authenticity_token: something
material_fingerprint[fingerprint_of_material_1]:
material_fingerprint[fingerprint_of_material_2]:
original_fingerprint[fingerprint_of_material_1]:

[jyotisingh]

@arvindsv - The issue you mentioned in scenario 1 has existed for as long as I can remember, not something new introduced in 18.2. Basically, if you do not select a new revision, the UI picks the revisions that you last ran the pipeline with - this is expected behavior. However, there is a side effect that it triggers a MDU for the materials associated. Unless the materials are blacklisted, the pipeline would trigger again with the new revisions.
Scenario 2 is the expected behavior - I don't remember the reasoning for it, but I can look up for the old mingle card for that.

[arvindsv]

I see. So, what you're saying is: If nothing is selected, then the previously run materials will be picked up for running. It probably deserves to be made more clear in the UI, for a start.

I guess scenario 2 is the same then. It runs with the previously run materials, and does not force a material check, since auto update is on.

Hmm. We need to make that more clear and provide a way to force the latest, then. The documentation around the schedule API suggests that it picks the latest materials if no material revisions are chosen.

[varshavaradarajan]

Related: https://github.com/gocd/gocd/issues/3449 - for scenario 2.

[jyotisingh]

The schedule-api documents it that way coz that's how it works, it's what 'trigger' uses. Trigger-with-options ui does some fancy stuff to pass along the revisions that the pipeline previously ran with - it used the same API but you would see revisions for all the materials set in the request. Those are overridden only if the user explicitly picks a revision. This behavior is very specific to the UI. This can be changed if the reasons for existing behavior doesn't make sense to us. I will try to find a bit more about it tomorrow.

[arvindsv]

Yes, you're right. I verified that, with this setup, doing this (below) in quick succession will always trigger with the latest:

date >>hello; git add hello && git commit -m "$(date)"
curl 'http://localhost:8153/go/api/pipelines/Test/schedule' -H 'Confirm: true' -X POST

That does make it a little less severe an issue. It's only the UI that's a problem.

[rajiesh]

Closing in favor of #3449