Deployment Workflow #101
Deployment Workflow #101
Conversation
There was a problem hiding this comment.
Thanks for your work here @shanice-skylight! Left a couple question below, but not going to block anything because I haven't been looped into this work for the last couple days.
| run: | | ||
| # Parse the service name from the payload | ||
| service_name=${{ github.event.client_payload.service }} | ||
| echo "Service Name: $service_name" |
There was a problem hiding this comment.
If we are parsing out service name here then this is really a general deployment workflow that can deploy any service not just the Query Connector. However the current workflow name, QC Target Workflow, suggestions things are scoped more narrowly to just the Query Connector. Am I following this correctly? Would it make sense to update the name?
| outputs: | ||
| tf_env: ${{ steps.set-environment.outputs.tf_env }} | ||
| steps: | ||
| - name: Checkout code |
There was a problem hiding this comment.
I'm confused why we need to checkout code from dibbs-query-connector if the service name and version are passed in separately.
PULL REQUEST
Summary
This PR will add a workflow that is triggered by the repo dibbs-query-connector. See explanation of each step of the workflow below:
shafield of theclient_payloadobject of the triggering event. This allows the workflow to operate on the exact code state associated with the triggering eventStep named Extract Service Name & Version will extract and display the service name and version values from the
client_payloadobject of the triggering event. These values are passed when the workflow is manually triggered and are stored in the payload for use in downstream steps.***Note: The intent is for this to automatically trigger but starting with manual for testing purposes ***
The remaining steps are pulled from the workflow named awsDeployment. The end result is the image for Query Connector is pulled from the repo dibbs-query-connector and deployed to the EKS pod
Related Issue
Fixes Issue 79