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
We saw this open issue, however our use case is different enough I thought a new issue (feature request) would be optimal. I'll try to explain our use case and provide sample YAML.
Use Case
We use GitHub Actions to manage CI/CD for a fairly large number of repos in support of a set of microservices that operate in Kubernetes. Since we have a multi-repo setup (a dedicated repo for each microservice) we designed our CI/CD pipelines such that the single workflow file residing in each microservice repo is as simple and uniform as possible. For example (I cannot provide the rest without redactions):
The peter-evans/repository-dispatch@v1 action allows us to specify another GitHub repo where the actual build is run. Envision the snippet above as the service-1 build_service.yml that dispatches the build request to another repo named central-builds which has a more complex workflow that:
is shared by all microservice repo workflows
can take in client-payload attributes to drive conditional logic
The purpose of this design is to allow us to manage changes to our pipelines in a single workflow in one repo only.
Workflow with Notification Logic
The workflow file in central-builds is the one we are interested in with respect to Slack notifications, as this is the workflow that builds the image, pushes it to the ECR (or GCR) and perhaps deploys the image to a cloud environment.
Here is the notification-related snippet from that workflow:
This ^ is where we need some assistance (or perhaps our use case is a feature request). The notification surfaces in Slack, however - given our design - the commit (AS_COMMIT) field is not useful, as it links to a commit in central-builds. We would like some way to link to the commit associated with the PR that triggered the build in the service-1 repository.
The text was updated successfully, but these errors were encountered:
bwmills
changed the title
Notification Field Support for Workflow with repository-dispatch@v1
Notification Field Support for Workflow with repository-dispatch
Oct 25, 2021
We achieved the desired behavior by using reusable workflows. This GitHub Actions feature allows our centralized build setup (described above) to have the build be controlled by the centralized workflow but run in the microservice repo.
When a microservice repo (small, uniform workflow) gets triggered, it is now a caller workflow and the centralized workflow (in a central-builds repo) is the called workflow (with all the actions and various logic) ... with this setup, the build itself actually runs in the microservice repo ... so:
The Actions build log resides in the repo where the code change that triggered the build occurred
The resulting action-slack-driven notification (defined in the called workflow) now has usable links to the microservice repo, build log, and commit.
Greetings,
We saw this open issue, however our use case is different enough I thought a new issue (feature request) would be optimal. I'll try to explain our use case and provide sample YAML.
Use Case
We use GitHub Actions to manage CI/CD for a fairly large number of repos in support of a set of microservices that operate in Kubernetes. Since we have a multi-repo setup (a dedicated repo for each microservice) we designed our CI/CD pipelines such that the single workflow file residing in each microservice repo is as simple and uniform as possible. For example (I cannot provide the rest without redactions):
The
peter-evans/repository-dispatch@v1
action allows us to specify another GitHub repo where the actual build is run. Envision the snippet above as the service-1 build_service.yml that dispatches the build request to another repo named central-builds which has a more complex workflow that:client-payload
attributes to drive conditional logicThe purpose of this design is to allow us to manage changes to our pipelines in a single workflow in one repo only.
Workflow with Notification Logic
The workflow file in central-builds is the one we are interested in with respect to Slack notifications, as this is the workflow that builds the image, pushes it to the ECR (or GCR) and perhaps deploys the image to a cloud environment.
Here is the notification-related snippet from that workflow:
This ^ is where we need some assistance (or perhaps our use case is a feature request). The notification surfaces in Slack, however - given our design - the commit (AS_COMMIT) field is not useful, as it links to a commit in central-builds. We would like some way to link to the commit associated with the PR that triggered the build in the service-1 repository.
The text was updated successfully, but these errors were encountered: