You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- name: Derive appropriate SHAs for base and head for `nx affected` commands
42
43
uses: nrwl/nx-set-shas@v4
43
-
44
+
44
45
- run: |
45
46
echo "BASE: ${{ env.NX_BASE }}"
46
47
echo "HEAD: ${{ env.NX_HEAD }}"
@@ -51,75 +52,81 @@ jobs:
51
52
- name: Derive appropriate SHAs for base and head for `nx affected` commands
52
53
id: setSHAs
53
54
uses: nrwl/nx-set-shas@v4
54
-
55
+
55
56
- run: |
56
57
echo "BASE: ${{ steps.setSHAs.outputs.base }}"
57
58
echo "HEAD: ${{ steps.setSHAs.outputs.head }}"
58
59
59
60
# ... more CI config ...
60
61
```
62
+
61
63
<!-- end example-usage -->
62
64
63
65
## Configuration Options
64
66
65
67
<!-- start configuration-options -->
68
+
66
69
```yaml
67
70
- uses: nrwl/nx-set-shas@v4
68
71
with:
69
72
# The "main" branch of your repository (the base branch which you target with PRs).
70
73
# Common names for this branch include main and master.
71
74
#
72
75
# Default: main
73
-
main-branch-name: ''
76
+
main-branch-name: ""
74
77
75
78
# Applies the derived SHAs for base and head as NX_BASE and NX_HEAD environment variables within the current Job.
76
79
#
77
80
# Default: true
78
-
set-environment-variables-for-job: ''
81
+
set-environment-variables-for-job: ""
79
82
80
83
# By default, if no successful workflow run is found on the main branch to determine the SHA, we will log a warning and use HEAD~1. Enable this option to error and exit instead.
81
84
#
82
85
# Default: false
83
-
error-on-no-successful-workflow: ''
86
+
error-on-no-successful-workflow: ""
84
87
85
88
# The type of event to check for the last successful commit corresponding to that workflow-id, e.g. push, pull_request, release etc.
86
89
#
87
90
# Default: push
88
-
last-successful-event: ''
91
+
last-successful-event: ""
89
92
90
93
# The path where your repository is. This is only required for cases where the repository code is checked out or moved to a specific path.
91
94
#
92
95
# Default: .
93
-
working-directory: ''
96
+
working-directory: ""
94
97
95
-
# The ID of the github action workflow to check for successful run or the name of the file name containing the workflow.
98
+
# The ID of the github action workflow to check for successful run or the name of the file name containing the workflow.
96
99
# E.g. 'ci.yml'. If not provided, current workflow id will be used
97
100
#
98
-
workflow-id: ''
101
+
workflow-id: ""
99
102
```
103
+
100
104
<!-- end configuration-options -->
101
105
102
106
## Permissions in v2+
103
107
104
108
This Action uses Github API to find the last successful workflow run. If your `GITHUB_TOKEN` has restrictions set please ensure you override them for the workflow to enable read access to `actions` and `contents`:
105
109
106
110
<!-- start permissions-in-v2 -->
111
+
107
112
```yaml
108
113
jobs:
109
114
myjob:
110
115
runs-on: ubuntu-latest
111
116
name: My Job
112
117
permissions:
113
-
contents: 'read'
114
-
actions: 'read'
118
+
contents: "read"
119
+
actions: "read"
115
120
```
121
+
116
122
<!-- end permissions-in-v2 -->
117
123
118
124
## Self-hosted runners
119
125
120
126
This Action supports usage of your own self-hosted runners, but since it uses GitHub APIs you will need to grant it explicit access rights:
121
127
122
128
<!-- self-hosted runners -->
129
+
123
130
```yaml
124
131
# ... more CI config ...
125
132
@@ -149,6 +156,7 @@ jobs:
149
156
150
157
# ... more CI config ...
151
158
```
159
+
152
160
<!-- end self-hosted runners -->
153
161
154
162
## Background
@@ -157,7 +165,6 @@ When we run the `affected` command on [Nx](https://nx.dev/), we can specify 2 gi
157
165
158
166
This makes it easy to set up a CI system that scales well with the continuous growth of your repository, as you add more and more projects.
159
167
160
-
161
168
### Problem
162
169
163
170
Figuring out what these two git commits are might not be as simple as it seems.
@@ -174,8 +181,9 @@ Conceptually, what we want is to use the absolute latest commit on the `master`
174
181
The commits therefore can't just be `HEAD` and `HEAD~1`. If a few deployments fail one after another, that means that we're accumulating a list of affected projects that are not getting deployed. Anytime we retry the deployment, we want to include **every commit since the last time we deployed successfully**. That way we ensure we don't accidentally skip deploying a project that has changed.
175
182
176
183
This action enables you to find:
177
-
* Commit SHA from which PR originated (in the case of `pull_request`)
178
-
* Commit SHA of the last successful CI run
184
+
185
+
- Commit SHA from which PR originated (in the case of `pull_request`)
process.stdout.write(`WARNING: Unable to find a successful workflow run on 'origin/${mainBranchName}'\n`);
37914
+
process.stdout.write("\n");
37915
+
process.stdout.write(`WARNING: Unable to find a successful workflow run on 'origin/${mainBranchName}', or the latest successful workflow was connected to a commit which no longer exists on that branch (e.g. if that branch was rebased)\n`);
37913
37916
process.stdout.write(`We are therefore defaulting to use HEAD~1 on 'origin/${mainBranchName}'\n`);
37914
-
process.stdout.write('\n');
37917
+
process.stdout.write("\n");
37915
37918
process.stdout.write(`NOTE: You can instead make this a hard error by setting 'error-on-no-successful-workflow' on the action in your workflow.\n`);
0 commit comments