I commented on an issue and closed it, and all I got was this lousy t-shirt GitHub Action failure email. Am I holding it wrong?
Possibly one for @wagoodman as he touched it last.
I commented on an issue and closed it, and all I got was this lousy t-shirt GitHub Action failure email. Am I holding it wrong?
Possibly one for @wagoodman as he touched it last.
I ran into this when commenting on a PR. Fixed with: fix: only remove awaiting response for issues, not PRs by kzantow · Pull Request #8 · anchore/workflows · GitHub
But I don’t think this fixes the case you ran in to.
I think @wagoodman had some plans to rethink how these workflows work, and we might as well discuss it here.
I think we’ve flip flopped a couple times from using labels to using project statuses to track when an issue is waiting for response from the requester.
It might be that we settle on project statuses because it doesn’t clutter up the audit trail on the issue.
When we do settle on an approach, that PR might be reverted (or changed to give a working code path for issues and PRs if necessary), because we want both issues and PRs to have the property that we can mark them as “awaiting response” and have that mark automatically removed when a user responds.
I wonder if there’s already something that does this? It’s a pretty common customer support / ticketing system flow…
Regardless of the specifics how we are tracking this awaiting user input state, I just have to say that having these workflows centralized is really great!