How to display a pipeline status from a different repository in the GitHub "All checks have passed" window?

[liviutomo]

Select Topic Area

Question

Body

I would like to know if there’s a way to link the status of an Azure Pipeline from a different repository to a common check status window in GitHub.

Here’s the scenario:

Pipeline A runs first → it builds and generates artifacts (binaries of component A).

Pipeline B is then triggered, consuming the artifacts produced by Pipeline A.

I would like the results from both pipelines to be displayed together in the GitHub repository of Pipeline A, under the “All checks have passed” status window.

Has anyone implemented something similar?
Would this typically be achieved using pipeline resources, service connections, or by leveraging the GitHub Checks API?
I’m looking for recommended approaches or best practices to set this up.

[Devangdaksh]

Key Points and Recommended Approaches

• Integration via Azure Pipelines + GitHub Checks API: When an Azure Pipeline is linked to a GitHub repository, it can automatically report its build status to GitHub using the GitHub Checks or Status API. This results in a visible status for each pipeline job in your GitHub PR and commits, under the “checks” section. You can set up branch protection rules to require these checks, ensuring that merges only happen after all pipelines succeed.

• Multiple Pipelines Reporting: If you want both Pipeline A and B (possibly from different Azure DevOps organizations or repositories) to show up as required checks for a PR in Repo A, both need to be set up to post their statuses to Repo A’s PRs using the GitHub Status/Checks API. This is typically done by:

  • Triggering the pipelines using GitHub webhooks or events.
  • Making sure each pipeline is configured to report results back to the target GitHub repo using the correct API.
  • You can aggregate multiple pipeline results so that all show in one status window in GitHub. The badge or status displayed is the aggregate of all reporting pipelines.

• Pipeline Resources and Service Connections: Pipeline resources in Azure Pipelines let you orchestrate multi-stage builds where artifacts produced by one pipeline can trigger jobs in another. Service connections are used to securely link Azure DevOps with GitHub, enabling status posting. However, these by themselves don’t automatically aggregate check status: you must configure each pipeline to report back to the correct GitHub repo.

• Best Practice: Use GitHub Status/Checks API Directly for Custom Scenarios: If you want full control over aggregation, especially when combining results from pipelines spanning different repos or organizations, consider building a small service (or use an existing GitHub App) that listens for pipeline completion events (e.g., via Azure DevOps webhooks), collects statuses from both Pipeline A and B, and updates the common “All checks” window in GitHub using the Checks/Status API. This is especially useful if pipelines don’t natively report to the same repo.

Implementation Steps

1. Configure Each Pipeline to Report Status to GitHub:

   • In Azure DevOps, set up your pipelines so each one reports build status to the target GitHub repo using Checks/status.
   • This may require service connections or authorizing Azure DevOps to post to GitHub.

2. Orchestrate Pipeline Runs Using Pipeline Resources:

   • Pipeline B triggers after Pipeline A completes, consuming its artifacts.
   • Both pipelines can be independent, but must be configured to post their final status to GitHub.

3. GitHub Side:

   • Ensure the GitHub repository’s branch protection rules require all desired checks (you can select which ones).
   • If you have many pipelines (across many projects/repos), you might want an automated or dynamic selection mechanism for required checks.

4. (Optional) Use GitHub Checks API Directly for Aggregation:

   • For more complex, cross-repo, nested, or dynamic check scenarios, use the GitHub Checks API to create custom status checks that aggregate results from multiple pipelines/services.
   • This typically involves building a small integration service or using a GitHub App.

Best Practices

• Ensure all pipelines report status to the correct GitHub repo.
• Use branch protection policies so that merges are only allowed when all required status checks (reported by both pipelines) “pass.”
• For advanced or custom aggregation across multiple repositories or external CI/CD systems, leverage the GitHub Status/Checks API directly.

You don’t have to use pipeline resources or service connections to aggregate status, though they help with artifact sharing and triggering; reporting aggregation is controlled by your status check configuration and API usage.

In summary, the recommended, maintainable approach is:

• Configure each pipeline to report its status using the GitHub Checks/Status API to the same repository,
• Use branch protection in GitHub to enforce the desired checks,
• For complex needs, aggregate externally using the GitHub Checks API.

[Devangdaksh]

✅ Key Constraints

• GitHub checks (and statuses) are attached to a commit SHA, not to a branch or a build in general.
• Each Azure Pipeline can update GitHub commit status using Azure DevOps GitHub integration or via the GitHub Checks API.
• If Pipeline B runs in a different repo or on a different commit, its status will not automatically show under Pipeline A's commit unless you explicitly push a status update to that commit SHA.

---

