#434 Contributing to a pagure repository
Closed: pushed 3 months ago by jflory7. Opened 3 years ago by robyduck.

Badge description (like "You added a co-maintainer to a package. BFF!"):
"Long life to pagure"

This badge, which can be a series, should be awarded for committing to a pagure repository. We are incouraging people to switch from fedorahosted to pagure and we could give them some badges for it.

Badges could be awarded with the same concept as for pushing to a Fedora package repository, for 1-10-50-250-500-1000 commits.

I will think about an artwork concept too, but the design could contain a panda badger with a sweet pagure under his arm, for example.


It's an attempt, if we want to do a series we should probably think about something else. Maybe a panda in a boat, and at the end the boat is full of pagures :D
[[Image(pagure-1.png)]]

It's an attempt, if we want to do a series we should probably think about something else. Maybe a panda in a boat, and at the end the boat is full of pagures :D
[[Image(pagure-1.png)]]

Random idea: Have the panda's face peeking out from the hermit crab shell?

Random idea: Have the panda's face peeking out from the hermit crab shell?

Nice idea. Something like this?
[[Image(pagure-1b.png)]]

Nice idea. Something like this?
[[Image(pagure-1b.png)]]

I made a series for pagure commits. Thoughts?
[[Image(1.png)]]
[[Image(10.png)]]
[[Image(50.png)]]
[[Image(150.png)]]
[[Image(500.png)]]
[[Image(1000.png)]]

I made a series for pagure commits. Thoughts?
[[Image(1.png)]]
[[Image(10.png)]]
[[Image(50.png)]]
[[Image(150.png)]]
[[Image(500.png)]]
[[Image(1000.png)]]

Uploading the yml file for the first badge, just to adapt for the others I think. Needs a review!

Uploading the yml file for the first badge, just to adapt for the others I think. Needs a review!

Marking ticket as triaged, concept looks good to me! CCing Design Team members for artwork review / feedback.

Marking ticket as triaged, concept looks good to me! CCing Design Team members for artwork review / feedback.

Hey! Fun badges! I think commit badges should have pink background (see style guide).
These look great to me, awesome job, robyduck!

*why is 10 a python? ;)

Hey! Fun badges! I think commit badges should have pink background (see style guide).
These look great to me, awesome job, robyduck!

*why is 10 a python? ;)

I chose the same background as for packaging commit badges. Should I change them all?

And I decided to make appear also a nice python because Pagure is written with Flask -> Python, that's the main reason. The other is...it looks so nice to have the pagure on the back of our little python :D

I chose the same background as for packaging commit badges. Should I change them all?

And I decided to make appear also a nice python because Pagure is written with Flask -> Python, that's the main reason. The other is...it looks so nice to have the pagure on the back of our little python :D

