-
Notifications
You must be signed in to change notification settings - Fork 807
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
fix(artifacts): Be more lenient when filtering expected artifacts #4397
fix(artifacts): Be more lenient when filtering expected artifacts #4397
Conversation
@dbyron-sf Do you think you can have a look at this? A little follow up on #4322 👍 |
.getResolvedArtifacts() | ||
.stream() | ||
.findFirst(); | ||
} catch (InvalidRequestException e) { |
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.
What is throwing InvalidRequestException that we might catch here?
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.
ArtifactResolver.resolveExpectedArtifacts()
throws this if it's unable to resolve the artifact. It's not something we care about, as most often it will probably not be matched.
I could use an example of a pipeline + trigger that doesn't work before this PR, but does work after. Especially if it's also one that worked before #4322. And then, is there a place to put that pipeline in a test? Maybe the first commit in this PR could be adding that test? |
f07b693
to
28b1030
Compare
I have rebased and split the commits so that I add the tests in the first commit and the implementation code in the second. There are two new tests, plus a minor edit to an existing one to check that the filter doesn't remove artifacts with
The whole point is to fix pipelines without any defined triggers, that are triggered by some other pipeline (using a pipeline stage). They will get an implicit trigger when being executed, but the pipeline config is (optionally) defined without any triggers at all. |
f406928
to
d8172fb
Compare
Not directly - defined inline it would not have worked earlier. But what you could do before was to define the expected artifact(s) on the child pipeline (as a workaround), and then use that artifact instead of defining it inline. But that is kind of hackish - you need to add a trigger to be able to define the artifact, and then you can remove the trigger again. After #4322 any expected artifacts defined using this workaround would be ignored, since Orca now only considers artifacts on the trigger actually used in the execution. |
It is currently hard/impossible to resolve artifacts in pipelines that doesn't have any triggers defined by themselves, and are triggered by a pipeline stage in another pipeline. Previously it was possible to get it to work by editing the json of the pipeline or in the UI by adding artifacts in a temp trigger and then removing it (this would keep the expected artifacts around). When I introduced trigger specific artifact constraints in spinnaker#4322, I made it a lot harder (if not impossible) to do this because no triggers are used and thus all expected artifacts are filtered out. This commit contains tests that demonstrate the issue.
It is currently hard/impossible to resolve artifacts in pipelines that doesn't have any triggers defined by themselves, and are triggered by a pipeline stage in another pipeline. Previously it was possible to get it to work by editing the json of the pipeline or in the UI by adding artifacts in a temp trigger and then removing it (this would keep the expected artifacts around). When I introduced trigger specific artifact constraints in spinnaker#4322, I made it a lot harder (if not impossible) to do this because no triggers are used and thus all expected artifacts are filtered out. This commit contains implementation code to fix the tests added in the previous commit. It will fix the issue by copying expected artifacts from the parent execution (only if triggered by a pipeline stage), thus avoiding the whole situation altogether. It will also not filter away any expected artifacts where `useDefaultArtifact` or `usePriorArtifact` is set to `true`, and it will bind artifacts defined inline in stages (so that you can match artifacts using regex and not only SpEL).
d8172fb
to
4816f8c
Compare
Thanks much @jervi . Think any of this warrants a release note? |
Explain the changes from spinnaker/orca#4397
@dbyron-sf I made a PR for some release notes: spinnaker/spinnaker.io#308 |
* docs(releasenotes): Changes to artifact handling Explain the changes from spinnaker/orca#4397 * Add image to repo
Thank you! |
This commit partially reverts spinnaker#4397. It broke some pipelines for a team that had a CI stage that created more artifacts with the same name as the expected artifact from the original trigger, and then had a pipeline stage. The result was that the child pipeline was triggered with multiple artifacts with the same name (but different version numbers), and then failed to start because the artifact resolver matched multiple artifacts instead of exactly one. Turns out the changes in DependentPipelineStarter wasn't really needed to fix the issue that spinnaker#4397 tried to solve, so I'm reverting them.
…4404) This commit partially reverts #4397. It broke some pipelines for a team that had a CI stage that created more artifacts with the same name as the expected artifact from the original trigger, and then had a pipeline stage. The result was that the child pipeline was triggered with multiple artifacts with the same name (but different version numbers), and then failed to start because the artifact resolver matched multiple artifacts instead of exactly one. Turns out the changes in DependentPipelineStarter wasn't really needed to fix the issue that #4397 tried to solve, so I'm reverting them.
…innaker#4397) * test(artifacts): Be more lenient when filtering expected artifacts It is currently hard/impossible to resolve artifacts in pipelines that doesn't have any triggers defined by themselves, and are triggered by a pipeline stage in another pipeline. Previously it was possible to get it to work by editing the json of the pipeline or in the UI by adding artifacts in a temp trigger and then removing it (this would keep the expected artifacts around). When I introduced trigger specific artifact constraints in spinnaker#4322, I made it a lot harder (if not impossible) to do this because no triggers are used and thus all expected artifacts are filtered out. This commit contains tests that demonstrate the issue. * fix(artifacts): Be more lenient when filtering expected artifacts It is currently hard/impossible to resolve artifacts in pipelines that doesn't have any triggers defined by themselves, and are triggered by a pipeline stage in another pipeline. Previously it was possible to get it to work by editing the json of the pipeline or in the UI by adding artifacts in a temp trigger and then removing it (this would keep the expected artifacts around). When I introduced trigger specific artifact constraints in spinnaker#4322, I made it a lot harder (if not impossible) to do this because no triggers are used and thus all expected artifacts are filtered out. This commit contains implementation code to fix the tests added in the previous commit. It will fix the issue by copying expected artifacts from the parent execution (only if triggered by a pipeline stage), thus avoiding the whole situation altogether. It will also not filter away any expected artifacts where `useDefaultArtifact` or `usePriorArtifact` is set to `true`, and it will bind artifacts defined inline in stages (so that you can match artifacts using regex and not only SpEL).
…pinnaker#4404) This commit partially reverts spinnaker#4397. It broke some pipelines for a team that had a CI stage that created more artifacts with the same name as the expected artifact from the original trigger, and then had a pipeline stage. The result was that the child pipeline was triggered with multiple artifacts with the same name (but different version numbers), and then failed to start because the artifact resolver matched multiple artifacts instead of exactly one. Turns out the changes in DependentPipelineStarter wasn't really needed to fix the issue that spinnaker#4397 tried to solve, so I'm reverting them.
This fix allows us to revert spinnaker#4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, it should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <benjamin_j_powell@apple.com> Signed-off-by: benjamin-j-powell <bjp@apple.com>
This fix allows us to revert spinnaker#4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, it should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <bjp@apple.com>
This fix allows us to revert spinnaker#4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, the child pipeline should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <bjp@apple.com>
This fix allows us to revert #4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, the child pipeline should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <bjp@apple.com> Co-authored-by: Benevolent Benjamin Powell <benjamin_j_powell@apple.com>
This fix allows us to revert #4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, the child pipeline should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <bjp@apple.com> Co-authored-by: Benevolent Benjamin Powell <benjamin_j_powell@apple.com> (cherry picked from commit 2e3c5f0)
This fix allows us to revert #4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, the child pipeline should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <bjp@apple.com> Co-authored-by: Benevolent Benjamin Powell <benjamin_j_powell@apple.com> (cherry picked from commit 2e3c5f0)
This fix allows us to revert #4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, the child pipeline should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <bjp@apple.com> Co-authored-by: Benevolent Benjamin Powell <benjamin_j_powell@apple.com> (cherry picked from commit 2e3c5f0)
…ker#4575) This fix allows us to revert spinnaker#4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, the child pipeline should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <bjp@apple.com> Co-authored-by: Benevolent Benjamin Powell <benjamin_j_powell@apple.com>
…ker#4575) This fix allows us to revert spinnaker#4397 since that makes retrieving bound artifacts actually more strict for most use cases. So this commit addresses the root cause that that PR was trying to implement. When a parent pipeline triggers a child pipeline, the child pipeline should be able to resolve incoming artifacts properly. Right now that does not happen because `expectedArtifactIds` is needed in the trigger section, otherwise no resolution will occur. This change fixes the parent payload to include `expectedArtifactIds` by viewing the child pipeline's top level expected artifacts and finding the intersection between expected artifacts and artifacts to be sent. With that intersection we can grab the expected artifact ids and properly set the the necessary field to allow for child pipelines to ingest the artifact. Signed-off-by: benjamin-j-powell <bjp@apple.com> Co-authored-by: Benevolent Benjamin Powell <benjamin_j_powell@apple.com>
…en if you have 2 or more of the same type (#4579) * refactor(artifacts): partially reverting #4397 * refactor(artifacts): reverted #4489 * refactor(artifacts): reverted #4526 * test(artifacts): added test when parent pipeline does not provide expected artifacts * test(artifacts): resolve artifacts for default and prior artifacts --------- Co-authored-by: Cameron Motevasselani <cmotevasselani@gmail.com>
…en if you have 2 or more of the same type (#4579) * refactor(artifacts): partially reverting #4397 * refactor(artifacts): reverted #4489 * refactor(artifacts): reverted #4526 * test(artifacts): added test when parent pipeline does not provide expected artifacts * test(artifacts): resolve artifacts for default and prior artifacts --------- Co-authored-by: Cameron Motevasselani <cmotevasselani@gmail.com> (cherry picked from commit 645059d) # Conflicts: # orca-core/src/test/groovy/com/netflix/spinnaker/orca/pipeline/util/ArtifactUtilsSpec.groovy
…en if you have 2 or more of the same type (#4579) * refactor(artifacts): partially reverting #4397 * refactor(artifacts): reverted #4489 * refactor(artifacts): reverted #4526 * test(artifacts): added test when parent pipeline does not provide expected artifacts * test(artifacts): resolve artifacts for default and prior artifacts --------- Co-authored-by: Cameron Motevasselani <cmotevasselani@gmail.com> (cherry picked from commit 645059d) # Conflicts: # orca-core/src/test/groovy/com/netflix/spinnaker/orca/pipeline/util/ArtifactUtilsSpec.groovy
…en if you have 2 or more of the same type (#4579) * refactor(artifacts): partially reverting #4397 * refactor(artifacts): reverted #4489 * refactor(artifacts): reverted #4526 * test(artifacts): added test when parent pipeline does not provide expected artifacts * test(artifacts): resolve artifacts for default and prior artifacts --------- Co-authored-by: Cameron Motevasselani <cmotevasselani@gmail.com> (cherry picked from commit 645059d) # Conflicts: # orca-core/src/test/groovy/com/netflix/spinnaker/orca/pipeline/util/ArtifactUtilsSpec.groovy
…en if you have 2 or more of the same type (backport #4579) (#4587) * fix(artifacts): Automated triggers with artifact constraints are broken if you have 2 or more of the same type (#4579) * refactor(artifacts): partially reverting #4397 * refactor(artifacts): reverted #4489 * refactor(artifacts): reverted #4526 * test(artifacts): added test when parent pipeline does not provide expected artifacts * test(artifacts): resolve artifacts for default and prior artifacts --------- Co-authored-by: Cameron Motevasselani <cmotevasselani@gmail.com> (cherry picked from commit 645059d) # Conflicts: # orca-core/src/test/groovy/com/netflix/spinnaker/orca/pipeline/util/ArtifactUtilsSpec.groovy * fix(artifacts): resolving git conflicts from #4579 for release-1.31.x (#4590) --------- Co-authored-by: Nemesis Osorio <nemesis211_6@hotmail.com>
spinnaker#4575) (spinnaker#4581) Co-authored-by: Benevolent Benjamin Powell <benjamin_j_powell@apple.com> Co-authored-by: xibz <impactbchang@gmail.com> fix allows us to revert spinnaker#4397
It is currently hard/impossible to resolve artifacts in pipelines that doesn't have any triggers defined by themselves, and are triggered by a pipeline stage in another pipeline. Previously it was possible to get it to work by editing the json of the pipeline or in the UI by adding artifacts in a temp trigger and then removing it (this would keep the expected artifacts around). When I introduced trigger specific artifact constraints in #4322, I made it a lot harder (if not impossible) to do this because no triggers are used and thus all expected artifacts are filtered out.
This PR will fix this by copying expected artifacts from the parent execution (only if triggered by a pipeline stage), thus avoiding the whole situation altogether. It will also not filter away any expected artifacts where
useDefaultArtifact
orusePriorArtifact
is set totrue
, and it will bind artifacts defined inline in stages (so that you can match artifacts using regex and not only SpEL).