Self-hosted shield.io instance

[lemeurherve]

Related to "Consider removing embeddable-build-status plugin" and since ci.jenkins.io is blocking access to ../api/json path for security reason, I'm proposing to self-host a shield.io instance instead of putting in place a token to authorize shield.io access to these urls.

The token solution would need a patch on shield.io server codebase to add this token for ci.jenkins.io requests, but since there aren't that much uses I don't think it worth it for them.

The self-hosted instance wouldn't need a token as we could whitelist it on ci.jenkins.io

WDYT?

[dduportal]

Excellent idea!

Proposal: if we host the "shields.jenkins.io" (I'll refer to it with this name for clarity but it can be chaneged of course!) service on the same VM as ci.jenkins.io, we would not even need any token:

• The Apache server exposing ci.jenkins.io would be updated with a new virtual host for "shields.jenkins.io"
• The backend for "shields.jenkins.io" can either be a docker container or a "Linux-raw service". In both cases, it can directly access the /api/json path on the Jenkins container (e.g. on http://localhost:8080/api/json) so no blocking from the Apache server.

I guess we have to evaluate the requirements for this services:

• Expected minimal resources (CPU/memory) to evaluate if it fit on this VM
• Deployment method of the service

[lemeurherve]

Additional doc on self-hosting shield.io: https://github.com/badges/shields/blob/master/doc/releases.md#shields-server

[lemeurherve]

As I didn't managed to join shield.io discord server, I've opened a discussion to ask about requirements.

[lemeurherve]

As @MarkEWaite and @darinpope adopted the plugin, it doesn't have to be removed from ci.jenkins.io. No need for a self-hosted shield.io instance, closing this issue.