You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This makes it difficult to update the targeted runner across the organisation. Reusable workflows however can define the type of machine used within them in a single location.
Could we use a combination of composite actions, reusable workflows and organisational variables to reduce duplication here?
Details
e.g. in a structure like this the machine would only need to be specified in two places (or as many reusable workflow that exist) and be independent of the number of repositories (and only defined once if a variable was used)
In contrast, if each repository called each composite action directly and defined the target runner there, it would scale linearly with the number of repositories.
graph TD;
subgraph Composite Action 1
direction TB
A1[Checkout code]
A2[Set up environment]
A3[Run build script]
A4[Run tests]
end
subgraph Composite Action 2
direction TB
B1[Checkout code]
B2[Set up environment]
B3[Run linting]
B4[Deploy]
end
subgraph Composite Action 3
direction TB
C1[Checkout code]
C2[Set up environment]
C3[Run security scans]
C4[Build and test]
end
subgraph Composite Action 4
direction TB
D1[Checkout code]
D2[Set up environment]
D3[Generate documentation]
D4[Publish artifacts]
end
subgraph Reusable Workflow 1
direction TB
E1[Runs on: ubuntu-latest]
E2[Call Composite Action 1]
E3[Call Composite Action 2]
E4[Call Composite Action 3]
E1 --> E2
E2 --> A1
A1 --> A2
A2 --> A3
A3 --> A4
E1 --> E3
E3 --> B1
B1 --> B2
B2 --> B3
B3 --> B4
E1 --> E4
E4 --> C1
end
subgraph Reusable Workflow 2
direction TB
F1[Runs on: ubuntu-latest]
F2[Call Composite Action 3]
F3[Call Composite Action 4]
F1 --> F2
F2 --> C1
C1 --> C2
C2 --> C3
C3 --> C4
F1 --> F3
F3 --> D1
D1 --> D2
D2 --> D3
D3 --> D4
end
subgraph Main Workflow 1
direction TB
G1[Trigger: Push to main]
G2[Call Reusable Workflow 1]
G3[Call Reusable Workflow 2]
G1 --> G2
G2 --> E1
G1 --> G3
G3 --> F1
end
subgraph Main Workflow 2
direction TB
H1[Trigger: Pull request]
H2[Call Reusable Workflow 1]
H3[Call Reusable Workflow 2]
H1 --> H2
H2 --> E1
H1 --> H3
H3 --> F1
end
subgraph Main Workflow 3
direction TB
I1[Trigger: Schedule]
I2[Call Reusable Workflow 1]
I3[Call Reusable Workflow 2]
I1 --> I2
I2 --> E1
I1 --> I3
I3 --> F1
end
subgraph Main Workflow 4
direction TB
J1[Trigger: Tag creation]
J2[Call Reusable Workflow 1]
J3[Call Reusable Workflow 2]
J1 --> J2
J2 --> E1
J1 --> J3
J3 --> F1
end
Loading
Next Steps/Accepted Response
No response
The text was updated successfully, but these errors were encountered:
Short Description
Prompted by https://github.com/UCL-MIRSG/MIRSG/issues/237
With composite actions, the calling workflow and job defines
runs-on
and what runner machine is targeted. This means that we have to define this machine in each calling workflows -e.g. every repository includes that includes a copy of https://github.com/UCL-MIRSG/mirsg-template/blob/main/.github/workflows/manage-projects.yaml#L11This makes it difficult to update the targeted runner across the organisation. Reusable workflows however can define the type of machine used within them in a single location.
Could we use a combination of composite actions, reusable workflows and organisational variables to reduce duplication here?
Details
e.g. in a structure like this the machine would only need to be specified in two places (or as many reusable workflow that exist) and be independent of the number of repositories (and only defined once if a variable was used)
In contrast, if each repository called each composite action directly and defined the target runner there, it would scale linearly with the number of repositories.
Next Steps/Accepted Response
No response
The text was updated successfully, but these errors were encountered: