Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Github: Support PR/issues with labels, full count #1020

Closed
wants to merge 3 commits into from

Conversation

dagwieers
Copy link
Contributor

@dagwieers dagwieers commented Jun 27, 2017

This PR includes the following:

  • Simplified the code, but kept it full-featured
    • Use the issues API for all calls to Github
    • Got rid of the repos API for some of the queries
  • It now displays more exact issue numbers (no longer indicates 30+)
  • It can now display the number of PRs by label too (not just issues only)
  • Can display the used label name too for completeness

This fixes #839
This fixes #420
This implements #862 partly

image

@dagwieers dagwieers force-pushed the github-fullsupport branch 10 times, most recently from 2a990a1 to 6fdb4c7 Compare June 27, 2017 17:21
@jhawkesworth
Copy link

nice!

@dagwieers dagwieers force-pushed the github-fullsupport branch 4 times, most recently from 168c081 to 3823df9 Compare June 27, 2017 22:53
@StoneCypher
Copy link

can the issues by-label include the label though? without that it might quickly get confusing

@dagwieers
Copy link
Contributor Author

@StoneCypher In our use-case, the context is very clear, so there is no need for that.
e.g. https://github.com/ansible/community/wiki/Windows:-action-list

But if you're going to add multiple of these on a single page, I see your point.
The question is how we are going to tell the code when the label should be shown.

Let me know what you like here. We could add -label to in there somewhere ?

@dagwieers
Copy link
Contributor Author

@StoneCypher I now do this:

image

So basically, if you provide -raw it does not add the label, otherwise it will.
Is this OK for you ?

@StoneCypher
Copy link

ya 😄

@dagwieers
Copy link
Contributor Author

@StoneCypher Enjoy !

PS Now I have to find out how to get this merged, because I would like to use it for real !

@StoneCypher
Copy link

Well, if I tag @espadrine , then you weren't the obnoxious one 😀

@dagwieers
Copy link
Contributor Author

@StoneCypher Not sure if you had any summoning powers before, but they are surely failing now ;-)

@StoneCypher
Copy link

they did indeed

@StoneCypher
Copy link

@Daniel15 - any chance of looking at this? This is rly valuable

Copy link
Member

@paulmelnikow paulmelnikow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi! Thanks for this. Could you add a service test which covers the new functionality?

@dagwieers
Copy link
Contributor Author

dagwieers commented Sep 23, 2017

@paulmelnikow Done.

The original code has been simplified as well, but commented out.
I don't think we need the original code using the issues API, as it has
some limitations (no label support, only up to 30, or 100 issues).
As requested, we now add the GitHub label to the badge, only if not
specifying `-raw` in the URL.
@StoneCypher
Copy link

@paulmelnikow (thank you)

@paulmelnikow paulmelnikow self-assigned this Sep 24, 2017
@paulmelnikow
Copy link
Member

Am I correct that /github/issues now returns only issues, and not issues + PRs?

Copy link
Member

@paulmelnikow paulmelnikow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests look great! Clarifies the API too, which I've made some comments on. Really excited about this functionality. Shields could use a count of beginner-friendly issues on the readme or contributing pages.

.expectJSONTypes(Joi.object().keys({
name: Joi.equal('issues'),
value: Joi.string().regex(/^[0-9]+[kMGTPEZY]?$/)
}));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about calling this -minimalist or -clean, or better yet, /issues/minimalist, rather than -raw? It seems to clarify that it's affecting the formatting, rather than the underlying number.

Copy link
Contributor Author

@dagwieers dagwieers Sep 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't introduce -raw, it was called like this before. I don't think we an break the existing interface.

.expectJSONTypes(Joi.object().keys({
name: Joi.equal('closed issues'),
value: Joi.string().regex(/^[0-9]+[kMGTPEZY]? closed$/)
}));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that closed is not needed here, since the left side already says it's counting closed issues. Then we could omit -closed-raw as well.

Copy link
Contributor Author

@dagwieers dagwieers Sep 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rights, I think this was done because it's closer to what we do for open. Otherwise there's no difference anymore between closed-raw and closed. It's not simple to omit something, except maybe from the listing, but people can still do it.

Up to you to decide. I'll do whatever makes it upstream ;-) My interest in displaying closed issues or PRs is non-existing.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

almost my entire interest here is in closed issues (though i do not understand or care about the -raw) distinction

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha. Ok, I'll do what you suggested.

.expectJSONTypes(Joi.object().keys({
name: Joi.equal('pull requests'),
value: Joi.string().regex(/^[0-9]+[kMGTPEZY]? open$/)
}));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this just be /pull-requests instead of /issues-pr?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, we need to support /issues-pr for backward compatibility. What do you think about supporting both?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, so I only simplified the implementation and made the numbers exact (rather than saying 30+ for everything larger than 30). And that's what we needed. The simplification was simple a result of the fact that it was needed for getting proper numbers.

@dagwieers
Copy link
Contributor Author

Am I correct that /github/issues now returns only issues, and not issues + PRs?

That is exactly as it was before AFAIK. You either have issues or PRs (and I don't know what the name is for both).

@dagwieers
Copy link
Contributor Author

Done !

server.js Outdated Show resolved Hide resolved
@dagwieers dagwieers force-pushed the github-fullsupport branch 3 times, most recently from 7c336ca to 57f88f7 Compare September 24, 2017 19:46
@dagwieers
Copy link
Contributor Author

dagwieers commented Sep 24, 2017

Latest result:
image

@dagwieers
Copy link
Contributor Author

dagwieers commented Sep 24, 2017

Ready to be merged ! (And then I can update our community wiki pages to get real numbers !)

This PR includes:
- Getting rid of the option that includes 2x closed
- Using -closed-raw is no longer useful
@espadrine
Copy link
Member

Merged and live.

@espadrine espadrine closed this Sep 24, 2017
@dagwieers
Copy link
Contributor Author

@espadrine Thanks ! I was making some more small changes to the examples, but I'll add them to another PR. Nothing important.

@StoneCypher
Copy link

Working in production. This used to say issues 30+ closed 😀

screen shot 2017-09-24 at 2 37 36 pm

@paulmelnikow
Copy link
Member

@dagwieers It's really cool to see this in use!

https://github.com/ansible/community/wiki/Ambassadors

@AraHaan
Copy link

AraHaan commented Feb 11, 2021

@espadrine what about a badge for merged PR's only too?

@calebcartwright
Copy link
Member

@AraHaan - thank you for looking back through the history to find things relevant to your inquiry, but a pull request that was closed more than 3 years isn't the best place for a new feature request. Please open a new issue if you'd like a new badge/new variant of a badge to increase the odds of someone potentially implementing it!

@AraHaan
Copy link

AraHaan commented Feb 12, 2021

ok opened #6164

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should GitHub issue badge including pull requests?
7 participants