Test-infra: Automatically add issues/PR to a project board based on a GitHub query

[cblecker]

One missing feature of GitHub's project boards is the ability to automatically add issues/PRs to a project board based on a GitHub search query.

Two examples of how this would be useful:

• KEP tracking

is:open org:kubernetes label:kind/kep

would automatically be added to https://github.com/kubernetes-sigs/architecture-tracking/projects/2

• API reviews

is:open org:kubernetes label:kind/api-change

would automatically be added to https://github.com/kubernetes-sigs/architecture-tracking/projects/3

We'd probably only want to respond to label add or issue/PR open events rather than poll on a cron, because we'd want the ability to manually remove from a project board if it doesn't apply. But the thought is if we add a framework that we can configure with query = project card create, then we could reuse it in a lot of different places.

GitHub API docs: https://developer.github.com/v3/projects/cards/#create-a-project-card

cc: @jdumars @bgrant0607 @spiffxp @dims
also cc @idvoretskyi @guineveresaenger because this is something that IMO GitHub should do out of the box, considering the "Add a Card" button accepts a search query to find cards in the first place to add. 👀

[dims]

I like it @cblecker ! basically add things to Backlog right?

[nikhita]

/kind feature

[wwwil]

Hi! I've started on a solution to this and have something working which I'm going to tidy up and submit a PR for.

I plan to store the projects and associated queries in the plugins.yaml in the format:

projects:
  - name: my-project
    org: my-org
    query:
      state: open
      org: my-org
      labels:
        - my-label

I'm quite new to this project, Kubernetes and Go so any advice or feedback is appreciated! Thanks!

[stevekuznetsov]

Hello @wwwil!

I would suggest using "org/repo" as your keys as per other configurations. Look at the Tide configuration for query syntax exposed as configuration.

[stevekuznetsov]

Also, I would suggest writing a design document either as a pull request to test-infra or as a Google doc that you can share with [email protected]. I think there are a lot of potential open questions here:

• is this a plugin? Does it react to Pull Request events to catch new PRs, or changed PRs?
• is this a Prow component?
• is it a standalone cli command for admins?
• does it use GitHub queries verbatim? If so, how often does it sync? What are the implications for tokens use?

Often it's best to try to get answers to these questions before code is written so you don't have to re-write code in the future.

[stevekuznetsov]

Also would love to hear from @idvoretskyi @guineveresaenger to see if this is something that GitHub might implement, we wouldn't want to duplicate work!

[wwwil]

I'll check the Tide config and can change the keys. At the moment I have designed it as a plugin and it responds to PR open, close, reopen, add label and remove label events.

I'll enquire more about issues before getting started in future. I just started writing it as a way to learn about this project and practise writing Go, so I wasn't sure if I'd be able to make it work and I'm not too worried about it having been unnecessary in this case.

How would I go about providing a design document as a pull request? Would that just be an 'empty' pull request with the design proposal in the description?

[cblecker]

also cc @jessfraz 👀

[jessfraz]

I can ask about it internally definitely seems like something that’s perfect for an action though, but will pass this along and let you all know

Thanks for pinging me, keep doing this :)

[bgrant0607]

This would be awesome, btw. Our KEP tracking board is completely out of date now that KEPs moved.

[idvoretskyi]

@cblecker great suggestion, +1

[stevekuznetsov]

@wwwil a markdown file could work - however if you have most of the code already written it may not make the most sense. Maybe open the PR when you're ready and we can hash out some ideas there, or comment on this issue and we could do it here.

My two largest questions are:

• how are you determining if a pull request for which you've gotten an event matches a query? On the components where we expose queries, we use the query API to run them. Are you doing that, or parsing the data in the push event to determinine if it matches?
  
  
  
  • in what cases does this new plugin use additional API tokens? Do we want to create a plugin that always enforces the condition or one that's best effort? Will this impact API rate limits greatly? Queries can reference pretty much any of the attributes of a pull request, so it would be interesting to see when we need to reach out to GitHub for additional metadata on a PR when determining if it fits a query
  
  

[wwwil]

I've submitted a pull request for what I have so far. I hope it make's sense, I'm quite new to this so any feedback is appreciated.

Currently the plugin uses the data in the pull request event so the fields that can be used in a query are limited to the ones the plugin can work with.

As it's responding to pull request events I think that makes it best effort, as it won't add existing pull requests that match the query unless they change.

[guineveresaenger]

My apologies for missing this so far! I’ll look into this and ask around for sure. 🙂

[justaugustus]

/assign
/sig pm architecture testing

[justaugustus]

Very interested in this!
@wwwil -- when you have a design proposal in mind, can you also share it with [email protected]?

[wwwil]

@justaugustus I've updated my PR body to reflect the current design: https://github.com/kubernetes/test-infra/pull/10401

How should I go about sharing it? I've not really used Google groups much.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[spiffxp]

/assign @hh @brahmaroutu
/remove-lifecycle stale
this came up during the k8s-conformance meeting, there was discussion of a "project manager" plugin

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[justaugustus]

/remove-lifecycle stale
/lifecycle frozen
/priority important-soon
/milestone v1.17

[justaugustus]

Twitter thread on this: https://twitter.com/carolynvs/status/1166033270032801793?s=20
@guineveresaenger @carolynvs @jeremyrickard

Some work going on here: https://github.com/kubernetes/test-infra/pull/12326

[justaugustus]

What's the current status on this?
/milestone v1.18

[justaugustus]

/remove-sig pm
/sig contributor-experience

[spiffxp]

/remove-lifecycle frozen
/remove-priority important-soon
I still think this could be really cool but have no idea where it's at, and I don't think having it frozen has helped it move forward

[saschagrunert]

/cc