Expensify Shared GitHub Actions workflows 🔄

What is the repository used for?

Expensify has multiple repositories that use the same GitHub Actions workflows. This repository centralizes and consolidates frequently used workflows to enhance security and maintain consistent standards across projects.

Usage

npmPublish.yml

Used to publish a package to npmjs, should be triggered when code is merged into the main branch. Note: Please follow these instructions to grant our bots the correct access to publish.

jobs:
  publish:
    uses: Expensify/GitHub-Actions/.github/workflows/npmPublish.yml@main
    secrets: inherit
    with:
      # Repository name with owner. For example, Expensify/eslint-config-expensify
      # Required, String, default: ${{ github.repository }}
      repository: ''

      # True if we should run npm run build for the package
      # Optional, Boolean, default: false
      should_run_build: true

cla.yml

Used to check if a user has signed the Contributor License Agreement, Should be triggered when a PR is opened or updated.

jobs:
  CLA:
    uses: Expensify/GitHub-Actions/.github/workflows/cla.yml@main
    # Required to pass along secrets for `CLA_BOTIFY_TOKEN`
    secrets: inherit

Rulesets

GitHub org-level rulesets can be configured to run a workflow check against pull requests in all repos in the org. This is a very powerful feature, but there are some caveats and best practices to be aware of when enabling a ruleset.

• Supported Event Triggers are documented here. However:
  • When a workflow runs in response to a ruleset, some configs such as branches, paths, paths-ignore, that would normally be valid in a workflow are ignored.
  • The default activity types for each event will be used. This means that something like pull_request:comment will not work - the pull_request event will always be triggered for the default activity types listed in the documentation.
  • If you need to target or exclude specific branches, that can be configured in the ruleset settings.
  • If you need to target or exclude specific paths, that must be implemented manually in the workflow itself.
• Due to a GitHub 🐛, PRs that are open when the rule is enabled will get stuck with a pending check that will never get picked up. The easiest way to fix that is to close and reopen the PR. Consider writing a script to close and reopen all open PRs across the org after the check is enabled.
• It is less disruptive to configure the ruleset to Evaluate first, then Active once the kinks are worked out.