GitHub Actions Pitfalls

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • act

    Run your GitHub Actions locally 🚀

  • If you want to run github actions locally before any pitfalls, you can try out

    https://github.com/nektos/act

  • actionlint

    :octocat: Static checker for GitHub Actions workflow files

  • The first pitfall can be statically detected with actionlint

    https://github.com/rhysd/actionlint

    $ actionlint oops.yaml

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • roadmap

    GitHub public roadmap

  • combine-prs-workflow

    Combine/group together PRs (for example from Dependabot and similar services)

  • Another pitfall I ran into recently with a workflow I've been working on [1]: Checks and CI that are made with GitHub Actions are reported to the new Checks API, while some (all?) external services report to their old Statuses API. This makes it needlessly difficult to ascertain whether a PR/branch is "green" or not. They finally decided to create a "statusRollUp" that combines the state of the two APIs, but it's not available in their REST api, only their GraphQL API.

    [1] https://github.com/hrvey/combine-prs-workflow/

  • runner

    The Runner for GitHub Actions :rocket:

  • Their self-hosted runners are pretty jank. If your workflow writes something to the docker container's user's home directory, you will see it in the next workflow you run. Due to this and other things, I need a "preamble" action that needs right after checkout. Oh, if don't checkout at the beginning of your workflow, you will be using the previous workflows copy of the repository.

    I'm 100% sure they don't use this internally as these are glaring issues that impacts anyone using the self hosted runner. They also recommend running the container as root[1] instead of designing something more secure and sane.

    1: https://github.com/actions/runner/issues/434#issuecomment-61...

  • travis-yml

    Travis CI build config processing

  • More likely they hacked their YAML parser to treat on as a string.

    At least that's what Travis CI folks did:

    https://github.com/travis-ci/travis-yml#user-content-yaml

  • gh-valet

    Discontinued Valet helps facilitate the migration of Azure DevOps, CircleCI, GitLab CI, Jenkins, and Travis CI pipelines to GitHub Actions.

  • GitHub also has a tool that will covert Jenkins pipelines (and other tooling) to Actions called Valet.

    https://github.com/github/gh-valet

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • changed-files

    :octocat: Github action to retrieve all (added, copied, modified, deleted, renamed, type changed, unmerged, unknown) files and directories.

  • paths-filter

    Conditionally run actions based on files modified by PR, feature branch or pushed commits

  • There’s an awkward gotcha/incompatibility between “Required status checks” and workflows that get skipped [1], eg due to setting a “paths” property of a push/pull_request workflow trigger [2].

    The checks associated with the workflow don’t run and stay in a pending state, preventing the PR from being merged.

    The only workaround I’m aware of is to use an action such as paths-filter [3] instead at the job level.

    A further, related frustration/limitation - you can _only_ set the “paths” property [2] at the workflow level (i.e. not per-job), so those rules apply to all jobs in the workflow. Given that you can only build a DAG of jobs (ie “needs”) within a single workflow, it makes it quite difficult to do anything non trivial in a monorepo.

    [1]: https://docs.github.com/en/repositories/configuring-branches...

    [2]: https://docs.github.com/en/actions/using-workflows/workflow-...

    [3]: https://github.com/dorny/paths-filter

  • runner-images

    GitHub Actions runner images

  • just

    🤖 Just a command runner

  • +1 for Justfiles[1]! They're a much saner alternative to makefiles with great shell support

    [1] https://github.com/casey/just

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts