Problem:

Currently, our Add page has 3 different options to allow the user to Import from Git: (1) Import from git (2) Import from dockerfile (3) Import from devfile

Goal:

Provide a single converged flow to allow developers to import from git.

Acceptance criteria:

1. As a developer, I should only see a single Import from git option on the add page & context menus in topology
2. As a developer, when using the Import from git option, I should be provided with a smart default, based on the contents of my git repo
3. As a developer, I should always be thrown all 3 options (Builder Image, Dockerfile, Devfile)
4. As a developer, if I select the builder image,
   1. I should see the same options we currently provide for Import from Git
   2. I should have access to all Adv Options
5. As a developer, if I select the dockerfile option,
   1. I should see the same options we currently provide for Import from Dockerfile
   2. I should be able to provide more info to help find my Dockerfile
   3. I should have access to all Adv Options
6. As a developer, if I select the devfile option,
   1. I should see the same options we currently provide for Import from Devfile
   2. I should be able to provide more info to help find my devfile
   3. I should have access to all Adv Options

Dependencies (External/Internal)

Design Artifacts

Exploration

MIRO Board

Notes

ALWAYS show the 3 options
provide a smart default
allow the user to provide more info (Dockerfile or devfile path) if they want

Need a utility that inspects the Git repo:

• if devfile found, would do that magic ( devfile should be default, but still allow the user to select builder option )
• if no devfile & it found a dockerfile would do that magic (dockerfile should be default, but still allow the user to select builder option )
• if no devfile or dockerfile, would do what we currently do today w/import from git
• if it found a combination, it would let the user know & prompt them as to which to proceed with ( using devfile as default if that was available )

Note, this git repo inspect utility should be extensible to allow future import types ala "intelligent import".   

For example, we inspect a git repo and offer options depending on what is detected 

1.  a gitops/kam repository , you could import an Gitops application ( https://issues.redhat.com/browse/GITOPS-455)  
2. if its repo with  pipelines as code included  (https://issues.redhat.com/browse/SRVKP-472) , (could be detected by the .tekton folder) then it could offer setup, configure and edit(save)
3. if it has a github actions workflow we could enable access to the cluster via the github app, offer extended scenarios (runners) .. out of scope for this issue but enabled in a future.