-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: add workflows #33
Conversation
…-test-compare into test/workflows
…-test-compare into test/workflows
@ianlnf are you looking for a review on this? if so, fix CI first please |
Updated now, ready for review. The logging added shows that Act tests do fail occasionally in CI with a Docker container error, but run locally. I've disabled the tests in CI and added issue #34. Options are removing the tests (no automated testing) or resolving the issue. But I think either option should be done after this PR is merged, as it has improved test structure anyway. The local tests may be of some value. |
My recommendation is to ditch act altogether and write unit test as we did in all out other actions. Are you up for picking this up? |
This is a purely composite action, there is no custom code to unit test |
That's exactly the idea. Logic should live in code, not in yaml. I'd turn this into a JS action, ditch act and write pure unit tests for the logic. |
I still think there is value in pursuing an effective mechanism for developing integration tests with composite actions longer term. Their raison d'etre is the reuse of logic within YAML, allowing existing actions to be repurposed to produce custom behaviour efficiently. Even if this action were to be refactored to JS/TS, which arguably is unnecessary here, it may still remain a composite action with custom code via github-script, e.g. if it wished to reuse actions such as input validation, copying of files, checkout etc. Testing only custom code in this case with unit tests may be sufficient, but may not be ideal. Integration tests could offer broader validation and less coupling to the production code. I think either way though, this PR could be merged and issue #34 assessed for effort vs a refactor. It may be a configuration error or an issue that may be resolved in future Act versions. There is an issue with duplicate Act job names that can be reviewed. I do think the act-js API can be improved and offer additional features such as mocking of composite action steps and inputs. This would reduce the boilerplate and remove the need to check for |
I'm going to close this PR as it will be difficult to hand over to somebody else. |
Resolves #32