When importing existing project only Maven pipelines are available

[bartoszmajsak]

When user imports existing project he can select one of the pipelines through the wizard.

The problem is that these are always "maven based", so Jenkinsfile which we add to the repository will expect JVM/Maven project resulting in not working pipelines for other stacks/build tools.

As an interim solution, we could think of an additional step in the "import flow" of the wizard, where the user can be asked to select his stack - but we can't really assure yet those pipelines will work in the OSIO Build (e.g. nodejs pipeline requires Docker right now).

Therefore until we have it working I propose making import only for Maven (additional step with the clear information for the user).

[bartoszmajsak]

@catrobson we might need some UX help on the additional step where user can select his runtime.

/cc @slemeur

[slemeur]

I agree that for now we are not able to handle other projects than Maven ones. So we should be informing the user about that into the import wizard.

Here are my thoughts on the flow:

• We notify the user that he can import only maven projects for now
• When the user is doing the import, we check the the project is having a maven file. If yes, we continue, otherwise we raise an error.
• Then, we check for the existence of a jenkinsfile.
  • If there is a jenkinsfile already in the repo, we should propose to the user to leverage it. (Question here is, how much can we use it or tune it for our pipelines?)
  • If there is no jenkinsfile, then we propose to the user to chose one of the pipeline.

Then, step by step, we can add more stacks and more technologies. At first, the user would be asked to choose that and do the configuration himself, but ideally I'd like the wizard to be intelligent enough to understand what's going to be imported and provide recommended choice and guidance to the user.

[catrobson]

+1 to @slemeur's thoughts on the flow. Since we only have Maven projects right now let's not introduce another step forcing the user to map their project to the runtime. Once we plan to extend beyond Maven projects we can discuss how to make this part work.

[bartoszmajsak]

Thanks @slemeur. I think we can do following right away

• after importing the project we check if it's Maven based and if so we advance to pipeline selection
• otherwise we show error with the information as you suggested

If there is a jenkinsfile already in the repo, we should propose to the user to leverage it. (Question here is, how much can we use it or tune it for our pipelines?)

Question is if we can afford giving such a promise, as we have quite opinionated environment right now. It should be a broader conversation with the build team, as I'm not sure we are able to support all that users could have there.

For non-evaluation and externally hosted Jenkins instances it is another story - probably would need to handle, but I am not sure how far on the horizon that is /cc @arilivigni @sthaha

I'd like the wizard to be intelligent enough to understand what's going to be imported and provide recommended choice and guidance to the user.

Absolutely, we share the same goal :)

[catrobson]

@serenamarie125 @openshiftio/uxd-team - After a chat discussion with @bartoszmajsak, I now understand that we're trying to move towards being able to support Maven + Nodejs projects in the J Train. In order to support that, a runtime discovery/selection will be necessary. A few things we discussed:

• The name of the first step should probably be "Import codebase" or "Select repository" or something to that effect over "Authorize git provider"
• We will try to detect what runtime the codebase is based on files present in it. There are several use cases that may then come up: The runtime is 'obvious' on detection. We show the user what we have detected. There seems to be multiple stacks on detection. We'll allow the user to select the right runtime. ** We've detected that they are using an incompatible codebase for our current runtimes. We display an error explaining what runtimes we support.

We talked about it being desirable that the runtime selection happens within step 1 of importing (Option 1 below)

However, the challenge here is that you're putting runtimes into a box where the context is "github".

I think we could do something where the discovery kicks off as soon as you select a repository, and right below the GitHub stuff as a full width area that expands downward we could display the results of this automatic discovery covering the three use cases above. I think adding it to step 1 of the import launcher will require a bit of design work because of this dynamic behavior, and some UI implementation with animated transitions.

We'll need to kick off some UX Work to support this effort.

[catrobson]

Had a copy/paste queue error. Please refer to issue for latest screenshot.

[bartoszmajsak]

In terms of import, we should distinguish two aspects of discovery:

