Skip to main content

depends-on-action

GitHub action to install dependent Pull Requests and configure them to be used by later steps.

Overview

This action allows you to install Pull Request dependencies when the workflow action is triggered.

You need this action if your project is split into multiple repositories, and you can have Pull Requests that must be tested together. It happens often when you have libraries or micro-services in different repositories, and you need to test changes with the programs that use them. Even if you depend on third-party repositories that are not yours, you can use this action to test your Pull Requests with the third-party Pull Requests.

How does it work? This GitHub action extracts all the Pull Requests that are declared in the description of the main Pull Request with the Depends-On: <PR url> syntax. You can have multiple dependencies in the description of the main Pull Request by adding multiple Depends-On: lines. For example, if you depend on a Pull Request in the org/library repository, you can add the following line in the description of your Pull Request:

Change to use the new library function

Depends-On: https://github.com/org/library/pull/123

If you need to specify a sub-directory for a particular Pull Request, use the following syntax:

Depends-On: <PR url>?subdir=<subdir path>

This GitHub action then injects the needed modifications in the code to use the other changes.

Gerrit and Gitlab changes

Gerrit and Gitlab dependencies are also supported. Examples:

Depends-On: https://gerrit-review.googlesource.com/c/gerrit/+/394841
Depends-On: https://gitlab.com/adblockinc/ext/adblockplus/spec/-/merge_requests/428

The detection of the type of change is done in this order:

  1. If there is a /c/ in the url, it is a Gerrit change.
  2. If there is gitlab in the hostname, it is a Gitlab change.
  3. It is a Github change.

Gitlab credentials

If you need credentials to access the Gitlab server, you can set the environment variables GITLAB_TOKEN and GITLAB_USER as secrets. Depending on the configuration of your server, you could only need GITLAB_TOKEN.

Go lang

For a Go lang change, the action adds replace directives for the dependencies inside the go.mod file. This action needs to be placed after installing the Go lang toolchain.

Python

The action replaces entries in requirements.txt for a Python change with a -e <local change> or the equivalent for pyproject.toml.

Javascript

The action replaces entries in package.json for a Javascript change with file:<local change>.

Ansible

The action replaces entries in requirements.yml for an Ansible collection change.

Container

The action auto-detects if a container is present and injects the changes in a compatible way if this is the case.

Enabling the action

Sample Configuration

Defining Github Actions requires creating a directory .github/workflows inside your repository. Inside this directory, you create files processed when various events occur.

The simplest example of using this action would be to create the file .github/workflows/pull_request.yml with the following contents:

---
name: Pull Request
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  validate-tests:
    runs-on: ubuntu-latest
    steps:

      - name: Checkout code
        uses: actions/checkout@v4

      # install the toolchain for your language

      - name: Extract dependent Pull Requests
        uses: depends-on/depends-on-action@0.15.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
        # optional if needed for Gitlab
        env:
          GITLAB_TOKEN: ${{ secrets.GITLAB_TOKEN }}
          GITLAB_USER: ${{ secrets.GITLAB_USER }}

      # <your usual actions here>

  check-all-dependencies-are-merged:
    runs-on: ubuntu-latest
    steps:

      - name: Check all dependent Pull Requests are merged
        uses: depends-on/depends-on-action@0.15.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          check-unmerged-pr: true
        # optional if needed for Gitlab
        env:
          GITLAB_TOKEN: ${{ secrets.GITLAB_TOKEN }}
          GITLAB_USER: ${{ secrets.GITLAB_USER }}
...

As demonstrated above, you need at least two pipelines: one or more to do your regular builds and tests injecting the dependent changes and, a specific one to block until the dependent changes are merged.

Multiple checkouts

If your pipeline is cloning multiple git repositories, you could want to inject the dependencies in all these directories. To do so, use the extra-dirs option with space separated names of directories like this:

---
name: Pull Request
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  validate-tests:
    runs-on: ubuntu-latest
    steps:

      - name: Checkout code
        uses: actions/checkout@v4

      - name: Check out an extra dir
        uses: actions/checkout@v4
        with:
          repository: org/proj
          path: proj

      # install the toolchain for your language

      - name: Extract dependent Pull Requests
        uses: depends-on/depends-on-action@0.15.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          extra-dirs: org/proj

      # <your usual actions here>
      ...
...

Details

When the action is called with the check-unmerged-pr: true setting, stages 1 and 2 are used but not stage 3. Stage 2, in this case, is not extracting the dependent changes on disk but just checking the merge status of all the dependent changes.

Usage outside of a GitHub action

If you want to use the same dependency management in other CI pipelines or in a local test, you can install the python package:

$ pip install depends-on

and use the depends_on_stage1 script as an entry point taking the URL of the change you want to download in parameter:

$ cd <workspace>
$ export GITHUB_TOKEN=<your token>
$ # if you need access to a private Gitlab server
$ export GITLAB_USER=<your user>
$ export GITLAB_TOKEN=<your gitlab token>
$ # Extracting a Github change and its dependencies
$ depends_on_stage1 https://github.com/depends-on/pyprog/pulls/2
$ # Extracting a Gitlab change and its dependencies
$ depends_on_stage1 https://gitlab.com/adblockinc/ext/adblockplus/spec/-/merge_requests/428
$ # Extracting a Gerrit change and its dependencies
$ depends_on_stage1 https://softwarefactory-project.io/r/c/dci-pipeline/+/29700

Roadmap

Metadata

Release files for depends-on 0.15.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for depends-on 0.15.0
File Size Uploaded Provenance
depends-on-0.15.0.tar.gz 27.8 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for depends-on 0.15.0
File Interpreter ABI Platform
depends_on-0.15.0-py3-none-any.whl Python 3 none any Details

Total release size: 55.9 kB

Release files / depends-on-0.15.0.tar.gz

Download URL depends-on-0.15.0.tar.gz
Size 27.8 kB
Tags Source
SHA-256 checksum
How to use checksums
7723c17d9dd7627b06f707b910c3094a83ea146c657173a3b6a813eafe4ea10b
BLAKE2b-256 checksum
How to use checksums
045e49695b2891ea18ad3272993d8bc70d9c0523501d4aa0078cdc2a06528279
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/5.0.0 CPython/3.12.3

Release files / depends_on-0.15.0-py3-none-any.whl

Download URL depends_on-0.15.0-py3-none-any.whl
Size 28.0 kB
Tags Python 3
SHA-256 checksum
How to use checksums
8b3092a983d2536fff1ccc730c0746f3a9b7f5db73fb90a47f70f71a2d4ca28f
BLAKE2b-256 checksum
How to use checksums
eede86d6ca43149159be4c59796264fb9a198b522f6c4d5817de0645bcce66fe
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/5.0.0 CPython/3.12.3

Security for depends-on 0.15.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page