Skip to content

Minor: Lint repo

Minor: Lint repo #477

Workflow file for this run

name: CI
# TODO Looks like workflows ARE reusable now: https://docs.github.com/en/actions/using-workflows/reusing-workflows#creating-a-reusable-workflow
# Controls when the action will run.
on:
# Allows you to run this workflow manually from the web GUI "Actions" tab
workflow_dispatch:
# Triggers the workflow on push or pull request events but only for the master branch
push:
branches: [ master ]
pull_request:
branches: [ master ]
# Specify defaults for all jobs' `run` blocks.
# See:
# https://github.community/t/use-working-directory-for-entire-job/16747/9
# https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun
# https://github.community/t/github-actions-configure-defaults-option/18438/3
defaults:
run:
shell: bash
working-directory: ./
# Set GitHub user info for ease of use of `gh` CLI commands.
#
# See:
# - https://docs.npmjs.com/cli/v9/commands/npm-run-script#ignore-scripts
# - https://stackoverflow.com/questions/59471962/how-does-npm-behave-differently-with-ignore-scripts-set-to-true
# - https://github.com/tschaub/gh-pages#optionsuser
# - https://github.com/actions/checkout/issues/13
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
gitUserName: ${{ github.actor }}
gitUserEmail: ${{ github.actor }}@users.noreply.github.com
nodeVersion: 18
clientVersion: ""
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
# Workflows require at least one job that has no dependencies.
# However, we can still use the `uses` block for "reusable workflows"
#
# See:
# - Reusable workflows `uses`: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iduses
jobs:
ci-client:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Specify defaults for all steps that override top-level `defaults`
# defaults:
# run:
# # Specify directory in which to run all subsequent steps/commands
# #
# # e.g. If using a monolith with `./client/` and `./server/` directories, then set:
# # `working-directory: ./client`
# working-directory: ./
outputs:
CLIENT_CACHE_ID: ${{ env.CLIENT_CACHE_ID }}
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it.
# Note: Files don't carry over between separate jobs so merge the git-checkout/env-setup
# logic in with the actual job logic.
- name: CI:Client - Checkout repository branch
uses: actions/checkout@v3
- name: CI:Cache name - Init
uses: ./.github/workflows/actions/init
- name: CI:Client - Run all
id: ci-client-all
# Import reusable GitHub Action logic via `uses`
uses: ./.github/workflows/actions/client
# Set env vars for all nested composite actions.
# Any env vars set within composite actions apply to the parent job.
#
# See:
# - https://github.com/orgs/community/discussions/27088
# - https://stackoverflow.com/questions/70098241/using-secrets-in-composite-actions-github/70111134#70111134
# - https://stackoverflow.com/questions/63663436/what-is-difference-between-with-and-env
env:
GITHUB_TOKEN: ${{ env.GITHUB_TOKEN }}
gitUserName: ${{ env.gitUserName }}
gitUserEmail: ${{ env.gitUserEmail }}
nodeVersion: ${{ env.nodeVersion }}
with:
clientVersion: ${{ env.clientVersion }}
# Env vars are always accessible between jobs of the same workflow.
# - $CLIENT_CACHE_ID
# - ${{ env.CLIENT_CACHE_ID }}
# Adding an output var means we can reference the job ID in subsequent jobs:
# - ${{ needs.ci-client.outputs.CLIENT_CACHE_ID }}
# If a nested composite action forwards its child/(doubly-)nested composite action's outputs in its own
# root-level `outputs` block, then we can also reference the job's specific step in subsequent jobs:
# - ${{ needs.ci-client-output-cache-id.outputs.CLIENT_CACHE_ID }}
- name: CI:Client - Output cache ID
id: ci-client-output-cache-id
run: |
echo "CLIENT_CACHE_ID=${{ env.CLIENT_CACHE_ID }}" >> $GITHUB_OUTPUT
ci-server:
runs-on: ubuntu-latest
needs: [ ci-client ]
env:
# Env vars set from previous jobs are lost once that job ends.
# Re-declaring it here means we can use the shorthand `$CLIENT_CACHE_ID` or `${{ env.CLIENT_CACHE_ID }}`
# instead of referencing the job name each time it's used in this job's steps.
#
# Must use `needs` rather than `jobs` since `jobs` is only available in reusable workflows.
#
# See:
# - https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-defining-outputs-for-a-job
# - https://docs.github.com/en/actions/learn-github-actions/contexts#jobs-context
CLIENT_CACHE_ID: ${{ needs.ci-client.outputs.CLIENT_CACHE_ID }}
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it.
# Note: Files don't carry over between separate jobs so merge the git-checkout/env-setup
# logic in with the actual job logic.
- name: CI:Server - Checkout repository branch
uses: actions/checkout@v3
- name: CI:Cache name - Init
uses: ./.github/workflows/actions/init
- name: CI:Server - TODO
id: ci-server-todo
run: |
echo "TODO - Server logic"
ci-complete:
runs-on: ubuntu-latest
needs: [ ci-client, ci-server ]
# Re-export outputs from previous jobs
outputs:
CLIENT_CACHE_ID: ${{ env.CLIENT_CACHE_ID }}
steps:
- name: CI:Completed - Aggregate and wait for jobs
id: ci-complete
run: |
echo "CLIENT_CACHE_ID=$CLIENT_CACHE_ID" >> $GITHUB_OUTPUT