I like the python, yeah =)
What, this one? Let's change just one for starters and see how it looks, but we really do want to be consistent.
[[Image(https://badges.fedoraproject.org/pngs/you-can-call-me-patches-01.png)]]

Replying to [comment:10 robyduck]:

I chose the same background as for packaging commit badges. Should I change them all?

And I decided to make appear also a nice python because Pagure is written with Flask -> Python, that's the main reason. The other is...it looks so nice to have the pagure on the back of our little python :D

I like the python, yeah =)
What, this one? Let's change just one for starters and see how it looks, but we really do want to be consistent.
[[Image(https://badges.fedoraproject.org/pngs/you-can-call-me-patches-01.png)]]

Replying to [comment:10 robyduck]:

I chose the same background as for packaging commit badges. Should I change them all?

And I decided to make appear also a nice python because Pagure is written with Flask -> Python, that's the main reason. The other is...it looks so nice to have the pagure on the back of our little python :D

Personally I like it less, and we need to make the pagure with a white line inside (need help). Here is the pink one.
[[Image(1_pink.png)]]

Personally I like it less, and we need to make the pagure with a white line inside (need help). Here is the pink one.
[[Image(1_pink.png)]]

I agree with Maria that we should be consistent with the backgrounds, otherwise these badges look great. Eg for the background spec it's on this page of the badge styleguide:

https://fedorahosted.org/fedora-badges/attachment/wiki/DesignResources/styleguide_3.c.png

I can help with the pagure transparency, one sec and I'll upload a version that won't do that.

I agree with Maria that we should be consistent with the backgrounds, otherwise these badges look great. Eg for the background spec it's on this page of the badge styleguide:

https://fedorahosted.org/fedora-badges/attachment/wiki/DesignResources/styleguide_3.c.png

I can help with the pagure transparency, one sec and I'll upload a version that won't do that.

version of the pagure shell that's filled
1_pink-filledshell.svg

version of the pagure shell that's filled
1_pink-filledshell.svg

Thanks mizmo, nice solution. Here are the updated badges:
[[Image(1_pink-filledshell.png)]]
[[Image(10_pink-filledshell.png)]]
[[Image(50_pink-filledshell.png)]]
[[Image(150_pink-filledshell.png)]]
[[Image(500_pink-filledshell.png)]]
[[Image(1000_pink-filledshell.png)]]

Thanks mizmo, nice solution. Here are the updated badges:
[[Image(1_pink-filledshell.png)]]
[[Image(10_pink-filledshell.png)]]
[[Image(50_pink-filledshell.png)]]
[[Image(150_pink-filledshell.png)]]
[[Image(500_pink-filledshell.png)]]
[[Image(1000_pink-filledshell.png)]]

Robyduck: perfecto! Setting artwork_approved.

Robyduck: perfecto! Setting artwork_approved.

Seems like this badge just needs to evaluated by a sysadmin-badges member to ensure the YAML file is all set. Artwork is a go. Anyone think they can review this ticket?

Seems like this badge just needs to evaluated by a sysadmin-badges member to ensure the YAML file is all set. Artwork is a go. Anyone think they can review this ticket?

Hi guys - First time reviewing a badge, so if I am outrageously wrong, nb or ralph can correct me.

  • I think we need a recipient line in the .yml file
  • Created separate yml files for each level
  • Each separate yml file would need an updated description and image url

If any of that is what I need to do, I will happily follow up.

Hi guys - First time reviewing a badge, so if I am outrageously wrong, nb or ralph can correct me.

  • I think we need a recipient line in the .yml file
  • Created separate yml files for each level
  • Each separate yml file would need an updated description and image url

If any of that is what I need to do, I will happily follow up.

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-01.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-01.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-10.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-10.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-50.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-50.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-150.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-150.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-500.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-500.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-1000.stl

Long Life to Pagure STL file (for 3D printing)
pagure-long-life-1000.stl

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-01.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-01.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-10.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-10.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-50.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-50.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-150.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-150.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-500.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-500.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-1000.yml

Long Life to Pagure updated YAML file (should be correct for prod)
pagure-long-life-1000.yml

To make life easier, a git patch that automatically puts all of the above files exactly where they should go
0001-Add-Long-Life-to-Pagure-series-PNG-YML-SVG-STL.patch

To make life easier, a git patch that automatically puts all of the above files exactly where they should go
0001-Add-Long-Life-to-Pagure-series-PNG-YML-SVG-STL.patch

Thanks for reviewing this ticket, aikidouke! I went ahead and organized all of the PNGs and SVGs under a uniform naming scheme (pagure-long-life-*.*) for all files. I updated all of the YAML files to be correct and current for names, descriptions, image file name locations, and commit counts. I also generated STLs for all of the Pagure badges, which will let us print these with 3D printers, given the chance. :)

For simplicity, you can merge this [https://fedorahosted.org/fedora-badges/attachment/ticket/434/0001-Add-Long-Life-to-Pagure-series-PNG-YML-SVG-STL.patch patch] in, which will move all of the files for this badge in.

Let me know if anything else is needed, thanks!

Thanks for reviewing this ticket, aikidouke! I went ahead and organized all of the PNGs and SVGs under a uniform naming scheme (pagure-long-life-*.*) for all files. I updated all of the YAML files to be correct and current for names, descriptions, image file name locations, and commit counts. I also generated STLs for all of the Pagure badges, which will let us print these with 3D printers, given the chance. :)

For simplicity, you can merge this [https://fedorahosted.org/fedora-badges/attachment/ticket/434/0001-Add-Long-Life-to-Pagure-series-PNG-YML-SVG-STL.patch patch] in, which will move all of the files for this badge in.

Let me know if anything else is needed, thanks!

An archive of all of the files with the naming scheme (all PNGs, SVGs, STLs, and YAMLs inside)
pagure-long-life-series.tar.gz

An archive of all of the files with the naming scheme (all PNGs, SVGs, STLs, and YAMLs inside)
pagure-long-life-series.tar.gz

I have pushed the badges and rules to production. Can someone clarify the badge names for me?

Should they be;

"Long Life to Pagure (Pagure I)"

OR

"Pagure I"

and so on for each in the series?

Thanks!

I have pushed the badges and rules to production. Can someone clarify the badge names for me?

Should they be;

"Long Life to Pagure (Pagure I)"

OR

"Pagure I"

and so on for each in the series?

Thanks!

I think the name for the badges should be as they are pushed already, "Long Life to Pagure (Pagure I)". This is how other series badges are formatted so I believe this is the best way to name them.

I noticed that these badges are missing tags, so they're showing up as uncategorized. They should probably receive two: "development" and "pagure". This should sort them all correctly in Tahrir.

I think the name for the badges should be as they are pushed already, "Long Life to Pagure (Pagure I)". This is how other series badges are formatted so I believe this is the best way to name them.

I noticed that these badges are missing tags, so they're showing up as uncategorized. They should probably receive two: "development" and "pagure". This should sort them all correctly in Tahrir.

Hello - Badges have been pushed and tagged with development, pagure. I have not had a chance to test yet.

Hello - Badges have been pushed and tagged with development, pagure. I have not had a chance to test yet.

I've just pushed some commits and nothing. The porblem seems to be, that no fedmsgs are emitted

I've just pushed some commits and nothing. The porblem seems to be, that no fedmsgs are emitted

fedmsg are emitted. Looks like wrong yml file. It's throwing a KeyError: 'msg.commit.username'

fedmsg are emitted. Looks like wrong yml file. It's throwing a KeyError: 'msg.commit.username'

Yeah, I think pagure doesn't emit the username, the yml needs to catch the mail address for now. Not sure if pingou is planning to add the username in fedmsg in the next releases, but for now I guess the only way is through the email.

There is just one problem, pagure permits to register with several mail addresses, so if you want match the address with the nick, and use the one in FAS, people who used another address on pagure won't get the badge.

Yeah, I think pagure doesn't emit the username, the yml needs to catch the mail address for now. Not sure if pingou is planning to add the username in fedmsg in the next releases, but for now I guess the only way is through the email.

There is just one problem, pagure permits to register with several mail addresses, so if you want match the address with the nick, and use the one in FAS, people who used another address on pagure won't get the badge.

So, here's the thing:

1) my issue of no fedmsg was solved by opt-in in repo settings

2) the username of the committer (or I guess pusher) is in in msg.user.name

3) count of the commits is in msg.total_commits (and that somehow needs to be accumulated if we count commits and not pushes)

See example message here https://apps.fedoraproject.org/datagrepper/id?id=2016-10c66966-ee17-4511-9297-7b43c95c6d6d&is_raw=true&size=extra-large

So, here's the thing:

1) my issue of no fedmsg was solved by opt-in in repo settings

2) the username of the committer (or I guess pusher) is in in msg.user.name

