GitHub Actions

GitHub Actions

We use GitHub actions to run automated linting, testing and deployment.

These actions are currently split into two different workflows: energyvision/.github/workflows/ci.yaml and energyvision/.github/workflows/storybook.yaml.

The ci.yaml workflow is set to run each time a new commit is pushed to the main branch in the repository and runs an ESLint task from the root of the repository, followed by a task to run unit tests.

The storybook.yaml workflow runs each time a new commit is pushed to the main branch that contains changes to the energyvision/web/components/ directory. This workflow runs an ESLint task for the energyvision/web/components/ directory followed by a a task to run the unit tests in the energyvision/web/components/ directory. If both the linting and tests succeed it builds the storybook application and deploys it to azure blob storage.

Caching

Both workflows currently use GitHub's actions/cache@v2 to store/restore the yarn cache directory in order to speed up the installation of dependencies. This is done by using a hash of the yarn.lock file. If any yarn.lock file is updated, it will bust the cache and download, install and cache the (new) dependencies. If there are no changes, GitHub uses the stored cache in the container. By passing --prefer-offline to the yarn install script, yarn will install from the cache if it is available.

Comments

2020.02.19

The reason for having two separate workflows is that it currently is difficult to run a workflow from another workflow. Why would we want this? Because we are using a monorepo and use trunk-based development - we do not want to build and deploy applications if there were no changes (in this case storybook, but later on Sanity studio and the Next.JS frontend). We currently solve this by using a path specific conditional on the storybook workflow, but this conditional only works on workflow level - not on job or step level; making it difficult to integrate it with a repo-wide linting and testing workflow.

In the ideal world we would only have 1 workflow that can lint and test the whole repository, but only builds and deploys each app if there are changes.

One alternative is to make a workflow for each individual app that uses path specific conditionals to only run when they have to. For example:

• studio.yaml that is triggered by changes in energyvision/studio/**
• web.yaml that is triggered by changes in energyvision/web/**
• storybook.yaml that is triggered by changes in energyvision/web/components/**

With that approach we could have app specific eslint configurations, instead of having the linting from the root.