add default workspace when auto starting pipeline from Add flow #7237

karthikjeeyar · 2020-11-17T10:24:56Z

Fixes:
https://issues.redhat.com/browse/ODC-5118

Analysis / Root cause:
As a user, when I'm getting my Pipeline Run auto-started off the add flow, I need a PVC volumeClaimTemplate otherwise my Pipeline Run doesn't successfully run.

Solution Description:

Attach a default volumeClaimTemplate to the pipelineRun when auto starting a pipeline through the +Add flow with pipeline metadata label attached to it.
Use the pipeline metadata label pre select the PVC in the Start pipeline modal and Add Trigger modal or fallback to select the EmptyDirectory option

Screen shots / Gifs for design review:

PVC getting created through the add flow pipeline auto start feature (via volumeclaimTemplate in the pipelinerun).

2. In Start Modal, PVC getting auto selected using the pipeline label attached to it.

3. In Add trigger, PVC getting auto selected

Pipelines are now getting executed successfully

Unit test coverage report:

Browser conformance:

Chrome
Firefox
Safari
Edge

cc: @andrewballantyne @jerolimov @vdemeester @openshift/team-devconsole-ux

jerolimov · 2020-11-17T11:16:51Z

/assign

andrewballantyne · 2020-11-17T15:09:28Z

/assign

vdemeester

This uses volumeClaim by default right ? If that's the case, it works, but this means there might be a few "gotchas":

2 pipelines running in parallel might run into problems as they will want to write to the same PVC
the git-clone task needs to set a parameter (that "reset" the workspace before cloning) — that parameter should default to "true" but doesn't as of today I think.

karthikjeeyar · 2020-11-17T17:46:11Z

@vdemeester Thank you for the review :)

This uses volumeClaim by default right ? If that's the case, it works, but this means there might be a few "gotchas"

2 pipelines running in parallel might run into problems as they will want to write to the same PVC

Hmmm... 2 different pipelines will have 2 different PVC generated here, but for a single pipeline there can be parallel pipelineruns which might use same PVC to read/write. Any suggestions to overcome this issues?

the git-clone task needs to set a parameter (that "reset" the workspace before cloning) — that parameter should default to "true" but doesn't as of today I think.

In pipeline 1.2, git-clone task has deleteExisting parameter which has default value set to "true". Is this what you are refferring when you say reset ? If yes, then we are good there.

vdemeester · 2020-11-18T09:52:22Z

Hmmm... 2 different pipelines will have 2 different PVC generated here, but for a single pipeline there can be parallel pipelineruns which might use same PVC to read/write. Any suggestions to overcome this issues

Right, I wasn't clear indeed, I was talking about one pipeilne and two parallel pipelinerun. This could happen "relatively" quickly if this is hooked to a git repository and there is multiple developer on it. Using volumeClaimTemplate would help there (but this would mean a new PVC is created for each run.. which means at some point, the user might run out of space if pipelinerun are not cleaned up)

In pipeline 1.2, git-clone task has deleteExisting parameter which has default value set to "true". Is this what you are refferring when you say reset ? If yes, then we are good there.

Yes 👍 very good then 😝

karthikjeeyar · 2020-11-18T10:20:00Z

Agreed, PVC isn't a best option in triggerTemplates @vdemeester We have a story to track this ODC-4772, but it dint make it to 4.7 though.

abhinandan13jan · 2020-11-20T11:08:26Z

frontend/packages/pipelines-plugin/src/components/pipelines/hooks.ts

@@ -9,6 +13,7 @@ import { pipelinesTab } from '../../utils/pipeline-utils';
 import { PipelineRun, getLatestRun } from '../../utils/pipeline-augment';
 import { TektonResourceLabel } from './const';
 import { PipelineRunModel } from '../../models';
+import { PersistentVolumeClaimModel } from '@console/internal/models';


nit: move import

abhinandan13jan · 2020-11-20T11:29:04Z

frontend/packages/pipelines-plugin/src/components/import/pipeline/pipeline-template-utils.ts