• technology stack (VertX, Thorntail, SpringBoot)
• build tool (Maven, Gradle, Ant)

Both are equally important for both build and IDE, but for our pipeline selection, we rely on an odd mix of those right now. For Java we only support Maven and the whole pipeline library is Maven-focused (so we don't support other build tools right now). You can see pipelines templates here https://github.com/fabric8io/fabric8-jenkinsfile-library their naming is a mix of runtime and build tools right now.

[catrobson]

@bartoszmajsak Here is a design for how we can add the runtime information into the import flow. Please review and let us know if you have any feedback or updates. Otherwise we should talk to @krishnapaparaju about how we would proceed forward with implementing these changes.

https://redhat.invisionapp.com/share/WQNGYRPSAYJ

[bartoszmajsak]

Thanks @catrobson. As I mentioned above, runtime itself might not be sufficient right now. We should also know which build tool is in use. Based on the proposed design above we can have at least two common combinations:

• Spring Boot + Maven (what we can support right now)
• Spring Boot + Gradle (not supported as our pipelines don't support Gradle builds at this point)

[catrobson]

@bartoszmajsak Ok. I'm actually not sure how to clearly communicate this since we don't talk about build tools when selecting a runtime in the quickstart scenarios, so this is the first time that this matters. Do you think users will clearly understand what these are with just a label: field called "Build Tool: Maven|etc". Is a selection even necessary or do we only support Maven, so we actually only need to handle an error case where the build tool is not Maven?

[bartoszmajsak]

we don't talk about build tools when selecting a runtime in the quickstart scenarios

That's because our boosters are all Maven based and thus pipelines are preselected. When we import any Java project we have a bunch of other build tools to consider (e.g. Gradle or Ant) - which will need a proper setup on the build service side. Currently, build will fail if the imported Java project won't be Maven based (so that would be a "feature-request" to @sthaha / build team to support other build tools for JVM).

Is a selection even necessary or do we only support Maven, so we actually only need to handle an error case where the build tool is not Maven?

For the moment it's only "error case". With the support of node it will become more relevant. I think we should simply say something like "We only support JVM based projects built using Maven".

Runtime is a bit fuzzy term right now, as we say NodeJS is a runtime, but for JVM we distinguish frameworks (SpringBoot, VertX, Thorntail / WildFly Swarm) and call them runtimes. These are two different levels of abstraction IMHO.

Also, pipelines we are serving are a bit of an odd mix too. We have golang (so the language), node (runtime) and for JVM we only have Maven (so we have a container with Java and Maven installed to execute the build). This is an important concern for the build team again (cc @sthaha @arilivigni) to think about on what level we should talk when we say "what does the build service support".

[muruGanesan]

@bartoszmajsak, Did you get a chance to look at the UXD proposal? https://redhat.invisionapp.com/share/WQNGYRPSAYJ

• please let us know if you would like to discuss further and take this forward.

CC: @catrobson

[bartoszmajsak]

@muruGanesan I think the overall flow looks good. One option I could think of is to add selection of all supported runtime for the user regardless if we detect or not - to give him a way to correct based on his knowledge of the project.

As for what is presented - as I mentioned above we shouldn't talk about the runtimes such as Spring Boot or VertX, but the build tool used for those - in case of boosters all java projects (so Spring Boot and VertX too) are using Maven. We should show Maven instead.

[sbose78]

@bartoszmajsak

we shouldn't talk about the runtimes such as Spring Boot or VertX, but the build tool used for those - in case of boosters all java projects (so Spring Boot and VertX too) are using Maven. We should show Maven instead.

Are you proposing that we omit showing "Spring Boot / Vertx" as a detected runtime , and instead show "Maven/Gradle" because that's what our build really cares about?

[sbose78]

As a first cut - let's have the following:

On import,

Step 1 The UI would make a call to the backend to determine:

• maven project
• nodejs project
• unknown

The detection is shown to the user and the user is allowed to change it ( in case an incorrect detection was done )

Step 2 Based on the above, show the right pipelines.

What do you think?

[bartoszmajsak]

I would break it down even further to work on that in parallel to progress on that flow and fix issues which are currently there.

• start without build detection and only let the user select among supported build tools and show the right set of pipelines
• work on integrating detection as a parallel stream

WDYT @sbose78?

[sbose78]

@bartoszmajsak Sounds good!

@vikram-raj Let's give the user an option to say if the imported project is a

• maven project , or
• nodejs project

@Veethika Could you please help with a UX recommendation on how to present the choice to the user?

[ldimaggi]

Just to confirm - the user will be able to select either maven or nodejs - and not a third "other" option, yes?

[tinakurian]

@ldimaggi we don't support an "other" option yet. Only nodejs and maven. If however, the url to the repository we receive from the user is neither built by maven or nodejs the build-tool-detector will return "unknown." Not sure what our recourse is here? Do we just notify the user that it's unsupported and not show any pipelines? Or are there some default pipelines we show them? @sbose78 @bartoszmajsak

[bartoszmajsak]

Do we just notify the user that it's unsupported and not show any pipelines? Or are there some default pipelines we show them?

What would the default pipeline do if we don't have the tool supported yet? In my opinion, we should not allow importing such a project because if you can't build that or deploy what is OSIO useful for?

[tinakurian]

Do we just notify the user that it's unsupported and not show any pipelines? Or are there some default pipelines we show them?

What would the default pipeline do if we don't have the tool supported yet? In my opinion, we should not allow importing such a project because. If you can't build that or deploy what is OSIO useful for?

Not too sure. Perhaps you want to import and edit it in eclipse che? You arent ready to build and deploy yet? Maybe this is something you want to do at a later time? Perhaps the easier route would be to reject.

[bartoszmajsak]

But what is the benefit of editing it in Che if you can't really do much more than that?

[tinakurian]

I guess the way i was thinking about it was that you could import a barebones or even an old existing java project that hasn't been integrated with maven yet. After you import and open in eclipse che, you're next step could be to add in maven. Maybe in eclipse you want to select the "Convert to Maven project" option. Now you have a pom.xml and you can select a build + pipelines...

[bartoszmajsak]

It is a valid use case, I'm just not sure we are there yet.

Now you have a pom.xml and you can select a build + pipelines...

Not sure we have an option of "add pipeline" later in the flow yet, or in general incremental enrichment of the project with OSIO bits.

[tinakurian]

It is a valid use case, I'm just not sure we are there yet.

Now you have a pom.xml and you can select a build + pipelines...

Not sure we have an option of "add pipeline" later in the flow yet, or in general incremental enrichment of the project with OSIO bits.

Hmm, okay.

[bartoszmajsak]

What I would suggest is to slice it to a few iterations to ship it faster - so first cut would be to just not being able to continue when the project is not "compatible with our pipelines" (so it's of unknown type), but still allowing user to select one of the supported ones. Next step would be an "incremental enrichment", but this is a broader discussion I believe and needs to be surfaced from several angles in OSIO. /cc @gorkem

[sbose78]

Yes, other than node and maven, we wouldn't let the user proceed with the import.

The issue otherwise would be:

• the user would have an expectation that the imported project would work in all angles in OSiO - which would be incorrect.
• In the current form, we expect to start a che workspace using a stackID . ( which we would like to change in future by letting the user enter custom che config while importing https://github.com/openshiftio/openshift.io/issues/4536 )

[ldimaggi]

+1 Initially limit the user to: other than node and maven, we wouldn't let the user proceed with the import.

[serenamarie125]

Where are we with this, @christianvogt are you tracking the UI changes for this?

[christianvogt]

@serenamarie125 Tracked by https://openshift.io/openshiftio/Openshift_io/plan/detail/404 assigned to @vikram-raj

[vikram-raj]

This issue has been fixed and on prod.