-
Epic
-
Resolution: Done
-
Major
-
None
-
None
-
Update console to handle builds v1 being optional
-
False
-
None
-
False
-
Green
-
To Do
-
OCPSTRAT-867 - Update console to handle that admins can opt-out from Build v1 (BuildConfig) and DeploymentConfigs
-
0
-
OCPSTRAT-867Update console to handle that admins can opt-out from Build v1 (BuildConfig) and DeploymentConfigs
-
0% To Do, 0% In Progress, 100% Done
-
S
-
Not Supported
Problem:
When the cluster does not have v1 builds, console needs to either provide different ways to build applications or prevent erroneous actions.
Goal:
Identify the build system in place and prompt user accordingly when building applications.
Why is it important?
Without this enhancement, users will encounter issues when trying to create applications on clusters that do not have the default s2i setup.
Use cases:
- As a developer, provide me with a default build option, and show options to override.
- As a developer, prevent me from trying to create applications if no build option is present on the cluster.
Acceptance criteria:
Console will have to hide any workflows that rely solely on buildconfigs and pipelines is not installed.
If we detect Shipwright, then we can call that API instead of buildconfigs. We need to understand the timelines for the latter part, and create a separate work item for it.
If both buildconfigs and Shipwright are available, then we should default to Shipwright. This will be part of the separate work item needed to support Shipwright.
Dependencies (External/Internal):
rgormley@redhat.com to confirm timelines when customers will have to option to remove buildconfigs from their clusters. That will determine whether we take on this work in 4.15 or 4.16.
Design Artifacts:
Exploration:
Note:
- is related to
-
WRKLDS-695 Make DeploymentConfig and BuildConfig apis optional
- Closed
- relates to
-
OCPBUILD-21 Make builds v1 api optional
- Closed
- links to