search

RedpointGames / uet

UET (Unreal Engine Tool) makes building and testing Unreal Engine projects and plugins easy. It can distribute builds with BuildGraph, remotely execute automation tests on device and across multiple machines, handles fault tolerance and automatic retries and generally makes the whole experience of automating Unreal Engine a lot more pleasant.
https://docs.redpoint.games/uet/
MIT License
64 stars 8 forks source link

[Mike Seese] GitHub Executor for `uet build` #30

Open hach-que opened 1 month ago

hach-que commented 1 month ago

While I understand Redpoint is well invested in the GitLab ecosystem and that this feature request may not come without contribution, I definitely would love to use this tool in GitHub Actions. I believe this requires a github executor for uet build (not sure since the documentation for CI/CD hasn't been written yet, so please correct me if I'm wrong).

hach-que commented 3 days ago

I have investigated this, and I don't believe it's possible to implement a GitHub Actions executor.

The problem is that GitHub does not support dynamically generating workflow YAML files and executing them. The closest you can get is dynamically generating a list of entries for matrix (see https://github.com/orgs/community/discussions/17245). However, we not only need to generate a list of jobs, but also be able to specify their needs section, which you can't do per matrix entry as far as I can tell (nor can you have matrix items depend on other matrix items).

The only possible way I could see this working is by having UET push a commit on top of the target commit to the target repository on some special branch name, whereby that commit adds a file called .github/workflows/uet-generated.yml, following by calling the "Create a workflow dispatch event" API endpoint. This is of course, extremely janky because we have to generate a new commit for every commit we want to build. I'm pretty sure that target commit needs to remove all other .github/workflows/ files to prevent recursive behaviour, and we need to delete the special branch after the downstream workflow completes regardless of success. This approach would also probably mean that the GitHub Actions UI will show the "generate" workflow and "generated" workflow as two separate entries - rather than them being connected in the UI like in GitLab.

mikeseese commented 3 days ago

Thanks for looking into this! Sounds good; I don't think the janky experience is necessarily worth it due to the substantial amount of generated build commits.

hach-que commented 1 day ago

https://github.com/orgs/community/discussions/146008 is the product feedback I've raised with GitHub.