[Feature request] API general pipeline status

Hans Dampf

unread,

Jun 7, 2024, 6:53:31 AMJun 7

to go-cd

Hi,

it would be great if the api request on /go/api/pipelines/<pipeline>/<counter> would have a general pipeline status.

The stage have one, but it would be alot easier to work with if the last status is access able on the toplevel. Currently, you have to parse all stages to get the pipeline status.

Currently :

{
  "name" : "Pipeline 1",
  "counter" : 2641,
  "label" : "2641",
  "natural_order" : 2641.0,
  "can_run" : true,
  "preparing_to_schedule" : false,
  "comment" : null,
  "scheduled_date" : 1717756828914,
  "build_cause" : {
    "trigger_message" : "User",
    "trigger_forced" : true,
    "approver" : "User",
    "material_revisions" : [ {
      "changed" : false,
      "material" : {
...      },
      "modifications" : [ {
...      } ]
    } ]
  },
  "stages" : [ {
    "result" : "Passed",
    "status" : "Passed",
...    } ]
  }, {
    "result" : "Unknown",
    "status" : "Building",
...    } ]
  } ]
}

Changed:

{
  "name" : "Pipeline 1",
  >>>  "status" : "Building", <<<<<
  "counter" : 2641,
  "label" : "2641",
  "natural_order" : 2641.0,
  "can_run" : true,
  "preparing_to_schedule" : false,
  "comment" : null,
  "scheduled_date" : 1717756828914,
  "build_cause" : {
    "trigger_message" : "User",
    "trigger_forced" : true,
    "approver" : "User",
    "material_revisions" : [ {
      "changed" : false,
      "material" : {
...      },
      "modifications" : [ {
...      } ]
    } ]
  },
  "stages" : [ {
    "result" : "Passed",
    "status" : "Passed",
...    } ]
  }, {
    "result" : "Unknown",
    "status" : "Building",
...    } ]
  } ]
}

Regards

Ashwanth Kumar

unread,

Jun 7, 2024, 7:34:22 AMJun 7

to go...@googlegroups.com

It is not possible because the definition of pipeline level status can vary from one person to another.

For instance, the 2nd stage could be validation that I don't care much as long as the 3rd stage is green (after manually approving it) and things like that. Ideally you only want to check the status of the stage you're interested in rather than the entire pipeline. This is how the pipeline dependencies also work.

Hope this helps.

Thanks,

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/031c7115-4290-40ff-8646-e9976b08fd6en%40googlegroups.com.

Chad Wilson

unread,

Jun 7, 2024, 7:44:26 AMJun 7

to go...@googlegroups.com

Yeah, as Ashwanth mentions, this doesn't currently exist, probably because it's somewhat indeterministic. GoCD does not rigidly define what "success" means for a pipeline - that is up to the user in how they compose from stages.

e.g

- subsequent stages can sometimes allow manual triggering even if a previous stage failed

- is a pipeline successful if it has 3 passed automatic stages and then 1 manual stage afterwards not yet triggered? or is it in progress?

- a separate pipeline can be triggered by a stage part-way through an earlier pipeline, even if the later stages of that pipeline failed. It could be confusing to consider the earlier pipeline "failed", and "success" may also be misleading.

There is discussion on these lines at https://groups.google.com/g/go-cd/c/vhJVoOYqNCI/m/I5ufd0EQAgAJ and probably elsewhere.

The dashboard filters are the only places I can think of that express an opinion on such things, and do so rather simplistically by only looking at the status of the latest stage instance that has been triggered with a status other than "Unknown" and considering that. Due to this opinionated nature they will sometimes filter pipelines that arguably should not - perhaps OK for a user-driven filter view, but not really for an API.

If we were to consider this, I think it'd need to be multiple fields that are calculated by different mechansisms, e.g "status_by_last_triggered_stage" alongside "status_by_all_triggered_stages" and "status_by_all_configured_stages" and "status_by_last_configured_stage" -- multiplied x2n if you want "result" as well. It'd get messy fast and maybe better to just let people look at the stage array themselves ....

-Chad

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAD9m7CzxHFe6NqEpFYMhSqPO5TZnFqfajfeA4K98-aA9h%3DXgSg%40mail.gmail.com.

Reply all

Reply to author

Forward