-
Notifications
You must be signed in to change notification settings - Fork 2
149 lines (129 loc) · 5.89 KB
/
ci.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
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://git.luolix.topmunity/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://git.luolix.topmunity/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