Automatically grab bomVersion instead of having them in the config file

[geoand]

I believe that we the BOM versions we provide should as options should be automatically retrieved (from Maven Central most likely).
We could grab the latest X versions and show them.

WDYT @cmoulliard @lincolnthree ?

[geoand]

Just a note, the above suggestion would remove the need to update the project every time a BOM is released - we would of course also need a mechanism of reloading the versions every Y amount of time

[lincolnthree]

So, I was actually doing this previously from the UI, but since the SB version is linked to snowdrop version and some magic happens in the generator to correlate them, I deferred to the data provided via the config. I think it's a good idea, but we'd need to figure out how to map versions programatically.

[geoand]

Good to know @lincolnthree !

If we think this is a good approach, I could work on implementing it

[cmoulliard]

Just a note, the above suggestion would remove the need to update the project every time a BOM is released -

This is an excellent idea. WDYS @geoand ? That we calculate live the list of the bom to be displayed within the UI OR that we update when the HTTP server starts the list within the config's file ?

[geoand]

We would most likely have to do in go code, but should be pretty simple

[cmoulliard]

As new versions could arrive when the HTTP runs, then we need a cron job able to update the config's file consumed by the UI

[geoand]

Yeah exactly.
I don't think it will be too hard to implement

[cmoulliard]

The ideal scenario would be. When a new snowdrop bom version comes, then the configmap is updated and that triggers the process to restart the HTTP Server's pod

[geoand]

We could always just create a CronJob Kubernetes resource on the cluster as part of the installation and also have Go code poll that for changes.
It' sounds doable

[metacosm]

We could implement a Github webhook? Then again, we should support productized version as well, I think… Not sure how to support that use case properly, though…

[geoand]

We can support the productized version by utilizing the redhat tags of one of boosters.

I am thinking that this might be a good way for Aurea to start learning about the various things we have. WDYT @cmoulliard @metacosm ?