Skip to content

WIP: Add compatibility for GitHub Required Status Checks by using fixed context

James Edwards-Jones requested to merge jej/github-status-checks-used-fixed-context-so-success-can-be-required-6696 into master

What

Sets the context of GitHub status updates to gitlab/ci instead of gitlab/ci/#{refname}.

Why

A large percentage of users of the GitHub integration will want to require a successful pipeline before merging pull requests. Because GitHub requires users to specify which context to block on it can not be something that varies by branch.

Related

Closes #6696 (moved), see issue for discussion

Drawbacks

This change in behaviour will mean that in some cases status get overwritten. If CI is configured to run different jobs for certain branches or when running for a tag then one pipeline may pass while another fails. The status will be overwritten when the later pipeline completes.

Examples:

  1. After the pull request is merged a deploy job that only runs on master is triggered and fails. The old pull request would then be updated with a failed status despite having passed tests.
  2. Branches matching *-docs are configured to skip most tests and only run documentation linting. If two branches point to the same commit and the second was named add-additional-feature-docs then the pipeline run for the docs could cause the main pull request to be marked as passing even if other tests fail.

Alternatives

  • We could have a checkbox to specify if the context is fixed. Before thinking about this in depth I'm not sure I'd have understood the above edge cases, and wouldn't have known to change this setting, so most users might just find this confusing. Additionally we might want a solution for the above edge cases that can be used alongside Required Status Checks.
  • We could send multiple statuses, one with the fixed context and one with the refname so users can distinguish between different pipeline runs. This might be something we consider in a later iteration, or as more designed move to multiple statuses. The refname status might only be needed if there have been multiple runs for a given commit.
  • We could send statuses per job or per pipeline stage, so gitlab/ci/rspec could be required to pass. Since users might still want to block on the entire pipeline passing we'd probably still want a fixed context in addition.

Overall I think this simple change is a good first fix we'd follow up with a second iteration design to cover the edge cases.

Does this MR meet the acceptance criteria?

Edited by James Edwards-Jones

Merge request reports