-
Notifications
You must be signed in to change notification settings - Fork 66
Curate list of boosters/quickstarts to only contain those that actually will work within Che in openshift online #316
Comments
To be clear, this is to remove those quickstarts that do NOT run on our build set or work in Che? |
Ideal is to have only quickstarts that actually will deploy AND be possible to run the unit tests in Che (even if that means remove the tests) |
So these are the boosters in https://github.com/openshiftio/booster-catalog right? Let me know which boosters are valid and then I'll create a branch containing only the supported boosters (probably named |
We'll have a meeting on Monday 10th to discuss about how to improve the booster-catalog, so although a different branch will resolve the issue for now, the strategy may will probably change depending on the outcome of the meeting. |
so to fix this blocker for now we could just remove them all right ? /me ducks :) |
<sarcasm> 😃 |
basically. Here is a result of @ldimaggi running through them: Vert.X basic - OK @ldimaggi can you confirm if you in this tested they work from within Che too or only wether they deployed ? |
I probably can't make it but could you add me on this as I would like to listen in to better understand the challenges. |
Btw to be clear: We absolutely need to get the list cut down to actually working on openshift.io quickstarts. If they don't work in the deploy phase nor when running tests in Che they are a waste of time for users on openshift.io to try out. Thus getting the list reduced to what actually runs by July 14th is of higher priority than fixing the quickstarts. |
Note that due to a current limitation in OSIO, regardless of the booster/quickstart selected, the Che stack will always be the same one (plain java): fabric8-ui/fabric8-ui#1534 |
And - in the unpaid account config, the user can have (1) Che workspace at a time. |
So to be able to filter the list of boosters we display unfortunately thats all done inside the Obsidian code in List<Booster> quickstarts = this.catalogService.getBoosters();
this.type.setValueChoices(quickstarts);
if(!quickstarts.isEmpty()) {
this.type.setDefaultValue(quickstarts.get(0));
} so we'll need code in @Override
public void initializeUI(UIBuilder builder) throws Exception {
super.initializeUI(builder);
Object boosterCatalogValue = getParentClassFieldValue("catalogService");
if (boosterCatalogValue == null || !(boosterCatalogValue instanceof BoosterCatalogService)) {
LOG.warn("Cannot find the parent `catalogService` field!");
return;
}
Object boosterFieldValue = getParentClassFieldValue("type");
if (boosterFieldValue == null || !(boosterFieldValue instanceof UISelectOne)) {
LOG.warn("Cannot find the parent `type` field!");
return;
}
BoosterCatalogService boosterCatalog = (BoosterCatalogService) boosterCatalogValue;
UISelectOne boosterField = (UISelectOne) boosterFieldValue;
List<Booster> boosters = boosterCatalog.getBoosters();
// TODO filter out the list to only include the boosters we want to include...
boosterField.setDefaultValue(boosters);
} |
@jstrachan until we come up with the definitive solution, we can create a new branch in booster-catalog and add only the passing boosters so you guys can use them without any changes. WDYT? |
@ldimaggi @maxandersen to be clear For what I can see errors are related to the fact that file |
so we just need to have 'fabric8:resource' tied into the test lifecycle ? |
@l0rd btw. when I run 'mvn' from terminal I get:
|
OK here is our curated list of boosters we include: https://github.com/fabric8io/fabric8-generator/blob/master/src/main/java/io/fabric8/forge/generator/quickstart/ValidBoosters.java#L39 So if we find another booster that works - or one to remove - we can just make a PR on this file. When we can refer to individual versions of boosters we can then add better automated CI pipelines to add/remove/upgrade individual boosters. |
I don't know how we should run this test. What I can tell is that if I
Weird. It works for me but that doesn't count :-) It works on @ldimaggi tests so maybe you are running an old version of Che? |
Awesome @jstrachan and @l0rd for now if we can't give users an end-2-end walkthrough that is somewhat error free that is considered a blocker. But yes, it is not Che specific - it is the quickstarts that are faulty. About Che being old, then status says I'm running 1.0.201 - is that old or new ? |
The latest che is |
@maxandersen the new filtered list is now live on prod. Though it looks like a UI regression has kicked in breaking all combo boxes + kebab menus fabric8-ui/fabric8-ui#1726 so you can only pick 1 quickstart anyway right now ;) |
@maxandersen I'm able to reproduce your issue when trying to run maven in Che terminal:
As a workaround I've That happens because the docker image used to run Che workspaces is rhche/vertx. Before it was rhche/centos_jdk8 but we need to figure what caused this change of stack. By the way this problem should be solved by redhat-developer/rh-che#147 that is currently wip by @dharmit |
No description provided.
The text was updated successfully, but these errors were encountered: