Usage of "agenda" label to get PRs and Issues automatically added to the Open Community Weekly Meetings agenda.

[benjagm]

Open Community Weekly Meeting: 2023-01-16

Work Summary:
In the past Open Community Working Meeting 2023-01-16 #294, we agreed on the usage of a new "agenda" label for tagging PRs or issues to be discussed in the meeting

As a result, a new action was captured owned by @benjagm with the purpose of building a GitHub automation to add the tagged issues/PRs as agenda items of the Open Community Weekly Meetings. For more context please check #294 notes and recording.

Context:
JSON Schema Community is running an Open Community Weekly Meeting every Monday. For every meeting, a new issue is created 6 days before the meeting using the OCWM template, and during that time, everyone in the community is free to add new topics to the agenda. With this feature, we can make it easier to include PRs to be discussed as part of the agenda without having to do all the work manually.

Automation trigger:
Every time someone adds the label "agenda" to a PR, that PR should be included in the agenda of the upcoming OCWM.

Outcome
A new item will be added to the agenda, the PR will be added to the Topic column and the author to the Owner column.

Completing this work will mean the automation has been built, tested, and communicated among the community.

Do you think this work might require an Architectural Decision Record (ADR)? (significant or noteworthy)

No

Work Detail:

• Gather sample actions with a similar purpose.(@0xsudarshan)
• Minimum requirements.(@0xsudarshan)
• Development.(@0xsudarshan)
• Test. (@0xsudarshan)
• Install in JSON Schema organizacion (@benjagm)
• Ready.
• Communicated to the Community.

Any further requirements to resolve this issue

[Relequestual]

The OpenJS Foundation uses https://github.com/nodejs/create-node-meeting-artifacts
We may not want to copy all of it, but some of it may be useful.

[benjagm]

Other resources:

• https://blog.marcnuri.com/triggering-github-actions-across-different-repositories
• https://github.com/marketplace/actions/select-matching-issues

[benjagm]

A great next feature to implement from here is to automatize 1)the messages to slack and 2) to social media to promote new Open Community Weekly Meetings.

One possible solution would be to configure Webhooks in every repository or at an organisation level and whenever there is a pull request with a particular label we trigger a workflow that edits the existing issue with the newly raised PR as well as author of the PR but the problem is only issue owners and users with push access can edit an issue. Maybe we could just use the owner / or someone with the write access (could pass their creds manually instead) to edit it out I guess

[benjagm]

Congrats for the great research @0xsudarshan . This is a great starting point but there are some clarifications needed.

• Trigger: The trigger should be the "labeled" action over the "pull_request" event. More info here
• The destination file to add the labeled PRs details should be the agenda issue of the upcoming OCWM.

The next step in my opinion might be to build and try this in a testing repo.

[Relequestual]

We might need to modify this issue, as I haven't found anything that supports org wide action triggers without using a webhook, which isn't ideal.

What might be preferable is to have an action which runs on a schedule to collect Issues and PRs from the org with the required label, and then replaces the right part of the template in the latest OCWM issue.

Would be best to do this in a test org.

[Relequestual]

@0xsudarshan I think you are looking for these details: https://docs.github.com/en/actions/security-guides/automatic-token-authentication ?

Also worth noting that there are a load of existing examples you can look at : https://github.com/actions

@Relequestual I am going to change my approach as to what u said . I was in an assumption that we will be implementing this to all repositories that come under this organisation so thought Webhooks would be the way to go since it captures event at org level and there wouldn't be any need for us to create it in individual repos .(I will avoid using using webhooks) and as you mentioned there aren't any org wise action triggers we need to set up actions in individual repository . I don't think we need a scheduler tho , we could just update the latest OCWM issue with the PR and the author name when the workflow is triggered in a particular repo that has a pr with the label "agenda"

[gregsdennis]

I haven't found anything that supports org wide action triggers without using a webhook - @Relequestual

I found https://blog.marcnuri.com/triggering-github-actions-across-different-repositories during the meeting.

[Relequestual]

I haven't found anything that supports org wide action triggers without using a webhook - @Relequestual

I found https://blog.marcnuri.com/triggering-github-actions-across-different-repositories during the meeting.

That's cool, but we need a "trigger", not "triggering".
Webhooks would be the only viable way to proxy such, but I think an alternative approach would be better.

[Relequestual]

... I don't think we need a scheduler tho , we could just update the latest OCWM issue with the PR and the author name when the workflow is triggered in a particular repo that has a pr with the label "agenda" - @0xsudarshan

It needs to be Issues, PR's, and Discussions, across the org, but with the ability to exclude specific repos.

In fact, I think just making sure only PUBLIC repos are considered should be enough. We just don't want to automatically do anything based on anything in private repos in the org.

The workflow could be run manually. This would enable us to choose to run it or not depending on if the meeting is happening. We could modify the Issue template for the meeting to include a link to the workflow. We will need to modify it anyway to include a placeholder.

@Relequestual @benjagm @gregsdennis :

1. We create a workflow which triggers when a PR/issue/discussion is raised under the label "agenda"
2. The above can be be setup in public repos we need
3. We create another workflow in separate a repository just like https://github.com/nodejs/create-node-meeting-artifacts that gets triggered when 1. gets triggered (this can be done using repository_dispatch - https://blog.marcnuri.com/triggering-github-actions-across-different-repositories )and make sure the workflow runs node js scripts to update the latest OCWM issue.
   Let me know if this sounds reasonable ?
   Also i do agree in making the workflow manual. we could do that as well

[benjagm]

I agree with @Relequestual on the benefits of triggering the workflow manually.
@0xsudarshan lets follow the approach of building the logic in node.js like https://github.com/nodejs/create-node-meeting-artifacts to make it easier to modify the issue.

To make it easier to add the information to the PR we just need to add a placeholder (like https://github.com/nodejs/create-node-meeting-artifacts).