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
Copy file name to clipboardExpand all lines: AGENTS.md
+13-5Lines changed: 13 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,15 @@
5
5
pnpm install
6
6
```
7
7
8
-
## Schema Change Fix
8
+
## Development Guidance
9
+
### Generating Action Types
10
+
From the root directory, run
11
+
```
12
+
pnpm generate-action-types
13
+
```
14
+
to correctly update action types.
15
+
16
+
### Schema Change Fix
9
17
1. When the schema (source: schemastore) changes, we want to update the types:
10
18
```bash
11
19
pnpm generate-workflow-types
@@ -17,10 +25,10 @@ pnpm install
17
25
Ensure Coverage remains at 100%. If not, create the necessary test(s) to keep it at 100%.
18
26
19
27
3. Commit the change
20
-
a. The branch name should be of the format `chore/schema-update-YYMMDD` if the change only contains schema changes. If the branch contains more changes, use conventional commit and branch naming style.
21
-
b. The commit message should have the title format `chore: update types` if only schema changes else use conventional commit style.
22
-
c. You can add more detail to the commit message but be succint and concise.
23
-
d. Finally, the pre-commit script will run and ensure that workflow files are regenerated.
28
+
1. The branch name should be of the format `chore/schema-update-YYMMDD` if the change only contains schema changes. If the branch contains more changes, use conventional commit and branch naming style.
29
+
2. The commit message should have the title format `chore: update types` if only schema changes else use conventional commit style.
30
+
3. You can add more detail to the commit message but be succint and concise.
31
+
4. Finally, the pre-commit script will run and ensure that workflow files are regenerated.
24
32
25
33
4. Create the pull request
26
34
a. When you create the PR, be equally succinct and concise in the PR description.
Copy file name to clipboardExpand all lines: README.md
+55Lines changed: 55 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -321,6 +321,61 @@ If you want to change how github-actions-workflow-ts generates the yaml files, y
321
321
| refs | If true, convert duplicate objects into references in YAML |`Boolean`| false |
322
322
| headerText | Replace the header text in generated YAML files with your own text. <br>If you want the source filename and path in the text, use `<source-file-path>` in<br>the text and it will be replaced with the path to the source-file. |`Array<string>`| # ----DO-NOT-MODIFY-THIS-FILE----<br># This file was automatically generated by github-actions-workflow-ts. <br># Instead, modify `<source-file-path>`<br># ----DO-NOT-MODIFY-THIS-FILE---- |
323
323
| dumpOptions | Options for the dump function of js-yaml. See [all the options here](https://github.com/nodeca/js-yaml#dump-object---options-)| Record <string, any> | Uses the default options |
324
+
| diagnostics | Configure diagnostic warnings emitted during build. See [Diagnostics Configuration](#diagnostics-configuration) below. |`Object`| undefined |
325
+
326
+
</details>
327
+
328
+
### Diagnostics Configuration
329
+
When using `@github-actions-workflow-ts/actions`, the CLI emits warnings for version mismatches (e.g., using `actions/checkout@v3` with `ActionsCheckoutV4`). You can configure these diagnostics in `wac.config.json`:
When using typed actions, the CLI validates that the action version you specify matches the expected version. For example, if you use `ActionsCheckoutV4` but override the `uses` field to `actions/checkout@v3`, a warning will be emitted during build.
57
+
58
+
### Diagnostic Codes
59
+
60
+
| Code | Description |
61
+
|------|-------------|
62
+
|`action-version-unverifiable`| The action version cannot be verified because the git ref is not a valid semver (e.g., `@main`, `@feature-branch`) or the repository doesn't match |
63
+
|`action-version-semver-violation`| The action version doesn't satisfy the expected semver constraint (e.g., using `@v3` with a `V4` typed action) |
64
+
65
+
### Configuring Diagnostics
66
+
67
+
You can configure how these diagnostics are handled in your `wac.config.json`:
68
+
69
+
```json
70
+
{
71
+
"diagnostics": {
72
+
"rules": {
73
+
"action-version-unverifiable": "off",
74
+
"action-version-semver-violation": "error"
75
+
}
76
+
}
77
+
}
78
+
```
79
+
80
+
#### Severity Levels
81
+
82
+
-`"off"` - Suppress the diagnostic entirely
83
+
-`"warn"` - Emit as a warning (default behavior)
84
+
-`"error"` - Upgrade to an error
85
+
86
+
#### Advanced: Per-Action Rules
87
+
88
+
You can suppress diagnostics for specific actions while keeping them enabled for others:
89
+
90
+
```json
91
+
{
92
+
"diagnostics": {
93
+
"rules": {
94
+
"action-version-semver-violation": {
95
+
"severity": "error",
96
+
"exclude": [
97
+
"actions/checkout@*",
98
+
"actions/setup-node@v3"
99
+
]
100
+
}
101
+
}
102
+
}
103
+
}
104
+
```
105
+
106
+
The `exclude` array supports patterns:
107
+
- Exact match: `"actions/checkout@v3"`
108
+
- Wildcard version: `"actions/checkout@*"` (matches any version)
109
+
- Wildcard repo: `"actions/*"` (matches all actions from an org)
110
+
111
+
### Example: Intentionally Using an Older Version
112
+
113
+
If you need to use an older action version for compatibility reasons, you can suppress the warning in two ways:
114
+
115
+
#### Option 1: In-Code Suppression with `suppressWarnings` prop
0 commit comments