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
|`scope`| true | The scope is used to identify which value to select for each key name. See the usage instructions below. |
28
31
|`input-file`| false | A specially formatted YAML file containing possible environment variable candidates with their associated scopes. |
29
32
|`create-output-variables`| false | Create output variables (in addiction to environment variables) for use in other steps and jobs. Accepts true or false. Defaults to false. |
@@ -164,9 +167,12 @@ GitHub actions expressions can be used in the _`key-value`_ when supplying input
**Note the resulting environment variables this step will set aren't yet available to expressions in the step's own `env` block.** The resulting environment variables are not available until the next step in the job. If you need scoped variable values to be based on the values of other scoped variables you can use this action in consecutive steps.
170
+
**Note the resulting environment variables this step will set aren't yet available to expressions in the step's own `env` block.** The resulting environment variables are not available until the next step in the job. If you need scoped variable values to be based on the values of other scoped variables you can use this action in consecutive steps.
168
171
169
172
#### Input File Format
173
+
174
+
The `input-file` must be YAML format and has all the elements at the root level. It's contents would be formatted like this:
175
+
170
176
The `input-file` must be YAML format and has all the elements at the root level. It's contents would be formatted like this:
`error-on-no-match`is intended to alert that no env or output variable has been found based on the input scope. This is beneficial in troubleshooting if a scope *should* produce some form of output. Also a warning will show for any keys that have been included but doesn't provide a value for the input scope criteria.
196
+
`error-on-no-match`is intended to alert that no env or output variable has been found based on the input scope. This is beneficial in troubleshooting if a scope _should_ produce some form of output. Also a warning will show for any keys that have been included but doesn't provide a value for the input scope criteria.
191
197
192
198
## Contributing
193
199
194
-
When creating new PRs please ensure:
200
+
When creating PRs, please review the following guidelines:
201
+
202
+
- [ ] The action code does not contain sensitive information.
203
+
- [ ] At least one of the commit messages contains the appropriate `+semver:` keywords listed under [Incrementing the Version] for major and minor increments.
204
+
- [ ] The action has been recompiled. See [Recompiling Manually] for details.
205
+
- [ ] The README.md has been updated with the latest version of the action. See [Updating the README.md] for details.
206
+
207
+
### Incrementing the Version
208
+
209
+
This repo uses [git-version-lite] in its workflows to examine commit messages to determine whether to perform a major, minor or patch increment on merge if [source code] changes have been made. The following table provides the fragment that should be included in a commit message to active different increment strategies.
| patch | _default increment type, no comment needed_ |
195
218
196
-
1. For major or minor changes, at least one of the commit messages contains the appropriate `+semver:` keywords listed under [Incrementing the Version](#incrementing-the-version).
197
-
1. The action code does not contain sensitive information.
219
+
### Source Code Changes
198
220
199
-
When a pull request is created and there are changes to code-specific files and folders, the build workflow will run and it will recompile the action and push a commit to the branch if the PR author has not done so. The usage examples in the README.md will also be updated with the next version if they have not been updated manually. The following files and folders contain action code and will trigger the automatic updates:
221
+
The files and directories that are considered source code are listed in the `files-with-code` and `dirs-with-code` arguments in both the [build-and-review-pr] and [increment-version-on-merge] workflows.
200
222
201
-
- action.yml
202
-
- package.json
203
-
- package-lock.json
204
-
- src/\*\*
205
-
- dist/\*\*
223
+
If a PR contains source code changes, the README.md should be updated with the latest action version and the action should be recompiled. The [build-and-review-pr] workflow will ensure these steps are performed when they are required. The workflow will provide instructions for completing these steps if the PR Author does not initially complete them.
206
224
207
-
There may be some instances where the bot does not have permission to push changes back to the branch though so these steps should be done manually for those branches. See [Recompiling Manually](#recompiling-manually) and [Incrementing the Version](#incrementing-the-version) for more details.
225
+
If a PR consists solely of non-source code changes like changes to the `README.md` or workflows under `./.github/workflows`, version updates and recompiles do not need to be performed.
208
226
209
227
### Recompiling Manually
210
228
211
-
If changes are made to the action's code in this repository, or its dependencies, the action can be re-compiled by running the following command:
229
+
This command utilizes [esbuild] to bundle the action and its dependencies into a single file located in the `dist` folder. If changes are made to the action's [source code], the action must be recompiled by running the following command:
212
230
213
231
```sh
214
232
# Installs dependencies and bundles the code
215
233
npm run build
216
-
217
-
# Bundle the code (if dependencies are already installed)
218
-
npm run bundle
219
234
```
220
235
221
-
These commands utilize [esbuild](https://esbuild.github.io/getting-started/#bundling-for-node) to bundle the action and
222
-
its dependencies into a single file located in the `dist` folder.
223
-
224
-
### Incrementing the Version
225
-
226
-
Both the build and PR merge workflows will use the strategies below to determine what the next version will be. If the build workflow was not able to automatically update the README.md action examples with the next version, the README.md should be updated manually as part of the PR using that calculated version.
236
+
### Updating the README.md
227
237
228
-
This action uses [git-version-lite] to examine commit messages to determine whether to perform a major, minor or patch increment on merge. The following table provides the fragment that should be included in a commit message to active different increment strategies.
| patch | *default increment type, no comment needed* |
238
+
If changes are made to the action's [source code], the [usage examples] section of this file should be updated with the next version of the action. Each instance of this action should be updated. This helps users know what the latest tag is without having to navigate to the Tags page of the repository. See [Incrementing the Version] for details on how to determine what the next version will be or consult the first workflow run for the PR which will also calculate the next version.
236
239
237
240
## Code of Conduct
238
241
239
-
This project has adopted the [im-open's Code of Conduct](https://github.com/im-open/.github/blob/master/CODE_OF_CONDUCT.md).
242
+
This project has adopted the [im-open's Code of Conduct](https://github.com/im-open/.github/blob/main/CODE_OF_CONDUCT.md).
0 commit comments