Spring boot config map booster not working

[piyush-garg]

As mentioned in the file https://raw.githubusercontent.com/fabric8-launcher/launcher-booster-catalog/master/spring-boot/current-redhat/configmap/booster.yaml

If you clone the git repo mentioned in url and checkout to ref mentioned in ref, after that if you hit mvn clean install it's breaking.

Logs are

$ mvn clean install
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Non-resolvable import POM: Failure to find me.snowdrop:spring-boot-bom:pom:1.5.12.Final-redhat-1 in https://repository.jboss.org/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of redhat-public has elapsed or updates are forced @ io.openshift.booster:spring-boot-booster-parent:1.5.12-3-rhoar, /home/pgarg/.m2/repository/io/openshift/booster/spring-boot-booster-parent/1.5.12-3-rhoar/spring-boot-booster-parent-1.5.12-3-rhoar.pom, line 100, column 19
[ERROR] 'dependencies.dependency.version' for org.assertj:assertj-core:jar is missing. @ io.openshift.booster:spring-boot-booster-parent:1.5.12-3-rhoar, /home/pgarg/.m2/repository/io/openshift/booster/spring-boot-booster-parent/1.5.12-3-rhoar/spring-boot-booster-parent-1.5.12-3-rhoar.pom, line 138, column 17
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project io.openshift.booster:spring-boot-configmap-parent:1.5.12-2-redhat (/home/pgarg/testbooster/spring-boot-configmap-booster/pom.xml) has 2 errors
[ERROR]     Non-resolvable import POM: Failure to find me.snowdrop:spring-boot-bom:pom:1.5.12.Final-redhat-1 in https://repository.jboss.org/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of redhat-public has elapsed or updates are forced @ io.openshift.booster:spring-boot-booster-parent:1.5.12-3-rhoar, /home/pgarg/.m2/repository/io/openshift/booster/spring-boot-booster-parent/1.5.12-3-rhoar/spring-boot-booster-parent-1.5.12-3-rhoar.pom, line 100, column 19 -> [Help 2]
[ERROR]     'dependencies.dependency.version' for org.assertj:assertj-core:jar is missing. @ io.openshift.booster:spring-boot-booster-parent:1.5.12-3-rhoar, /home/pgarg/.m2/repository/io/openshift/booster/spring-boot-booster-parent/1.5.12-3-rhoar/spring-boot-booster-parent-1.5.12-3-rhoar.pom, line 138, column 17
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

Basically its not able to find the dependency me.snowdrop:spring-boot-bom:pom:1.5.12.Final-redhat-1 which is mentioned in spring-boot-booster-parent/1.5.12-3-rhoar pom.xml which is used in the boosters.

I checked the repo https://github.com/snowdrop/spring-boot-bom/releases and there is no tag with release. Due to this project is not getting build and regression test on FMP are broken.

We have observed this in spring boot rest http and spring boot crud also.

[gastaldi]

@piyush1594 this is not the correct repository to open such issues. Please use https://github.com/snowdrop/spring-boot-configmap-booster/issues instead

[piyush-garg]

Hey @gastaldi

Thanks for this, I have created an issue there. But what I know is - the version mentioned in booster.yaml is used in osio. If that is the case, is not affecting this on OSIO ?

Thanks

[Ladicek]

I know this is not the right place, but I'm gonna say it here anyway. @piyush1594 I think your usage of the RHOAR boosters makes too many assumptions that simply aren't always true:

• If there's a booster pointing to a Red Hat version of Spring Boot BOM, that Spring Boot BOM is available in Red Hat Maven Repository. That's not true, because if new release is being prepared, the Spring Boot BOM is only available in an internal Maven repository.
• If there's a tagged booster pointing to a Red Hat version of Spring Boot BOM, that Spring Boot BOM is available in Red Hat Maven Repository. That's not true, because even if the booster has been finalized, the entire release might not have finished yet.
• If the master branch of the booster catalog points to a booster tag, then everything that's required for the booster to work is available publicly. I'd personally argue that this should be true, but that requires discipline on the boosters maintainer side, and that discipline simply isn't there :-/

The only thing you should be able to rely on is tagged versions of the booster catalog.

[piyush-garg]

Hey @Ladicek

What information I received previously is - the version mentioned in booster.yml is the version of the booster which is used in osio and right now rhoar version is getting used. That's why we are always parsing the redhat/booster-name/booster.yml and always using the version mentioned there in FMP regression tests because the FMP is heavily getting used there and we should get the info if something breaks before merging a PR.

And I agree with the third fact you mentioned, if a version of booster reflected here should work whether it is OSIO or locally in any system or anywhere else. Previously FMP regression tests were working fine and we observed this from last 2-3 days because may be a different version of booster specified here.

With assuming your fact 3, I pointed the issue here because it seems to be like an issue with current version mentioned in booster.yaml and this may be affecting OSIO also I don't know. And if this the case, this version should not be reflected here. That's the reason for creating the issue here.

Hope it helps and agree with your fact 3.

And we want to rely on the version which is used in OSIO if you can point to same.

Thanks

[Ladicek]

