698c08cf4e
Cancelled or timeouted workflow would keep the docker container running. Closes game-ci/unity-test-runner#197 This has two parts: Part one. The entrypoints. `runs.post`: GitHub Action metadata allow running something after the action (regardless of a failure, crash, timeout, ...). https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runspost However, it needs to be a `.js` file and it can't be configured to pass any arguments. There already was `index.js` used as the main entrypoint. The build process of this file uses typescript compiler and ncc to pack all dependencies into one .js file. And ncc has no way of generating multiple files in one go, so the only solution would be to run ncc twice and generate two independent files. That would be quite unfortunate, wasting time and storage. So I rather came up with a new entrypoint that symlinked from two locations. And this new entrypoint understands how it was executed, so it can run the correct behaviour. This makes it easy to add `runs.pre` if needed. This new entrypoint is in `index.ts`. The original `index.ts` is now in `main.ts`. Part two. The signals. I've tried: * try/catch/finally around the `await Docker.run`. Catch and finally are not executed when process receives SIGINT. See the discussion in: https://github.com/nodejs/node/discussions/29480 * New AbortController and AbortSignal. Great concept, but the action.exec does not support it. So it can't be aborted. * Doing cleanup on `process.on('exit')`. Unfortunately you can't really do async stuff from there, so can't really run the docker rm command to delete the container. * Using `process.on('SIGINT')`. For some reason that wasn't really executing for me. I'd not put my hand in fire for this, but I assume because it was in the signal handler it does something special, or would heed to be scheduled for later with `setTimeout(0)`. Evaluating all these I came to a conclusion that it is fragile and just relying on a `runs.post` is much better and safer. ` |
||
|---|---|---|
| .github | ||
| .husky | ||
| artifacts | ||
| dist | ||
| media | ||
| src | ||
| unity-project-with-correct-tests | ||
| .dockerignore | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .gitattributes | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc.json | ||
| .yarnrc | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| action.yml | ||
| jest.config.js | ||
| package.json | ||
| tsconfig.json | ||
| yarn.lock | ||
README.md
Unity - Test runner
(Not affiliated with Unity Technologies)
GitHub Action to run tests for any Unity project.
Part of the GameCI open source project.
How to use
Find the docs on the GameCI documentation website.
Related actions
Visit the GameCI Unity Actions status repository for related Actions.
Community
Feel free to join us on
and engage with the community.
Contributing
To help improve the documentation, please find the docs repository.
To contribute to this project, kindly read the contribution guide.
Support us
GameCI is free for everyone forever.
You can support us at OpenCollective.
Licence
This repository is MIT licensed.
This includes all contributions from the community.