Skip to content

CI Pipeline Subscriptions without tags

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Enable the execution of subscribed CI pipelines on subscriber repositories without tags being created on the upstream/subscribed repository.

Problem to solve

As a user creating subscribed CI jobs, I want to create CI job subscriptions without requiring tags on the subscribed repository, so I can execute subscribed CI jobs on any commit, regardless of whether or not the commit had an associated new tag. Specifically, being able to run a subscribed CI job whenever a mirrored repository is updated.

Current behavior

Upstream projects should run pipelines on tags in order for downstream projects to trigger pipelines on them. Doc: Trigger a pipeline when an upstream project is rebuilt

Intended users

Unknown, but I suspect at least the following roles would find utility in this, in order to develop more complete automation workflows.

User experience goal

The user should be able to subscribe any hosted repository, and have subscribed CI/CD jobs execute when CI completes on the subscribed repository under any circumstance, without the requirement for a tag being published.

Proposal

I would suggest retaining the current default of executing subscribed jobs only when tags initiate a CI/CD job on the subscribed repository, and simply add an option to the subscriber repository's CI/CD pipeline subscription section to enable running subscriber CI jobs for all commits. This could also be implemented as a simple checkbox, "Enable subscription for jobs initiated by new tags only", which defaults to on, but can be disabled to remove the filter, and allow jobs to run on any CI/CD job in the subscribed repository.

Further details

One key use case is to enable external package builds requiring metadata in an external repository to be executed when mirrored upstream source repositories receive new commits. These, depending on workflow, might not always have a tag per release, maybe be on a branch, or canary builds may need to happen from the default remote development branch, for example.

Permissions and Security

  • No expected impact to members with no access (0)
  • No expected impact to Guest (10) members
  • No expected impact to Reporter (20) members
  • No expected impact to Developer (30) members
  • Maintainer (40) members should be able to configure the behaviour of this feature
  • Owner (50) members should be able to configure the behaviour of this feature

Documentation

  • Update of permissions document to detail changes to the CI/CD Pipeline subscription settings depending on implementation.
  • Update user documentation to clarify behaviour around tagged CI/CD jobs in subscribed repositories, and any change to available options in order to accommodate running subscriber CI/CD jobs.
  • Current document: Trigger a pipeline when an upstream project is rebuilt

Availability & Testing

Suggested test coverage, to mitigate risk of changing default behaviour (mitigated of course if the default behaviour remains unchanged)

  • With the option to only run subscriber CI/CD jobs on tags enabled (default), verify that when a build is started on a subscribed repository, on the default branch, without a tag being created, that the build in the subscribed repository does not run.
  • With the option disabled, verify that the same job does run
  • With the option enabled, verify that a job with a tag associated does run
  • With the option disabled, verify that a job with a tag associated does run

What does success look like, and how can we measure that?

When running a CI/CD pipeline on a subscribed repository executed due to a new commit, without tags being created/added/updated, subscribed CI/CD pipelines will also run, if the option to do so is enabled on the subscribed repository (or repositories)

What is the type of buyer?

This feature would only make sense in the Premium/Silver tiers, as the required features are only available at those tiers. This would most likely be of interested to the "Manager - App Dev" buyer or similar, looking to unlock more flexible multiple-repository pipelines.

Is this a cross-stage feature?

I assume so.

Links / references

Edited by 🤖 GitLab Bot 🤖