Add a shared GitHub workflow for notifications #8
Conversation
yrodiere
left a comment
yrodiere
left a comment
There was a problem hiding this comment.
Too fast as always :) Thanks. I added a few comments, and one of them makes me think this wasn't tested yet, but before you work on this more, maybe let's talk; I wonder if hibernate-github-bot wouldn't be a simpler and more powerful solution to the whole thing; able to provide the Develocity report directly in the notification...
But that definitely isn't high-priority work -- I'm mainly mentioning it because if we do that, we'll have to remove calls to this workflow from all other workflows, so... it'd be annoying.
So, yeah, let's talk :)
| # jobs: | ||
| # notification: | ||
| # name: Notify about build failures | ||
| # # List the other build jobs that we want to "monitor for failures": | ||
| # needs: build | ||
| # if: ${{failure()}} | ||
| # uses: hibernate/.github/.github/workflows/send-notification.yml@main | ||
| # build: | ||
| # name: ... |
There was a problem hiding this comment.
This makes me think that we probably don't want this notification to be sent on PRs... So I guess the "if" will be a bit more complex.
| api-key: ${{ secrets.ZULIP_GITHUB_WORKFLOW_NOTIFICATION_API_KEY }} | ||
| email: ${{ secrets.ZULIP_GITHUB_WORKFLOW_NOTIFICATION_EMAIL }} |
There was a problem hiding this comment.
I think secrets need to be passed from the calling workflow, correct?
There was a problem hiding this comment.
yeah ... that's what I wasn't entirely sure about, I mean when I tested the action option it was clearly failing with a message that it cannot access secrets and from the docs, one need to pass secrets to action through input paramteres... so that's when I switched to testing the workflow... here it does not complain about the use of secret in the workflow, and I was hoping that if we have the secret in the repo where the workflow is or as an org secret thigns would work.... because if we end up passing the secret at the "call site" then it kind of defeats the purpose of sharing this particular workflow 😔 😕 🙂
2 participants
I've removed any input parameters from the notification workflow (initially I had a message parameter to pass from the "project" side... but decided that it would be best if we have 0 parameters instead 🙂)
One "downside", if we can call it that, would be that we won't be able to reference the workflow by a commit hash (that is since we want to be able to change the notification without changing the project workflows ...)
Tested this on my forks:
and
(I haven't tested the message part itself, since we don't have the bot setup yet)