search

reanahub / reana-ui

REANA UI frontend
http://reana-ui.rtfd.io
MIT License
4 stars 33 forks source link

investigate flexible badge generation options #219

Closed tiborsimko closed 2 years ago

tiborsimko commented 2 years ago

For "Run on REANA" or "Launch on REANA" or "Execution on REANA" badges, we need to investigate the possible badge hosting solutions.

Two options:

See some existing examples:

Hosting locally has some pros (e.g. URL longevity, access rates, measuring usage) and cons (e.g. maintenance).

If going for an external service, check service conditions, FLOSS-iness, rate limits, etc.

tiborsimko commented 2 years ago

Also, think about flexible URL and label text options, such as "Run on REANA@CERN", "Run on REANA@BNL", etc.

mdonadoni commented 2 years ago

Both Binder and SWAN host the badge on their servers (Binder badge, SWAN badge). In addition to that, Binder also provides a custom badge builder that relies on the shields.io service.

I think hosting the badge locally is the best solution, as we don't have to rely on external third-party services. If we decide to provide a single static badge, it is as easy as serving a single image file that is publicly accessible on reana.io. This also makes it possible to easily update the badge, without the need for users to change anything in their repositories. However, we must make sure that the URL of the badge will stay the same in the future.

With regard to flexible URLs, as a MVP we can just provide a single generic badge that everybody can use (see the proposals below). This doesn't stop users from specifying a particular REANA cluster to which workflows should be submitted nor to generate a custom badge on their own.

In the future we might provide a way to generate custom badges such as "Run on REANA@BNL". This can be done either by relying on an external system, as in the case of Binder, or by self-hosting a badge generation service. Considering this second case, it is interesting to note that both shields.io and badgen.net are open-source: the former is licensed under the CC0 license, while the latter under the ISC license; shields.io also provides docker images.

What do you think?

Badge proposals It might be a good idea to use the same shade of red as the one in the REANA logo:

tiborsimko commented 2 years ago

Fully agreed WRT hosting and MVP. As for the badge proposals, I like the first two. We are kind of used to seeing "Run on REANA" phrasing as per the tentative project name, but "Launch on REANA" phrasing might be perhaps even more "engaging" for users to click on?! If I had to choose one, then taking into account the similarity with "workflow run" concept that we are advertising everywhere in the docs and on the web site, perhaps sticking to "Run on REANA" nomenclature is better anyway. Any other thoughts? @mvidalgarcia @audrium @VMois

VMois commented 2 years ago

For MVP (and even longer-term), I think hosing badges on our side is a good choice.

For customization, in the future, we can also allow for custom badges like "Run on REANA@ABC" to be configured per REANA instance. For MVP, I think starting with a general "Run on REANA" badge should be enough.

I prefer "Run" over "Launch" for the same reasons that @tiborsimko described.

audrium commented 2 years ago

First option looks nice to me as well! And I agree that for MVP it's the solution to go. @mdonadoni but is it also possible to us use these third party services easily without self-hosting it? It was not very clear from your post (just curious to know)

mdonadoni commented 2 years ago

First option looks nice to me as well! And I agree that for MVP it's the solution to go. @mdonadoni but is it also possible to us use these third party services easily without self-hosting it? It was not very clear from your post (just curious to know)

Yes, it is possible to easily use them without self-hosting. Both shields.io and badgen.net provide endpoints to dynamically generate badges (e.g. https://img.shields.io/badge/Run%20on-REANA-ff3336 generates the "Run on REANA" badge)