✅ Recommended Approaches

1. Use the GitHub Checks API or Status API

• Both pipelines can post status checks to the same commit SHA in the GitHub repo for Pipeline A.

• Pipeline A naturally reports its status when it runs.

• Pipeline B (even from a different repository or project) can call:

  POST /repos/{owner}/{repo}/statuses/{sha}
  

  with a custom context like pipeline-b/integration.

• This requires:

  • A GitHub token with repo:status or checks:write scope.
  • A script in Pipeline B to send the status back to GitHub for the commit in Repo A.

Example using curl for Status API:

curl -X POST \
-H "Authorization: token $GITHUB_TOKEN" \
-H "Accept: application/vnd.github.v3+json" \
https://api.github.com/repos/foomakers/pair/statuses/<commit-sha> \
-d '{
  "state": "success",
  "context": "pipeline-b/integration",
  "description": "Pipeline B completed successfully",
  "target_url": "https://dev.azure.com/org/project/_build/results?buildId=123"
}'

Pros:

• Full control over how many checks you add.
• Both pipelines appear under “All checks have passed” for the same commit.

Cons:

• Requires custom scripting + GitHub token in Pipeline B.

---

2. Use Azure DevOps GitHub App integration with multi-pipeline reporting

• If both pipelines are connected to the same GitHub repo through Azure DevOps GitHub App and you configure the same commit SHA, Azure Pipelines can automatically report multiple checks to GitHub.
• However, this only works if both pipelines are triggered by the same commit (same GitHub repo).
• If Pipeline B belongs to a different repo and doesn’t share the same SHA, this won’t work automatically.

---

3. Aggregate Pipeline Strategy

• Create a meta-pipeline (Pipeline C) that:

  • Depends on both Pipeline A and Pipeline B (via pipeline resources in YAML).
  • Runs after both are done.
  • Reports a single combined check to GitHub (like integration-suite).

• In GitHub, you’ll see one check for the meta-pipeline instead of two separate ones.

• This is cleaner for branch protection rules (one check instead of many).

YAML example:

resources:
  pipelines:
    - pipeline: pipelineA
      source: PipelineA
      trigger: true
    - pipeline: pipelineB
      source: PipelineB
      trigger: true

jobs:
- job: aggregate
  steps:
    - script: echo "Both pipelines succeeded"

Pros:

• Simpler GitHub configuration.
• No need for custom GitHub API calls.

Cons:

• You lose granularity (just one combined check instead of two).

---

4. Combination Approach (Best Practice)

• Keep both pipelines independent.
• Report individual statuses for each pipeline using GitHub Status API.
• Optionally add an aggregate pipeline for a combined status if you want a single “gate” for branch policies.

---

✅ Best Practice

If the goal is clear visibility in GitHub and strict branch protection, go with Approach #1 (GitHub Status API). It gives you:

• Separate checks for each pipeline.
• Ability to enforce required checks (Pipeline A, Pipeline B).
• Direct links from GitHub to Azure Pipelines.

[liviutomoiaga]

Hi – thanks for your response.
I went with an integration approach using Azure Pipelines + the GitHub Checks API.

• The status of Pipeline A is reported to the “All checks have passed” window through the native Azure Pipelines integration.

• For Pipeline B, I used a cURL POST request to publish the necessary information directly into the checks window.

Since I’m leveraging the resources feature, I was able to retrieve all the required details from Pipeline/Repo A (such as the owner, repository name, and commit SHA) to populate the URL variables.

resources:
  pipelines:
  - pipeline: triggerd-by-dummy-main-pipeline 
    source: dummy.master
    project: Playground
    trigger: true

- bash: |
    SRC="$(resources.pipeline.triggerd-by-dummy-main-pipeline.pipelineName)"
    echo "Pipeline name from resources: $SRC"
    IFS='.' read -r OWNER REPO <<< "$SRC"
    echo "Owner=$OWNER"
    echo "Repo=$REPO"
    echo "##vso[task.setvariable variable=OWNER]$OWNER"
    echo "##vso[task.setvariable variable=REPO]$REPO"

curl -sS -X POST \
          -H "Accept: application/vnd.github.v3+json" \
          -H "Authorization: Bearer $GITHUB_PAT" \
          "https://api.github.com/repos/${OWNER}/${REPO}/statuses/$(resources.pipeline.triggerd-by-dummy-main-pipeline.sourceCommit)" \
          -d "{
            \"state\": \"$STATE\",
            \"target_url\": \"$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_build/results?buildId=$(Build.BuildId)\",
            \"description\": \"$DESC\",
            \"context\": \"$(Build.DefinitionName)\"
          }"

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