@@ -67,6 +72,11 @@ export const createPipelineForImportFlow = async (
 export const createPipelineRunForImportFlow = async (pipeline: Pipeline): Promise<PipelineRun> => {
  const pipelineInitialValues: StartPipelineFormValues = {
    ...convertPipelineToModalData(pipeline),
+    workspaces: (pipeline.spec.workspaces || []).map((workspace: PipelineWorkspace) => ({


is it better to have a null check? pipeline.spec?.workspaces

I have added a fallback || [] above, so it will not break.

sure but if a pipeline doesn't have specs yet, could it through cannot read property workspaces of undefined

You can't create a Pipeline without a spec:

andrewballantyne · 2020-11-20T20:04:13Z

frontend/packages/pipelines-plugin/src/components/import/pipeline/pipeline-template-utils.ts

+      case 'MAJOR_VERSION':
+        return { ...param, default: 'latest' }; // This needs to be removed when backend sends default value


Probably should remove this 🤔 It's in the preview channel, we can install 4.6 which is 1.1.z and that will work fine. They need to update 1.2.z to have this default.

removed it.

andrewballantyne · 2020-11-20T20:41:04Z

frontend/packages/pipelines-plugin/src/components/pipelines/modals/triggers/AddTriggerModal.tsx

@@ -48,6 +51,7 @@ const AddTriggerModal: React.FC<AddTriggerModalProps> = ({ pipeline, close }) =>
      initialValues={initialValues}
      onSubmit={handleSubmit}
      validationSchema={addTriggerSchema(t)}
+      enableReinitialize


Hmmm, not sure about this... kinda would want to wait for the data before rendering Formik. Reinitializing data could have side-effects mid-usage.

I have removed the enableReInitiaze prop and waiting for the data to render Formik.

andrewballantyne · 2020-11-20T20:41:19Z

...kages/pipelines-plugin/src/components/pipelines/modals/start-pipeline/StartPipelineModal.tsx

@@ -54,6 +56,7 @@ const StartPipelineModal: React.FC<StartPipelineModalProps & ModalComponentProps
      initialValues={initialValues}
      onSubmit={handleSubmit}
      validationSchema={startPipelineSchema(t)}
+      enableReinitialize


Same issue here...

andrewballantyne

/lgtm
/retest

openshift-ci-robot · 2020-11-24T18:31:25Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewballantyne, karthikjeeyar

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~frontend/packages/pipelines-plugin/OWNERS~~ [andrewballantyne]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

andrewballantyne · 2020-11-24T21:00:35Z

/retest

jerolimov · 2020-11-24T23:00:11Z

/retest

openshift-bot · 2020-11-24T23:58:56Z

/retest

Please review the full test history for this PR and help us cut down flakes.

jerolimov · 2020-11-25T00:48:47Z

/retest

openshift-bot · 2020-11-25T01:03:52Z

/retest

Please review the full test history for this PR and help us cut down flakes.

openshift-bot · 2020-11-25T02:21:53Z

/retest

Please review the full test history for this PR and help us cut down flakes.

karthikjeeyar · 2020-11-25T04:01:08Z

/retest

karthikjeeyar · 2020-11-25T05:15:57Z

/retest

openshift-bot · 2020-11-25T05:23:56Z

/retest

Please review the full test history for this PR and help us cut down flakes.

openshift-bot · 2020-11-25T08:12:57Z

/retest

Please review the full test history for this PR and help us cut down flakes.

openshift-bot · 2020-11-25T08:51:58Z

/retest

Please review the full test history for this PR and help us cut down flakes.

karthikjeeyar · 2020-11-25T10:06:53Z

/test e2e-gcp-console

openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Nov 17, 2020

openshift-ci-robot requested review from abhinandan13jan and debsmita1 November 17, 2020 10:25

karthikjeeyar force-pushed the default-workspace branch from 7d14f6f to a4626a3 Compare November 17, 2020 10:27

openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Nov 17, 2020

openshift-ci-robot assigned jerolimov Nov 17, 2020

openshift-ci-robot assigned andrewballantyne Nov 17, 2020

vdemeester reviewed Nov 17, 2020

View reviewed changes

abhinandan13jan reviewed Nov 20, 2020

View reviewed changes

andrewballantyne suggested changes Nov 20, 2020

View reviewed changes

add default workspace when auto starting pipeline from Add flow

0a3a217

karthikjeeyar force-pushed the default-workspace branch from a4626a3 to 0a3a217 Compare November 23, 2020 17:48

andrewballantyne approved these changes Nov 24, 2020

View reviewed changes

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 24, 2020

openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 24, 2020

openshift-merge-robot merged commit 54f261a into openshift:master Nov 25, 2020

spadgett added this to the v4.7 milestone Nov 30, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add default workspace when auto starting pipeline from Add flow #7237

add default workspace when auto starting pipeline from Add flow #7237

karthikjeeyar commented Nov 17, 2020 •

edited

jerolimov commented Nov 17, 2020

andrewballantyne commented Nov 17, 2020

vdemeester left a comment

karthikjeeyar commented Nov 17, 2020 •

edited

vdemeester commented Nov 18, 2020

karthikjeeyar commented Nov 18, 2020

abhinandan13jan Nov 20, 2020

abhinandan13jan Nov 20, 2020

karthikjeeyar Nov 20, 2020

abhinandan13jan Nov 20, 2020

andrewballantyne Nov 20, 2020

andrewballantyne Nov 20, 2020

karthikjeeyar Nov 23, 2020

andrewballantyne Nov 20, 2020

karthikjeeyar Nov 23, 2020

andrewballantyne Nov 20, 2020

andrewballantyne left a comment

openshift-ci-robot commented Nov 24, 2020

andrewballantyne commented Nov 24, 2020

jerolimov commented Nov 24, 2020

openshift-bot commented Nov 24, 2020

jerolimov commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

karthikjeeyar commented Nov 25, 2020

karthikjeeyar commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

karthikjeeyar commented Nov 25, 2020

		case 'MAJOR_VERSION':
		return { ...param, default: 'latest' }; // This needs to be removed when backend sends default value

add default workspace when auto starting pipeline from Add flow #7237

add default workspace when auto starting pipeline from Add flow #7237

Conversation

karthikjeeyar commented Nov 17, 2020 • edited

jerolimov commented Nov 17, 2020

andrewballantyne commented Nov 17, 2020

vdemeester left a comment

Choose a reason for hiding this comment

karthikjeeyar commented Nov 17, 2020 • edited

vdemeester commented Nov 18, 2020

karthikjeeyar commented Nov 18, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewballantyne left a comment

Choose a reason for hiding this comment

openshift-ci-robot commented Nov 24, 2020

andrewballantyne commented Nov 24, 2020

jerolimov commented Nov 24, 2020

openshift-bot commented Nov 24, 2020

jerolimov commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

karthikjeeyar commented Nov 25, 2020

karthikjeeyar commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

openshift-bot commented Nov 25, 2020

karthikjeeyar commented Nov 25, 2020

karthikjeeyar commented Nov 17, 2020 •

edited

karthikjeeyar commented Nov 17, 2020 •

edited