#6572 Feature Request: Github Bages
Opened 3 years ago by aviso. Modified 3 months ago

As discussed in this thread, it would be nice to have dynamic Fedora and EPEL badges for GitHub and other sites, such as PyPI. This will make it easier for an end uses to identify that a given project is available in Fedora or EPEL. This may require a lightweight service, or possibly a pull request to shields.io to support dynamic parsing of stable package info from the pdc.


Will the last suggestion in that thread not work?

https://img.shields.io/badge/dynamic/json.svg?uri=https%3A%2F%2Fapps.fedoraproject.org%2Fmdapi%2Ff27%2Fpkg%2Fpython3-enlighten&query=%24.version&label=Fedora+27

I suppose we would need to document things somewhere so github projects know whats available.

No, the whole point is we have to use half solutions like that because nothing better exists. For example, with that one, while it determines the package dynamically, you still have to update badge for the latest version of Fedora. Almost all web services that support badges have a latest option and have some sort of shorthand so the badges are easier to implement.

You may also want a badge like the ones I first mentioned in the thread which describe which releases a project has packages for rather than the versions available.

If we make badges flexible and easy to implement it gives maintainers a good way to point people to Fedora and EPEL and it serves as a reminder to keep packages updated.

Metadata Update from @kevin:
- Issue priority set to: Waiting on Asignee

2 years ago

Metadata Update from @kevin:
- Issue tagged with: backlog

a year ago

Metadata Update from @cverna:
- Issue untagged with: backlog

a year ago

Metadata Update from @cverna:
- Issue tagged with: help wanted

a year ago

I think this may be a good idea for a small application one could write and run in communishift (when it comes back).

At this point I do not think that this is something we want to do and maintain ourselves.

Therefore, as much as I think the idea is interesting, I would propose that we close this ticket.

I'm not sure closing it makes sense it's something we want to do.

I've also noticed Fedora badges are available in Sheilds.io now, but they are not very robust and are still static, requiring both the branch name and the name of the package within that repo (ex: python36-enlighten). I think a pull request to improve the badges there would be a good start, and once we're happy with them we could point people there via documentation.

I can help with that, but I'm not sure which API to use. The current one uses mdapi. For the badges on my projects, I'm using PDC to list branches for the ones I use. Maybe Bodhi's api is the one to use?

I think we'd want a few forms:

Fedora: {Version in latest fedora release}
EPEL: {Version in latest EPEL release}
Fedora: {Fedora versions that have the package}
EPEL: {EPEL versions that have the package}
Any others?

What API calls are needed to determine this information?

I am most happy to help you figure out how to build this but I still don't think this is something the Fedora Infrastructure team wants to development and maintain.

As for the answer to your question, it'll be a mixed of apps:
- mdapi will give you the version in a specific release (be that Fedora or EPEL)
- PDC will give you the list of active releases for a package
- Bodhi will return you everything unless you restrict to what you wish to know and that will require knowledge that is present in PDC.

I'm not seeing the autogenerating api docs for bodhi like the others have, but perhaps I'm not looking in the right place. Where can I find examples of getting JSON back from Bodhi REST queries?

It uses the Accept header to determine if it should return HTML or JSON, so if you hit bodhi with curl, you'll get JSON :)
After you just need to find the URL from the UI and query it.

For example:

curl "https://bodhi.fedoraproject.org/updates/?packages=guake" | python3 -m "json.tool"

Awesome, thanks!
What is the source of truth to determine the latest Fedora and EPEL versions? I assume there is some flag to indicate when they are released and not in a pre-release status.

As much as I hate myself for this, the best answer to this day may still be pkgdb2 (which has been retired, is no longer running but because some apps still rely on its API being there, we're still keeping up to date and serving: https://admin.fedoraproject.org/pkgdb/api/collections )

Beware that it will go away eventually, we dearly want it to go away, but so far it's still there.

Otherwise, you could poke at PDC for say: fedpkg which is present in all Fedora and EPEL versions and see which branches it has.

PDC was what I was thinking, but I wasn't sure how to tell that f32 is the latest stable branch vs f33.

@aviso do you need more information?

Are you ok with us closing this ticket?

I haven't had a chance to dig into it. Still a bit unsure about determining the latest release. I don't want to rely on something scheduled to go away.

Metadata Update from @smooge:
- Issue tagged with: dev, low-gain, low-trouble

3 months ago

Login to comment on this ticket.

Metadata
Boards 1
dev Status: Backlog