/load_testplan

Load multiple yaml files to generate environment variables/outputs for github actions

Primary LanguageJavaScriptBSD 3-Clause "New" or "Revised" LicenseBSD-3-Clause

Github action load_testplan

This github action loads one or more yaml or json files, applying golang templating and merging them together to generate either environment variables or outputs to be used in github actions. It can also output yaml or json files containing the merged data.

The code is maintained in the (development branch)[https://github.com/joernott/load_testplan/tree/development], the (main branch)[https://github.com/joernott/load_testplan/tree/main] only contains the binaries for the action itself to reduce the amount of data to download.

Usage

To use this action in your workflow and convert the content of some yaml files into outputs, you can use

- uses: joernott/load_testplan
  with:
    files: 'example/defaults.yaml.example/overwrite_string_with_structure.yaml'
    set_output: true
    set_env: true
    set_print: true
    separator: '_'

Inputs

The action has the following inputs:

files: Required, no default
A comma separated list of yaml files to be parsed. You can use go template syntax in those files (see below). Files are parsed from left to right and content from later files overrides previous values.

input_type: Not required, 'auto'
Set this to "yaml" and all the files specified in the files parameter will be loaded as yaml files. Set it to "json" to always assume them to be json files. If this is set to "auto", it will try to determine the file type based on its suffix. Files ending in ".yml" or ".yaml" will be loaded as yaml, files with ".json", ".jsn", ",jso" or ".js" will be loaded as json.

separator: Optional, default: '_'
When flattening hierarchical yaml into key/value pairs, this separator will be used to concatenate the keys. Using the default underscore,

foo:
  bar: baz

becomes "foo_bar=baz".

set_output: Optional, default: false
When set to true, the action will write the variables to the file defined in the environment variable $GITHUB_OUTPUT.

set_env: Optional, default: false
When set to true, the action will write the variables to the file defined in the environment variable $GITHUB_ENV.

set_print: Optional, default: false
When set to true, the action will write the variables with their values to stdout to provide some debugging information. Keys on the first level with a structure below will be interpreted as headings and printed in purple.

compile:
  flags: '--foo'

will render as

compile
compile_flags='--foo'

yaml: Optional, default: ''
If you provide a file name here, the merged and processed data will be written into the file as yaml. This helps debugging merge issues or can be used as later input.

json: Optional, default: ''
If you provide a file name here, the merged and processed data will be written into the file as json. This helps debugging merge issues or can be used as later input.

logfile: Optional, default: '-'
Tis defines where the actions log messages/output should go. The default "-" means logging to stdout.

loglevel: Optional, default: 'WARN' How verbose should the action log what it is doing. The levels (in order of increasing verbosity) are PANIC, FATAL, ERROR, WARN, INFO, DEBUG, TRACE.

generate_job: Optional, default: false If you set generate_job to true, this will create a file "job_load_testplan.yml" which contains a job running the testplan with exactly the input parameters specified and defining job outputs for every key found in the loaded yaml file(s). Copying from this file can save you a lot of time when you have a lot of outputs you want to use in the workflow.

token: Optional, default: '' If you want to check out a plan from a private github repository, you can set token to ${{ github.token }} to add "?token=" to the URL.

Templating

You can use (go templating)[https://pkg.go.dev/text/template] in the yaml files. To access the environment variables available to the action, use

{{ .Env.<VARRIABLE_NAME> }}

Instead of using the environment variables, you can also use

{{ .Github.<FIELD> }}

to access the Github context. We use (sethvargo/go-githubactions)[https://github.com/sethvargo/go-githubactions/], so the capitalization follows their (data structure)[https://github.com/sethvargo/go-githubactions/blob/v1.1.0/actions.go#L461] e.g. {{ .Github.RunID }} is the same as {{ .Env.GITHUB_RUN_ID }}, which you would write as ${{ github.run_id }} in a workflow file.

As we parse multiple files, the output from the previous merge step (or first file) is available as

{{ .Data.<field> }}

There are now two custom functions available to use in templates: replace and indent.

The replace function takes three string arguments:

  • input: The string to operate on
  • from: What you want to replace
  • to: The replacement

Example:

key: '{{ replace "foobar" "foo" "bar" }}'

will generate

key: 'barbar'

The indent function indents all lines in a multiline string but the first by a given number of spaces. It has two inputs:

  • input: The multiline string to operate on
  • spaces: A number of spaces to add at the beginning of every newline

Example: We have a multiline string defined in first.yaml:

multi: |
  I am indented by two
  spaces for a snytactically correct yaml,
  but those spaces get stripped away when reading the key.

In second.yaml, I want to refer to this string:

multiline: |
  {{ indent .Data.multi 2 }}

Loading both of them with the files input set to "first.yaml,second.yaml", we will get both keys correctly formatted:

multi: |
  I am indented by two
  spaces for a snytactically correct yaml,
  but those spaces get stripped away when reading the key.
multiline: |
  I am indented by two
  spaces for a snytactically correct yaml,
  but those spaces get stripped away when reading the key.