@gastaldi Could you clarify if the master branch of the booster catalog should always be in a usable state? (Specifically: if the master branch refers to boosters that depend on as-yet-unreleased runtimes, is that OK from the perspective of booster catalog users?)

[gastaldi]

@Ladicek yes, the master branch should always be in a usable state and ready to be tagged anytime. Mind that each booster.yaml has a staging and a production environment tag, that should always point to a tagged version:

• https://launcher.prod-preview.openshift.io and https://prod-preview.openshift.io use what's in staging:
• https://developers.redhat.com/launch and https://openshift.io use what's in production:

Ideally the booster-catalog should ONLY be updated when they are usable (artifacts are available and buildable), otherwise the developer should run Launcher pointing to its own forked booster-catalog and provide a PR to the official repository when done.

[Ladicek]

OK, so the Spring Boot guys screwed up here. And the rest of us reviewers :-)

[piyush-garg]

Hey @gastaldi Can you provide one more info, always master of catalogue is used in osio or something else, can you point me to that in case of the second ?

[gastaldi]

@piyush1594 note that the booster-catalog has a single master branch and tags. The master branch is used in the staging environment (prod-preview) and the latest tagged version is used in production. The idea is that the master branch should be always ready to be tagged and used by the production instance anytime.

[metacosm]

I guess I keep running into that issue and I never learn… 😭
@gastaldi If I want to record what the next version of launcher should look like when all the artifacts for a new runtime versions become available, what exactly should I be doing? Perhaps, this information should be added to the README since I don't see anything pertaining to staging and/or production there. Also, to my defence, I did attempt to run validate.sh on my local copy before creating the PR but to no avail. Is there a document explaining the catalog update process?

[Ladicek]

We used to have a description of the branching strategy in the README, but that was lost in the Grand Refactoring. Apparently, some parts of it would still be useful.

[gastaldi]

@metacosm I added some infromation in the README about the environment tag: https://github.com/fabric8-launcher/launcher-booster-catalog/blob/master/README.md#booster-descriptor

About validate.sh, it is only used right now to validate PRs, but the original intention was to run against the local copy. @quintesse is aware of that. I created #199 to allow validate.sh to be used locally, but feel free to use the PR validation process to check if your booster configuration is okay in the catalog.

[metacosm]

@gastaldi Thanks, that information helps however that still doesn't tell me precisely what the appropriate process is… Should I open a PR with DO NOT MERGE in the title? Only set the staging environment but then I would need to open yet another PR to update to prod? Since I'm also trying to automate that part of our release process, I'd like to know what's the best way to do update launcher catalog without causing issues and ideally as soon as I know a release is ready on our side without having to go back to it days later when the artifacts actually become available…

[gastaldi]

Ideally each runtime owner should be responsible of merging their own PRs, since they know best when that is ready (I have already given push permissions to each runtime team - if you can't merge your PRs, let me know).

[metacosm]

I do have merging permissions but with the often changing structure of the catalog and the lack of easy way to test a PR, it's kind of difficult to be confident in the result… :)
Also, from a "philosophical" perspective, I prefer not merging my own PRs and believe it's always better to have another set of eyes on them before merging. As evidenced by this issue, I think we can agree that it's not even enough! :)
Generally speaking, if rules can't be automatically enforced, people are bound to make mistakes. I don't release to launcher often enough to remember each time that master needs to always be releasable so I don't trust myself to not make that mistake again if nothing prevents me from doing it… ;)

[gastaldi]

That's why it's always a good idea to have more than one person in their respective teams: eg. https://github.com/orgs/fabric8-launcher/teams/runtime-spring-boot/members

Feel free to invite anyone from your team to join that team, which should be able to review your PRs and merge them and vice-versa ;)

[metacosm]

That would help somewhat (though members have to accept their invitations, wink, wink) but I still believe that if automated gates are not put in place, mistakes are bound to happen…

[piyush-garg]

@gastaldi If you go through the comments on the issue snowdrop/configmap-example#47 which I created as suggested by you mentions that catalog should not have been updated till the artifacts become available. Is not this statement make this is a valid issue here? Wont you think the change should be reverted? Maybe I am wrong here, Please clarify.

[gastaldi]

@piyush1594 yes, the catalog should only be updated when the artifacts are available (the tagged versions declared in staging and production). If they aren't, then the change must be reverted.

[piyush-garg]

Then according to the last comment, please reopen the issue and remove the invalid tag

[metacosm]

I will revert the change now.

[Ladicek]

We have a release checklist that puts "PR to booster catalog" after the "bits available" step. Maybe we should just follow that.

[piyush-garg]

@metacosm

I see you have reverted the change here #200 and then again you have created a PR that with not merge flag #201 till the artifacts did not get published. I see there is a change in booster.yaml file structure. Can't we keep this file consistent

[metacosm]

@piyush1594 the change in #200 is temporary, the structure we'll keep is most likely the one in #201. Easier to process.
@Ladicek I wasn't aware of that checklist until today, as a matter of fact… and yes, it is helpful but it showed up too late in this case.

[Ladicek]

@metacosm That is... sad. Not your fault, of course.