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
Note: Given the context this story is not a priority and might be overkill - Please align with the repo owners before starting on this story.
Description
The release workflow will not be running often, it only run if a user triggers manually.
There is a risk that this workflow gets broken without us knowing it. For example, if somebody adds a mandatory arg to the basic station Dockerfile, the job building the image would be broken, but we would only notice it when creating a release.
A solution could be:
Trigger the release workflow on PR
Disable steps that we only want to happen on a real release. For example pushing images and the release creation would be disabled when the trigger is pull_request.
Acceptance criteria
The risk to break the release workflow is minimised
Most of the release workflow is tested on PR.
Tasks
Add a pull_request trigger
Disable release creation if the trigger is not workflow_dispatch
Disable publishing images to docker hub if the trigger is not workflow_dispatch
The text was updated successfully, but these errors were encountered:
Note: Given the context this story is not a priority and might be overkill - Please align with the repo owners before starting on this story.
Description
The release workflow will not be running often, it only run if a user triggers manually.
There is a risk that this workflow gets broken without us knowing it. For example, if somebody adds a mandatory arg to the basic station Dockerfile, the job building the image would be broken, but we would only notice it when creating a release.
A solution could be:
pull_request
.Acceptance criteria
Tasks
workflow_dispatch
workflow_dispatch
The text was updated successfully, but these errors were encountered: