chore: Add metrics to update-release-branch workflow #1543
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,6 +27,16 @@ jobs: | |
| update-release: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Set start timestamp | ||
| id: start | ||
| run: printf 'timestamp=%(%s)T\n' >> "$GITHUB_OUTPUT" | ||
| - name: Configure AWS Credentials | ||
| uses: aws-actions/configure-aws-credentials@v4 | ||
| with: | ||
| role-to-assume: ${{ secrets.CI_AWS_ROLE_ARN }} | ||
| aws-region: us-west-2 | ||
| - name: Setup kat | ||
| uses: awslabs/aws-kotlin-repo-tools/.github/actions/setup-kat@main | ||
| - uses: actions/checkout@v4 | ||
| with: | ||
| ref: 'main' | ||
|
|
@@ -107,3 +117,23 @@ jobs: | |
| echo "pushing changes to release branch"; | ||
| git push origin release; | ||
| fi | ||
| - name: Calculate duration | ||
| id: end | ||
| run: | | ||
| printf -v now '%(%s)T' | ||
| duration=$(( now - ${{ steps.start.outputs.timestamp }} )) | ||
| printf 'duration=$duration\n' >> "$GITHUB_OUTPUT" | ||
| - name: Emit metrics | ||
| if: always() # run this step even if previous steps failed or the job is canceled | ||
| uses: awslabs/aws-kotlin-repo-tools/.github/actions/emit-metrics | ||
| with: | ||
| namespace: CI Metrics | ||
| dimensions: | | ||
| Product=aws-sdk-kotlin | ||
| Trigger=${{ github.event_name == 'schedule' && 'schedule' || 'manual' }} | ||
| metrics: | | ||
| ReleaseMergeAttempted:1:Count | ||
| ReleaseMergeSucceeded:${{ job.status == 'success' && '1' || '0' }}:Count | ||
|
Contributor
There was a problem hiding this comment. Question: If the job is canceled or fails before this step runs, would we still be able to emit metrics?
Contributor
Author
There was a problem hiding this comment. As you noted above, this step will always run regardless of whether previous steps have failed or the job's been canceled. |
||
| ReleaseMergeCanceled:${{ job.status == 'cancelled' && '1' || '0' }}:Count | ||
| ReleaseMergeFailed:${{ job.status == 'failure' && '1' || '0' }}:Count | ||
| ReleaseMergeDuration:${{ steps.end.outputs.duration }}:Seconds | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is duration a meaningful metric for this job? Since it runs on an automated schedule at 3AM, I don't think we care if it takes 5, 15, even 30 minutes, just that it succeeds or fails.
GitHub already has a default timeout of 6 hours, so we could never get into a situation where the job runs for 24+ hours and conflicts with subsequent merge jobs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe durations are always useful, particularly when they start being larger/smaller than one expects. You're right, we don't necessarily care whether it's 5 minutes or 30 minutes but we probably care if it's always been 5 minutes and suddenly becomes 30 minutes.
Additionally, we do run this job manually from time to time which means we'd be waiting for it to complete. In that case, I believe we would care more about time.