Make existing build workflows reusable #499
Conversation
Disable msbuild workflow triggers on push to master/dev branches and add parameters for workflow call inputs Remove `push` workflow triggers, as they are no longer required and will be triggered by calling workflow. Add inout parameters to define which build configuration to use an whether this run should upload its build artefacts.
Rework the meson build workflow to act as a callable workflow in a composite job. Disable triggering on pushes to dev/master. Add input parameters to call this workflow with, that dictate: - whether to upload build artefacts from this workflow - which meson build type to use (release/debug) - which debug level, if any, to compile the code at. Switched `meson 0.6.0 => 0.6.3` to match the version in our CI script. Split Meson setup/configuration to accommodate upload/non-upload invocations of the workflow Configured the upload step to fail with errors if no artefacts are found to be uploaded (when the relevant setting is configured).
Remove all duplicated code and replace it with calls to the new msbuild and meson build workflows. Update the concurrency group so that we don't waste time re-running the CI on outdated code. Rename top-level workflow.
|
This is technically a duplicate & extension of work done in #461, however that one never made it to the main branches and likely won't as it'll be discarded and re-written. |
traunts
changed the title
If it's there, it's far too late.
New builds no longer have the trailing ` x64` on their exe filepath, removed so any build artefacts are correctly uploaded.
…p outputs instead of env vars
…github.com/cortex-command-community/Cortex-Command-Community-Project-Source into 470-make-existing-build-workflows-reusable
…ather than env variables
Adds a new `master_build` workflow, identical to the existing CI workflow except: - It only runs on new pushes to `master` - It uploads all build artefacts to make them available for release Minor comment formatting.
|
Another irk that I had with these changes is GitHub's damn response to the concurrency changes. It sees a workflow run that's cancelled (due to newer changes invalidating the output of the run) as a job failure (marking that commit as failing checks) and sends a pesky email every time. Not sure if there's a way to filter these so that cancellations are discarded, and it's more a personal peeve than anything else, but I thought it best to make known. |
I'd certainly be happy to not have email spams haha. But if I have to have it, so be it I guess. |
The issue only occurs when repeatedly pushing to the same PR in a short span of time. It saves wasted workflow runs, but each run that it cancels incurs the notification. For large sets of batched changes it's non-existent, just an issue for constant small ones that are pushed before CI finishes. |
…le when uploading artefacts Add an extended glob pattern to match either of them if present (trailing `_debug`)
…ultiple path references
Refactor the two build workflows,
msbuildandmesonto be reusable per #470, and use these changes to simplify the CI script vastly.Reduces code duplication so we don't have to maintain more than one copy of a build script at any given time.
Resolves an issue where we built a debug build instead of a release build when performing compilation checks.
Required work for #460 (or at least, simplifies anything that needs to build the game rather than duplicating code).