This action is used to validate a YAML file with a custom schema.
Parameter | Is Required | Description |
---|---|---|
yaml-file-path |
true | The path of the yaml file to validate. |
schema-file-path |
false | The schema file used to validate yaml file. If omitted or set to "SAM", the IM-OPEN SAM schema format will be used. |
log-level |
false | The severity level of information to include the action's logging. Accepted values are information, warning, and failure. |
†output-json |
false | Specify whether or not to output a json document with the results. Accepts true or false. It will only produce an output if no failures occur. |
† Output will always return a json document with a documents array attribute. (See Output Example) |
{
documents: [<document1>, <document2>, <document3>, ...]
}
Parameter | Description |
---|---|
validation-outcome |
The results of the file validation. Will be success, warning, or failed. |
json-output |
A json conversion of the yaml file. |
jobs:
validate-files:
runs-on: ubuntu-20.04
steps:
- uses: actions/checkout@v3
- name: Test SAM YAML
id: sam-test
uses: im-open/[email protected]
with:
yaml-file-path: ./sam.yaml
# schema-file-path: 'SAM' <-- If left undefined or set to 'SAM' the IM-OPEN SAM schema format will be used
continue-on-error: true
log-level: 'failure'
- name: Output sam
run: |
echo "SAM Results: ${{ steps.sam-test.outputs.validation-outcome }}"
This action was designed to validate a yaml file particular to IM-OPEN's needs. The SAM.json
schema file will be used when SAM
or no schema-file
is specified. This is a sample SAM.YAML
file that uses the SAM.json
file for validation. This is a minimal sample SAM.YAML
file that would bee needed to pass the 'SAM' validation.
The syntax for creating a custom schema file is essentially a json formatted file which minimally describes a field if it's REQUIRED
and child elements, if any. Possible required values are required
, warning
, and info
. Elements that are lists can be built using the LISTOF
field.
This is an example schema definition file:
{
"first": "required",
"last": "required",
"middle": "info",
"ag": "warning",
"akas": {
"REQUIRED": "info",
"LISTOF": {
"name": "info"
}
}
}
This corresponding YAML file would validate successfully based on the definition file:
first: 'John'
middle: 'Jacob'
last: 'Jingle-Heimer-Schmidt'
akas:
- name: 'John'
- name: 'Jake'
- name: 'My name, too!'
- name: 'Da-da-da-da-da-da-da'
For lists elements without name keys this specification could be made:
...
"groceries": {
"REQUIRED": "required",
"LISTOF": { }
}
...
This YAML element would then become valid:
...
groceries:
- eggs
- milk
- bacon
...
It is important to note that the validator will not be able to validate the list format or item count in an unstructured list. It will however ensure that the groceries
node exists, but it can have zero or more items in the list.
When creating new PRs please ensure:
- For major or minor changes, at least one of the commit messages contains the appropriate
+semver:
keywords listed under Incrementing the Version. - The action code does not contain sensitive information.
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:
- action.yml
- package.json
- package-lock.json
- src/**
- dist/**
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 and Incrementing the Version for more details.
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:
# Installs dependencies and bundles the code
npm run build
# Bundle the code (if dependencies are already installed)
npm run bundle
These commands utilize esbuild to bundle the action and
its dependencies into a single file located in the dist
folder.
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.
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.
Increment Type | Commit Message Fragment |
---|---|
major | +semver:breaking |
major | +semver:major |
minor | +semver:feature |
minor | +semver:minor |
patch | default increment type, no comment needed |
This project has adopted the im-open's Code of Conduct.
Copyright © 2021, Extend Health, LLC. Code released under the MIT license.