fix(action): re-introduce a custom Dockerfile to handle user input #32
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After trying to reduce dependencies and eliminate the need to create a new container to run taskcat in GitHub workflows, it seems that it might be easier to simply control the execution from within a script, bypassing the restrictions set by the GitHub Action's metadata syntax. This commit re-introduces the entrypoint.sh script and the Dockerfile. Building on the official taskcat/taskcat container, the script allows users to pass arbitrary commands to taskcat from GitHub workflows, as they would when invoking the taskcat from the command line. Associated issues: #20, #26
Due to validation and implementation differences between act and the GitHub hosted runners, we cannot solely rely on the JUnit tests to ensure the correct functionality of the action. To help catch errors, a job was added to this repository's GitHub workflow, which runs the example in this project's README file against the sample CloudFormation template used by the JUnit tests. While we can only rely on the action's return code to determine if the execution was successful, it can act as a simple tool to detect errors that act might have missed. Associated issue: #20, #26
Re-enable the JUnit tests which have been disabled in commit 0cfb762. With the introduction of our own container layer in previous commits, the entrypoint is now defined in the Dockerfile, rather than the action.yaml file. While the underlying issue still persists, we're no longer affected by the discrepancy between act and the GitHub runner, each expecting different types for the entrypoint element in the action's definition. Associated issue: #26, #24
|
🎉 This PR is included in version 1.0.3-develop.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 1.0.3 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
ShahradR
added a commit
that referenced
this pull request
Nov 29, 2020
fix(git): bump .gitattributes file version
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request re-introduces the project-specific
Dockerfileandentrypoint.shfiles, due to the complexity of maintaining Docker parameters solely in theaction.yamlfile.Specifically, the
entrypointparameter is no longer defined as part of theaction.yamlfile—instead, layers are created on top of thetaskcat/taskcat:latestimage to set the entrypoint to theentrypoint.shscript. The script handles input tokenization, allowing users to pass commands liketest run, like they would in the command-line version of taskcat.Because we no longer define the entrypoint using the metadata syntax for GitHub Actions, we're side-stepping issue #26, where act and the GitHub hosted runner both expect different types for
entrypoint. As such, we can re-enable the act JUnit tests. To prevent this in the future, and catch errors act might have missed, a job is added to the CI/CD workflow, running this action on GitHub hosted runners as part of the integration tests.Closes #20, #26