3) count of the commits is in msg.total_commits (and that somehow needs to be accumulated if we count commits and not pushes)

See example message here https://apps.fedoraproject.org/datagrepper/id?id=2016-10c66966-ee17-4511-9297-7b43c95c6d6d&is_raw=true&size=extra-large

Yes, this has been pushed. But the rules are not proper therefore the badges are not awarded to anyone. IMO the ticket should be open till the correct rules are not pushed.

Yes, this has been pushed. But the rules are not proper therefore the badges are not awarded to anyone. IMO the ticket should be open till the correct rules are not pushed.

The message format from Pagure has changed in the past I believe. I have attached a patch that may fix the problem and only works with the current format.

There are three places in the message with some name:
* {{{msg.agent}}} is the person who pushed the commits
* {{{msg.repo.user.name}}} is owner of the repo that was pushed to
* {{{msg.authors[].name}}} is a list of people who wrote the pushed commits

My patch is using the first of these, as there there is no way to map individual authors to commits they wrote. It will also accumulate the number in msg.total_commits.

The big question is if this is the right approach: if the project is using pull requests from individual forks, people will have to enable the fedmsg hook for their forks (because merging via web interface does not send this kind of message). If they do, they may get badges for pushes that never make it into the main repo.

The message format from Pagure has changed in the past I believe. I have attached a patch that may fix the problem and only works with the current format.

There are three places in the message with some name:
* {{{msg.agent}}} is the person who pushed the commits
* {{{msg.repo.user.name}}} is owner of the repo that was pushed to
* {{{msg.authors[].name}}} is a list of people who wrote the pushed commits

My patch is using the first of these, as there there is no way to map individual authors to commits they wrote. It will also accumulate the number in msg.total_commits.

The big question is if this is the right approach: if the project is using pull requests from individual forks, people will have to enable the fedmsg hook for their forks (because merging via web interface does not send this kind of message). If they do, they may get badges for pushes that never make it into the main repo.

