New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1872336: Use metadata.generatorName when create a pipeline trigger #6248
Conversation
/king bug |
frontend/packages/dev-console/src/components/pipelines/modals/common/types.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you did a bit of a refactor to solve a long standing issue (ODC-2184)... unfortunately this is not going to be acceptable during the stability sprints. We should look to trim this down to just managing a use of generateName
for the trigger modal.
If you want, you can copy this code out and open up another PR we can get into master when it switches to 4.6 - but that's likely not until Oct 2nd.
frontend/packages/dev-console/src/components/pipelines/modals/common/types.ts
Outdated
Show resolved
Hide resolved
5388662
to
59ffa52
Compare
@jerolimov: This pull request references Bugzilla bug 1872336, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@andrewballantyne I removed the refactoring and monitor ODC-2184 so that we can maybe apply these changes later. The original changes are available here: master...jerolimov:odc-4236-with-refactoring I keep the extended unit tests. I'm open for any feedback. 😄 |
@jerolimov: This pull request references Bugzilla bug 1872336, which is valid. 3 validation(s) were run on this bug
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are on the right path for wanting to improve this... but as you found during your original changes, this is a broken path as it is today. Getting a Pipeline Run needs to be improved a lot and I don't know if it's worth while touching that path today. Just a straight improvement later to get us to the right spot might be the better call.
@@ -12,14 +12,15 @@ import { | |||
} from '../../resource-types'; | |||
|
|||
export const createTriggerTemplate = ( | |||
pipeline: Pipeline, | |||
pipelineRun: PipelineRun, | |||
params: TriggerTemplateKindParam[], | |||
): TriggerTemplateKind => { | |||
return { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could just override it for this one use-case rather than baking it into the (more or less) broken flow that exists today getting a Pipeline Run.
I think the refactor portion of your PR hit the nose of the problem, and that definitely is the better choice once we can refactor the code. Just not sure we need to pollute "crafting a pipeline run" if we are going to rewrite it in a few anyways.
I just suggest the modification here:
const resource = _.omit(pipelineRun, 'metadata.name');
resource.metadata.generateName = `${pipeline.metadata.name}-`;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andrewballantyne I though multiple times (and longer than I should) about this.. I would be happy if we stay with this (reduced) change. Keep the additional options parameter allow us to extend the unit tests for this case. Keep the additional tests instead of just "override" the generated json here is worth enough to touch 3 files.
I'm on your side that its still not perfect, but for me it looks like the right direction. 🤔
I'm also happy if we want split this method into 3 when starting with 4.7.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going with Christoph's suggestion to keep this change.
Imo, a full refactor in 4.7 is much better than a partial change here, but I left it up to him to make the call. Let's hope this fragile piece of the code doesn't come back to haunt us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andrewballantyne, jerolimov, rottencandy 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:
Approvers can indicate their approval by writing |
@jerolimov: All pull requests linked via external trackers have merged: Bugzilla bug 1872336 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/cherry-pick release-4.5 |
@jerolimov: new pull request created: #6615 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Fixes:
https://issues.redhat.com/browse/ODC-4236
Analysis / Root cause:
When adding a new Trigger for a Pipeline the web console creates an
EventListener
and aTriggerTemplate
. The trigger templates contains a spec of a PipelineRun configuration (incl. parameters and resources) which will be created when an event is received. The current PipelineRun spec defines a fix name which could be created only once.Solution Description:
To create multiple PipelineRun objects it is required to the a metaname
generateName
instead ofname
in the TriggerTemplate spec.Some background infos I received from Andrew:
generateName
attributeYAML diff:
Screen shots / Gifs for design review:
Nothing changed in the UI
But here you see the relevant part of the test setup below:
Unit test coverage report:
Added some unit tests, no big change here.
Before:
After:
Test setup:
Browser conformance: