WordPress / wordpress-playground

Run WordPress in the browser via WebAssembly PHP
https://w.org/playground/
GNU General Public License v2.0
1.66k stars 263 forks source link

GitHub Board Automation workflow is currently failing #1875

Open brandonpayton opened 1 month ago

brandonpayton commented 1 month ago

Our GitHub Board Automation is currently failing due to permissions issues again: https://github.com/WordPress/wordpress-playground/actions/runs/11257363931/job/31301419485#step:3:8264

"adamziel does not have the correct permissions to execute `CreateLabel`"

Maybe we need to just tolerate these permissions. 🤔 I haven't thought it through yet.

brandonpayton commented 1 month ago

It looks like we can approach this differently. Instead of having our automation work based on when a "Needs Author's Reply" label, we can use the moveProjectCard mutation and the MovedColumnsInProject event. Doing this should work around this case where we do not have permission to create labels in others' repos.

If it adds clarity when viewing individual issues, we can continue to attempt adding and removing those labels, but we would no longer depend on the labels for the automation to work.

adamziel commented 5 days ago

I like that idea 💯

adamziel commented 5 days ago

Oh, I remember why I did the label. The checkIfAuthorRepliedAfterLabelWasCreated method uses the timestamp of the "issue timeline items" to determine whether the reply happened before or after the card was marked as "needs reply". AFAIR I couldn't reliably get timeline items for "moved to a project board column" but I could for "assigned a label". See the list of issue event types.

Another solution would be to use another data store. We could store the timestamp when the card is first seen as "needs author's reply" and then compare it with the timestamp of the last comment.

Or we could just let go of the automation and have a column like "awaiting reply" that we review every week or two and manually archive older cards.

adamziel commented 5 days ago

Well, and then we could replace "not doing" and "future work" with just manually removing the card from the board. It's one more click and less code to maintain. And then there's nothing else that our board automation handles so we could just get rid of it and never fix a bug again. I'll go ahead and disable it, but I'm happy to re-enable if you think that would be more useful – what do you think @brandonpayton @bgrgicak @zaerl? If we're aligned, we can just delete the related code.