Is it possible to use more than one GitHub Labels for the GitHub Issue/PR by-label badges?

[JFQueralt]

Been looking around and couldn't find an answer to this.

This shield generates based on one label (Need: Position)

We would like however to be able to filter further by doing
Need: Position + Stage: Ready

Rationale: We publish issues in different stages and it would help to be able to show the actual number of issues that a "Ready".

Thoughts?

[calebcartwright]

At the moment I don't think so. If I recall correctly the entire input is utilized as a single label within the graphql query so any attempts to specify multiple labels for the route parameter would just end up as a long/odd singular label.

I think it'd be reasonable to try to support this, though figuring out a good way of handling the badge label would be tricky with an open ended set of input GH labels

[JFQueralt]

I am not acquainted with GitHub API (could have a look at it, I guess) and I'll assume that the limitation could come from there.
That said, if they allow filtering via querystring then it makes little sense that they wouldn't support it too.
If I source some time (🤞) I'll have a look around.

[calebcartwright]

It's a GraphQL query using the v4 API:

shields/services/github/github-issues.service.js

Lines 317 to 384 in 87d8028

	async fetch({ isPR, isClosed, user, repo, label }) {
	const commonVariables = {
	user,
	repo,
	labels: label ? [label] : undefined,
	}
	if (isPR) {
	const {
	data: {
	repository: {
	pullRequests: { totalCount },
	},
	},
	} = await this._requestGraphql({
	query: gql`
	query(
	$user: String!
	$repo: String!
	$states: [PullRequestState!]
	$labels: [String!]
	) {
	repository(owner: $user, name: $repo) {
	pullRequests(states: $states, labels: $labels) {
	totalCount
	}
	}
	}
	`,
	variables: {
	...commonVariables,
	states: isClosed ? ['MERGED', 'CLOSED'] : ['OPEN'],
	},
	schema: pullRequestCountSchema,
	transformErrors,
	})
	return { issueCount: totalCount }
	} else {
	const {
	data: {
	repository: {
	issues: { totalCount },
	},
	},
	} = await this._requestGraphql({
	query: gql`
	query(
	$user: String!
	$repo: String!
	$states: [IssueState!]
	$labels: [String!]
	) {
	repository(owner: $user, name: $repo) {
	issues(states: $states, labels: $labels) {
	totalCount
	}
	}
	}
	`,
	variables: {
	...commonVariables,
	states: isClosed ? ['CLOSED'] : ['OPEN'],
	},
	schema: issueCountSchema,
	transformErrors,
	})
	return { issueCount: totalCount }
	}
	}

I'm not sure how that could best be mapped to an AND type filter on the labels off hand either

[JFQueralt]

I'd need to look more closely into the code to see if I can propose a change. Maybe this weekend as we have a code sprint in Project Lockdown (https://github.com/TheIOFoundation/ProjectLockdown)