I'm CCing some other stakeholders in Badges / Fedora Infra for comments and thoughts on the above rules file. If this is the way we want to go, I'd be happy to push this out (assuming there's no special steps required for adding / updating a rule for a pre-existing badge).

Also raising the priority to major since this is a badge we have pushed, but is not current working.

I'm CCing some other stakeholders in Badges / Fedora Infra for comments and thoughts on the above rules file. If this is the way we want to go, I'd be happy to push this out (assuming there's no special steps required for adding / updating a rule for a pre-existing badge).

Also raising the priority to major since this is a badge we have pushed, but is not current working.

As far my discussion with pingou, the plan was to adjust the fedmsg-hook itself to include the number of commits person.

As far my discussion with pingou, the plan was to adjust the fedmsg-hook itself to include the number of commits person.

Replying to [comment:32 lsedlar]:

The message format from Pagure has changed in the past I believe. I have attached a patch that may fix the problem and only works with the current format.

There are three places in the message with some name:
* {{{msg.agent}}} is the person who pushed the commits
* {{{msg.repo.user.name}}} is owner of the repo that was pushed to
* {{{msg.authors[].name}}} is a list of people who wrote the pushed commits

My patch is using the first of these, as there there is no way to map individual authors to commits they wrote. It will also accumulate the number in msg.total_commits.

Yes, the older format of the Pagure fedmsg message included the number of commits per author. If the {{{msg.agent}}} is given the given the badge then it will only be the admins who will get the badge. So, I think its worth waiting for the hook or if the hook takes time then we just push this patch for now. Thoughts?

Replying to [comment:32 lsedlar]:

The message format from Pagure has changed in the past I believe. I have attached a patch that may fix the problem and only works with the current format.

There are three places in the message with some name:
* {{{msg.agent}}} is the person who pushed the commits
* {{{msg.repo.user.name}}} is owner of the repo that was pushed to
* {{{msg.authors[].name}}} is a list of people who wrote the pushed commits

My patch is using the first of these, as there there is no way to map individual authors to commits they wrote. It will also accumulate the number in msg.total_commits.

Yes, the older format of the Pagure fedmsg message included the number of commits per author. If the {{{msg.agent}}} is given the given the badge then it will only be the admins who will get the badge. So, I think its worth waiting for the hook or if the hook takes time then we just push this patch for now. Thoughts?

Metadata Update from @robyduck:
- Issue assigned to robyduck

2 years ago

Metadata Update from @riecatnor:
- Custom field artwork adjusted to None
- Custom field concept_review_passed adjusted to None (was: 1)
- Custom field has_complete_yaml reset (from Full, needs review)
- Custom field has_description adjusted to on (was: 1)
- Custom field has_name adjusted to on (was: 1)
- Custom field needs_manual_award reset (from 0)
- Custom field triaged adjusted to on (was: 1)
- Issue close_status updated to: None
- Issue tagged with: artwork-approved, bug, development

2 years ago

Metadata Update from @riecatnor:
- Custom field artwork adjusted to approved (was: None)
- Custom field has_complete_yaml reset (from false)
- Custom field needs_manual_award reset (from false)

2 years ago

Metadata Update from @sayanchowdhury:
- Custom field has_complete_yaml reset (from false)
- Custom field needs_manual_award reset (from false)

2 years ago

@sayanchowdhury said…
I have attached a patch that may fix the problem and only works with the current format.

Sayan, do you still have this patch or was it applied to the Infrastructure repo yet? It would be good to fix this one if we can. :grinning:

Metadata Update from @jflory7:
- Custom field has_complete_yaml reset (from false)
- Custom field needs_manual_award reset (from false)

2 years ago

Metadata Update from @jflory7:
- Custom field concept_review_passed adjusted to passed (was: None)
- Custom field external_requirements adjusted to on
- Custom field has_complete_yaml reset (from false)
- Custom field needs_manual_award reset (from false)

2 years ago

"No one has earned this badge yet."

I think there are a few people that have earned it ;)
Something broken in infra? @ralph ?

Not only "No one has earned" but also it is not assigning the new ones.
For sure I did some commits to pagure.

@ttorling @szydell Pushing this badge was a mistake – it's currently broken and it's not an easy fix to get it working. It will likely need some figuring out when @sayanchowdhury and @pingou have a chance to catch up. For now, this ticket and badge are blocked. :confused:

Metadata Update from @jflory7:
- Custom field has_complete_yaml reset (from false)
- Custom field needs_manual_award reset (from false)

5 months ago

@jibecfed We owe a huge thanks to @cverna for getting this badge working after almost three years. :tada: I am going to close this ticket as pushed since the badge works as intended now.

cverna++

Metadata Update from @jflory7:
- Custom field has_complete_yaml reset (from false)
- Custom field needs_manual_award reset (from false)
- Issue close_status updated to: pushed
- Issue status updated to: Closed (was: Open)

3 months ago

OK, great :) Thank you Clément!
But where should I create my issue?

I have only one event from last year in datagrepper:
https://apps.fedoraproject.org/datagrepper/raw?topic=io.pagure.prod.pagure.git.receive&user=jibecfed

While I had some commits even yesterday:
Screenshot_2019-04-09_jibecfed_-_overview_-_Pagure_io.png

Is there some special requirements for these events to get into datagreper?

Metadata Update from @churchyard:
- Custom field has_complete_yaml reset (from false)
- Custom field needs_manual_award reset (from false)

3 months ago

it indeed works, thank you (too bad it's not retroactive :p)

Login to comment on this ticket.

Metadata
Attachments 31
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment
Attached 3 years ago View Comment