Gh PR checkmarks for triggered pipelines

Pipelines
1

We have a pipeline (A) that triggers another pipeline (B) via trigger step, but we only get the green/red flags for the jobs of the first pipeline (A). We get the flag for the trigger step itself (green/red according to pipeline B status), but it would be good to get the check marks for all the steps in pipeline B, like we get for all the pipelines that run when we create a PR.

I’ve looked under the gh app configs in personal settings, and also on the pipeline’s gh app config, but i can’t seem to find any option to get this result.

Is this possible at all?

Thanks in advance

2

Hey @zenogueira,

This is currently the intended behaviour.

When creating a PR or creating a commit, it will inject the variable BUILDKITE_COMMIT, which will be used to trigger the build with the expected git state. When triggering another pipeline, there would be no commit to track in this case, as it will trigger the default branch (unless you provide a branch/commit).

As such, when you trigger a pipeline, it will report back its overall state to the parent pipeline (providing you do not have async: true set on your trigger step) after a wait. If this triggered pipeline fails, the parent pipeline will report a failed state, too. This should also reflect on your GitHub checks.

To view the individual steps from Pipeline B in this case, you’d need to open up the status check and then click on the trigger job in question.

Best regards,

Joe

3

Are there any plans to implement this feature or something like it?

We went around the issue by generating empty builds if the pipeline wasn’t meant to be triggered in the first place, but now we always run pipeline B on every commit.

This yields the same result, but it’s not as clean as a proper integration

4

Hey :waving_hand: ,

Thanks for the follow-up. As my colleague explained, this is the expected behaviour. The reason for this is that the triggered pipeline is technically part of the build of the trigger pipeline.

As for the triggered pipeline, it still gets its own build failure or success status (red/green)—so I am unsure how you mean “but it would be good to get the check marks for all the steps in pipeline B” here. To check this status, you would have to click on the triggered job which will take you there.

5

I am unsure how you mean “but it would be good to get the check marks for all the steps in pipeline B”

Sorry, i didn’t explain myself properly. The whole question is about the github checks integration.

The ideal scenario would be to have GitHub show green/red checks for each step in the triggered pipeline, along with those for the original pipeline (A, in this example) when the trigger isn’t asynchronous.

6

Hey @zenogueira,

Currently, you can follow our Feature Roadmap here, which should outline our current direction.

In regard to the GitHub checks as you’ve requested, there’s currently no plans to move towards it in such a way.

Could you better describe to use-case here for us to understand why this would be better vs relying on the overall status of the triggering pipeline to be reported back? One concern I’d have here would be with the noise that could be created from listing each individual steps, specifically when it’s a private pipeline on a public respository.

7

To follow-up on this, if both pipelines are from the same repository, you should be able to achieve this with the following within your trigger step:

- trigger: "app-sub-pipeline"
  label: "Sub-pipeline"
  build:
    message: "${BUILDKITE_MESSAGE}"
    commit: "${BUILDKITE_COMMIT}"
    branch: "${BUILDKITE_BRANCH}"
    env:
      BUILDKITE_PULL_REQUEST: "${BUILDKITE_PULL_REQUEST}"
      BUILDKITE_PULL_REQUEST_BASE_BRANCH: "${BUILDKITE_PULL_REQUEST_BASE_BRANCH}"
      BUILDKITE_PULL_REQUEST_REPO: "${BUILDKITE_PULL_REQUEST_REPO}"

If you are declaring your pipeline.yml within the steps builder, you’d need to expand variables from a single $ to $$.