I am trying to figure out how to optimize our builds by only building and testing what needs to be built and/or tested.
Let's say we have a 3-tier app in a single repository with structure with three "main" directories for each tier ("data", "api", "web") such as the below example.
.
├── data
│ ├── entities
│ ├── blah
│ ├── blah2
├── api
│ ├── blah
│ ├── blah2
├── web
│ ├── blah
│ ├── blah2
I would like:
- if there is a change in source code in "data" - do a "full" build (build "data", "api" and "web)
- if there is a change to source code in "api" - build "api" and "web" only
- if there is a change to source code in "web" - build "web" only
I have been able to essentially accomplish the above using the "paths" element of the github action workflow. For example, in the web.yml workflow:
on:
push:
paths:
- 'web/**'
Or, in the api.yml workflow:
on:
push:
paths:
- 'api/**'
But, if the commit contains changes in more than one folder, this becomes problematic, because more than one workflow will start.
There's some ability to use concurrency: as below:
concurrency: ${{ github.ref }}
And, there's even the ability to use cancel-in-progress as below:
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
But, here's the issue. How is there any priority to the cancellation?
For example, say a change is made to all three paths and all have the cancel-in-progress, how does github actions determine which two of the three to cancel.
Is there anyway to specify priority? In other words, can I specify in somewhat to keep the "full" build (or where paths: data)?
I can't figure out how to structure this to keep the workflow that starts the build in the correct spot in the dependency chain.
In other words, I would like:
- If a change is made to all three, keep the "full" or "data" workflow
- If a change is made to "api" and "web", keep the "api" workflow
- If a change is made to "data" and "web", keep the "data" workflow
Thoughts?