It's the last and the shortest part of the series. Testing the whole action as a black box can be done in 2 ways (as far as I can see).
github-action-ts-run-api again
Use the same tool as for integration test, but run tests against the whole action.
Use Act tool
This approach implies that you should create special testing workflows that can be naturally run on GitHub Actions runner or can be run locally using Act.
If you need to debug an action on actual GitHub hosted runner, take a look at debugging-with-tmate action on the Marketplace.
Testing workflows can be located in the action repository and refer to the action using the local ./ path. It's especially convenient because each branch in the action repo will be tested against the version of the action stored in this branch.
Here is a fragment of the testing workflow for git-get-release-action:
- name: Get 1.1.1 release by releaseId
id: getByReleaseId
# referring to the action in the current repo
uses: ./
with:
releaseId: 41301084
- name: Check getByReleaseId step result
if: steps.getByReleaseId.outputs.tag_name != '1.1.1'
shell: bash
run: exit 1
Another option is creating a dedicated repo for testing workflows. It can also contain commits, releases, issues and other GitHub objects that can be read and modified by the action without bloating your main repository.
The drawback of this approach is that you have to specify an exact version of the action in uses key of each step:
- name: Get 1.1.1 release by releaseId
id: getByReleaseId
# referring to the specific version (v1)
uses: cardinalby/git-get-release-action@v1
with:
releaseId: 41301084
If you have multiple branches in the main repo and want to test them, you should create the same
branches in the tesing repo and change all uses keys to the appropriate version (action-name@myBranch).
đź‘Ź Thank you for reading
Any comments, critics and sharing your own experience would be appreciated!
If you are interested in developing own Actions, you can read my other posts:
Top comments (0)