Because the customer uses infrastructure as a code (IaC) into their pipelines using AWS CloudFormattion, they were used to the YAML format and the advanced features from the AWS schema and functionalities available, Actions YAML was simple to use and teach, however, introduced last year the workflow_dispatch allows customers to create workflows that are manually trigger with the option of input parameters. Our product supports only a limit of 10 inputs and throws an error, not allowing customer with multi-cloud environment setup more control for those manually trigger workflows.
We introduced a few options for the customer with the goal of continue maintaining the developer experience, interoperability, compliance and security and the ability to use the product in a multi-cloud environment.
When the developer commits it triggers the workflow passing the paramters inside the git commit message in JSON format.
git add .
git commit -m ' { "apiName": "testing-mulesoft-api-dev" } '
git push
The workflow looks like this, mostly taking advantaged of fromJSON() built-in function.
name: JSON commit message # Name of the workflow
on:
push:
branches:
- main
jobs:
job1:
runs-on: ubuntu-latest
outputs:
apiName: ${{ steps.myoutputs.outputs.apiName }}
apiMajorVersion: ${{ steps.myoutputs.outputs.apiMajorVersion }}
apiMinorRelease: ${{ steps.myoutputs.outputs.apiMinorRelease }}
apiPatchRelease: ${{ steps.myoutputs.outputs.apiPatchRelease }}
assetGroupId: ${{ steps.myoutputs.outputs.assetGroupId }}
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Set env variables
id: myoutputs # set the outputs
run: |
echo ::set-output name=apiName::${{fromJSON(github.event.head_commit.message).apiName}}
echo ::set-output name=apiMajorVersion::${{fromJSON(github.event.head_commit.message).apiMajorVersion}}
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- name: Grab Job1 env variables
run: |
echo ${{needs.job1.outputs.apiName}}
echo ${{needs.job1.outputs.apiMajorVersion}}
Similar to the JSON commit message, we can use a json file to input the paramters, there are a few limits to this option, it's recommended to the file be lower than 10KB as the file takes time to load in the context.
As long you have a valid JSON file format, you can input an example like this:
{
"apiName": "testing-mulesoft-api-dev",
"apiMajorVersion": "1",
"apiMinorRelease": "0",
"apiPatchRelease": "0",
"assetGroupId": "1"
}
In this particular example, instead of using fromJSON() I used the built-in support for jq to show the customer they can use bash to parse the JSON file.
name: JSON file # Name of the workflow
on:
push:
branches:
- main
jobs:
job1:
runs-on: ubuntu-latest
outputs:
apiName: ${{ steps.myoutputs.outputs.apiName }}
apiMajorVersion: ${{ steps.myoutputs.outputs.apiMajorVersion }}
apiMinorVersion: ${{ steps.myoutputs.outputs.apiMinorVersion }}
apiPatchVersion: ${{ steps.myoutputs.outputs.apiPatchVersion }}
assetGroupId: ${{ steps.myoutputs.outputs.assetGroupId }}
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Set env variables
id: myoutputs # set the outputs
run: |
json_file=`cat ./pipelines/inputs.json`
echo ::set-output name=apiName::$(echo $json_file | jq -r '.apiName')
echo ::set-output name=apiMajorVersion::$(echo $json_file | jq -r '.apiMajorVersion')
echo ::set-output name=apiMinorVersion::$(echo $json_file | jq -r '.apiMinorVersion')
echo ::set-output name=apiPatchVersion::$(echo $json_file | jq -r '.apiPatchVersion')
echo ::set-output name=assetGroupId::$(echo $json_file | jq -r '.assetGroupId')
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- name: Grab Job1 env variables
run: |
echo ${{needs.job1.outputs.apiName}}
echo ${{needs.job1.outputs.apiMajorVersion}}
echo ${{needs.job1.outputs.apiMinorVersion}}
echo ${{needs.job1.outputs.apiPatchVersion}}
echo ${{needs.job1.outputs.assetGroupId}}
For a handful of extra requirements, we end up using a few options available in the Actions Marketplace.