Provide badge endpoint

[kwin]

The recommendation from https://github.com/jvm-repo-rebuild/reproducible-central#what-can-i-do regarding reproducible build badge requires manual adjustment for each release. It would be nice to have an endpoint which serves the right badge (ok/not ok) depending on the given Maven coordinates only. Also it would be nice to be able to check against the most recent version optionally so the the version can be left out from the request path/parameters. That way a read me with that badge doesn’t require modification after each release.

[hboutemy]

I perfectly see your need given the number of Sling artifacts. I'd love of that. IMHO, it will require a seriously more advanced server-side solution than the basic static generated (from shell script) site. Or do you have an idea on how to make such badge in a static site?

[hboutemy]

notice that for project-oriented global view, I created some project-oriented rebuild https://github.com/jvm-repo-rebuild/reproducible-maven-HEAD this could help you

[hboutemy]

thinking at it, perhaps we can generate a static HTML site using GH pages (= gh-pages orphan branch in this repository) that mimics Maven Central directories with pre-gav content... seems feasible by adding more code in https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/update-reproducibility-summary.sh to not olny update README.md but also that new gh-pages branch

[hboutemy]

notice that while working on #80 (which is a must, because it breaks the site), it's probably an opportunity to add what you're looking for

[kwin]

Using https://shields.io/endpoint is maybe an option. Then only the static JSON would need to be delivered through GH Pages. Another alternative is to request official support via https://github.com/badges/shields/issues/new?labels=service-badge&template=3_Badge_request.md or even raise a PR for that. The tutorial https://github.com/badges/shields/blob/master/doc/TUTORIAL.md has some hints how to implement such a dynamic badge.

[jskov]

@hboutemy would it be make sense to extend the maven-metadata.xml for each build with a field with a boolean flag with state of the latest release (reproducible or not)?

Then (by my reading), it should be possible to make a badge reflect reality via https://shields.io/badges/dynamic-xml-badge.

The current badge is just statically looks like everything is OK (so I missed a problem with Gradle module files in some of my projects).

I'd be happy to give it a go, if you are interested.

[jskov]

Ah, commented on a wrong issue; the XML badge can only extract text. Not very interesting.

But it seems that it is possible to provide endpoint information directly from the repository. Examples:

https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2Fjskov%2Freproducible-central%2Fbadge%2Fcontent%2Fdk%2Fmada%2Fstyle%2Fmada-style-gradle%2Fbadge-error2.json

https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2Fjskov%2Freproducible-central%2Fbadge%2Fcontent%2Fdk%2Fmada%2Fstyle%2Fmada-style-gradle%2Fbadge-ok2.json

I am not sure what the minimal caching time is (but it is larger than my patience, hence the commits with renaming).

So I guess it is just a question of generating an extra file next to maven-metadata.xml in each content folder.