A Github action to identify any workflows that must complete successfully before another workflow will run.

"Relies-on is to workflows as needs is to jobs" - Relies-on Author 😉

Why does Relies-on exist? 🛸

The main purpose of Relies-on is to identify any workflows that must complete successfully before another workflow will run.

(The idea behind this action is similar to Github's needs but at a workflows scale).

As an example of a situation where Relies-on comes in handy, let's imagine that you have two different workflows one called CI and another called CD assuming the CD workflow will do a critical thing that mustn't be performed only if the latest run of the CI workflow succeeded. One approach to solve this problem is to check the status of the latest CI run manually, but the problem with this approach is the ability to run the CD workflow (doing the critical thing) whether the latest CI workflow run was succeeded or not, which is not totally safe because there is no actual restriction, therefore Relies-on comes into existence.

How could aliens use this action? 👽

Here's a simple example to get started (assuming we have another workflow called CI):

# This is a CD system. It should publish a new release
# if and only if the lastest run of the CI workflow has succeeded.
name: CD

on:
  push:
    tags:
      - "v*.*.*"

jobs:
  check_ci_status:
    name: Check the CI Workflow's Status
    runs-on: ubuntu-latest
    steps:
      - uses: hadialqattan/relies-on@v1.0.0
        with:
          workflow: CI

  deployment:
    name: Deployment job
    needs: check_ci_status
    ...

This would terminate the CD workflow if the latest CI workflow run faild.

Optional action inputs (arguments):

owner:
  The username of the owner of the repository containing the workflow. [default=currect
  repository owner username]

repository:
  The name of the repository containing the workflow. [default=current repository name]

workflow: The name of the workflow that would be checked.

branch:
  The name of the branch where the workflow runs. [default=repository's default branch
  (most likely master or main)]

event: The type of the event that triggers the workflow. [default= ]

exclude_pull_requests: If true pull requests based runs are omitted. [default=true]
# Falsy values: "n", "no", "f", "false", "off", "0"
# Truthy values: "y", "yes", "t", "true", "on", "1"

Changelog 🆕

All notable changes to this project will be documented here.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[Unreleased]

[1.0.0] - 2022-04-26

Added

• First published version, Happy 🍰 Day 2022!
• Semantically versioned
• Keep a Changelog formatted.

Authors 👤

Authors:

• Hadi Alqattan (@hadialqattan) alqattanhadizaki@gmail.com

Contributors:

Contributing ✨

A big welcome for considering contributing to make the project better. In general, we follow the "fork-and-pull" Git workflow:

1. Fork the repository to your own Github account.
2. Clone the project to your machine.
3. Create a branch locally.
4. Commit changes to the branch.
5. Follow any formatting and testing guidelines specific to this repo (pre-commit install).
6. Push changes to your fork.
7. Open a PR in our repository.

Code of Conduct ❤️

Everyone participating in the Relies-on project, and in particular in the issue tracker, and pull requests is expected to treat other people with respect.

License 🚓

This project is licensed under an MIT license.

Give a ⭐️ if this project helped you!