That said, I found this post and tested the AND functionality successfully although only with 2 labels so far.
(Few quick tests didn't work out for more labels for an AND operation - Anything added to the filterBy field operates as an OR)

Well, at least it's something

{
repository(owner: "TheIOFoundation", name: "ProjectLockdown") {
label(name: "Stage: Not Ready") {
issues(first: 100, after: null, filterBy: {labels: ["Need: Code"]}) {
totalCount
pageInfo {
startCursor
hasNextPage
endCursor
}
edges {
node {
number
title
resourcePath
url
state
labels(first: 100) {
edges {
node {
name
}
}
}
}
}
}
}
}
}

[chris48s]

I appreciate I'm scope-creeping this a bit, but here's a bigger idea..

In the github front-end, it is possible to construct fairly nuanced issue/PR queries. For example:

• is:open is:issue label:core label:bug author:app/sentry-io - open issues with the labels "core" and "bug" opened by sentry-io bot: https://github.com/badges/shields/issues?q=is%3Aopen+is%3Aissue+label%3Acore+label%3Abug+author%3Aapp%2Fsentry-io
• is:pr is:closed label:npm-package review:approved author:chris48s - closed PRs labelled "npm-package" submitted by user "chris48s" with one or more approving reviews: https://github.com/badges/shields/pulls?q=is%3Apr+is%3Aclosed+label%3Anpm-package+review%3Aapproved+author%3Achris48s

If we're going to go down the route of extending these badges to allow more advanced queries, I think the ideal solution would actually be if we supported that same query syntax in its entirity. Then users can build a query through the GH frontend and once they're happy with it, pass the query to a badge URL in a querystring. One of the nice things about the Github V4 API (which didn't exist when these badges were first designed) is we can actually use that syntax directly in a GraphQL query. So the queries above translate to:

query {
  search(query: "repo:badges/shields is:open is:issue label:core label:bug author:app/sentry-io", type: ISSUE) {
    issueCount
  }
}

and

query {
  search(query: "repo:badges/shields is:pr is:closed label:npm-package review:approved author:chris48s", type: ISSUE) {
    issueCount
  }
}

I think rather than gradually implement that syntax one feature request at a time, how about we implement one badge:

Github Issue (with arbitrary query): /github/issue-query?q=...

..and then we make our existing random mashup of github issue/PR variant badges redirects to preset queries on that general badge but we say "no more presets". Then any arbitrary query you can make through the GH builder can be a badge, we put this to bed once and for all and we can collapse this mess.

Thoughts?

[JFQueralt]

I was originally hoping for this to be the way to go as the querystring made a lot of sense.
The problem I found and made me go to the GraphQL I posted was that I couldn't figure out how to pass labels with special characters such as spaces and ":". I tried all I could think of and the query always returned 0.

[JFQueralt]

Just tried again using all combinations I could think of and it doesn't fly.
Ideas?

query {
search(first: 100, type: ISSUE, query: "repo:TheIOFoundation/ProjectLockdown state:closed label:'Team: Devs'") {
issueCount
pageInfo {
hasNextPage
endCursor
}
edges {
node {
... on Issue {
createdAt
title
url,
repository {
name
}
}
}
}
}
}

[calebcartwright]

Thoughts?

Yeah I think that's fair and had it in the back of my mind too as I feel like something similar came up on a different thread not too terribly long ago. It does beg a few questions for me though:

• Do the user friendly queries always map nicely 1:1 with their corresponding graphql queries?
• What should the story with the badge labels be on the new badges, maybe something generic like count or query or could we still have issues and pulls? Would our redirectors need to tack on a ?label query param (conditionally to avoid stomping any already custom labels) to the new route?
• Does this have any potential implications on our token query hits/rate limiting?

[calebcartwright]

Just tried again using all combinations I could think of and it doesn't fly.
Ideas?

What about this?
query: "org:TheIOFoundation repo:ProjectLockdown state:closed label:\"Team: Devs\"

[chris48s]

@JFQueralt The corresponding graphql query for

https://github.com/TheIOFoundation/ProjectLockdown/issues?q=is%3Aopen+is%3Aissue+label%3A%22Need%3A+Position%22+label%3A%22Stage%3A+Ready%22

would be

query {
  search(query: "repo:TheIOFoundation/ProjectLockdown is:open is:issue label:\"Need: Position\" label:\"Stage: Ready\"", type: ISSUE) {
    issueCount
  }
}

@calebcartwright

Do the user friendly queries always map nicely 1:1 with their corresponding graphql queries?

That is a good question. As far as I'm aware, yes but unfortunately the docs are not totally clear so we should test. I'd be surprised if there is any divergence though.

What should the story with the badge labels be on the new badges

For the existing badges, we should retain the same labels. I think for the "arbitrary search query" badge I think we just have to give it a generic label like "query" or "search" and leave it to the user to pass a suitable ?label= arg. I don't think we can attempt to generically parse something like is:open is:issue label:core label:bug author:app/sentry-io into a useful label.

Would our redirectors need to tack on a ?label query param (conditionally to avoid stomping any already custom labels) to the new route?

Yes. I'd envisage that adding a ?label= would be part of the redirect. Another thing we could do is instead of changing the existing ones to a redirect would be to just have one shared fetch() function and simplify the code under the hood but keep the existing special cases serving a badge directly without issueing a redirect if we wanted (but still not add more special-cases).

Does this have any potential implications on our token query hits/rate limiting?

As long as we only return the count, it is a single node query so one rate limit point regardless of the query.

[calebcartwright]

As long as we only return the count, it is a single node query so one rate limit point regardless of the query.

Excellent! Maybe I just haven't spent enough with these GitHub queries but it always impresses me how much of this knowledge you seem to keep in your head 😄

[JFQueralt]

Fantastic. "" never crossed my mind.

Excited about the possibilities.

[chris48s]

it always impresses me how much of this knowledge you seem to keep in your head

📚 I cheated and read the docs 😆

I've made an issue for this based on the discussion: #5948

[chris48s]

We've now deployed the generic issue search badge so you can now make this badge (and many others) using a custom query:
- https://img.shields.io/github/issues-search/TheIOFoundation/ProjectLockdown?query=is%3Aopen%20is%3Aissue%20label%3A%22Need%3A%20Position%22%20label%3A%22Stage%3A%20Ready%22

to customise the label:
- https://img.shields.io/github/issues-search/TheIOFoundation/ProjectLockdown?query=is%3Aopen%20is%3Aissue%20label%3A%22Need%3A%20Position%22%20label%3A%22Stage%3A%20Ready%22&label=custom%20label

so I'm going to mark this as answered

[JFQueralt]

Thanks for that!

I am testing it and it works like a charm. For reference, it works even if the labels have UTF emojis on them (which was my current concern after we "beautified" them these past days.

Sample:

https://github.com/TheIOFoundation/ProjectLockdown/issues?q=is%3Aopen+is%3Aissue+label%3A%22%F0%9F%96%96+Need%3A+Position%22

Truly appreciated, this is going to be of great help.