Closed grdryn closed 2 months ago
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please ask for approval from grdryn. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Currently an additional trigger (and possibly additional EventListener, although interceptors might be able to ensure only the appropriate trigger(s) is/are fired on a single EventListener) is needed for each different model image and/or GitOps repo.
I don't think it is needed for each different model image because model image is directly in the image-registry-repo
parameter, isn't it?
Also, GitOps repository can be parameterized as well, right?
In case a user has some internal organization for different GitOps repositories, they only need to change image registry, digest and GitOps repo URL. Or if everything is in one repository, then the yq-script
must be changed accordingly.
Currently an additional trigger (and possibly additional EventListener, although interceptors might be able to ensure only the appropriate trigger(s) is/are fired on a single EventListener) is needed for each different model image and/or GitOps repo.
I don't think it is needed for each different model image because model image is directly in the
image-registry-repo
parameter, isn't it? Also, GitOps repository can be parameterized as well, right? In case a user has some internal organization for different GitOps repositories, they only need to change image registry, digest and GitOps repo URL. Or if everything is in one repository, then theyq-script
must be changed accordingly.
If anything other than the image-registry-repo
and image-digest
parameters need different values for different models and/or GitOps repos (and I expect that they typically will), then a different trigger should be used. I think that's a cleaner approach than having the (already quite cumbersome) aiedge-e2e pipeline needing to know all of the extra parameters for the GitOps Update pipeline.
If anything other than the
image-registry-repo
andimage-digest
parameters need different values for different models and/or GitOps repos (and I expect that they typically will), then a different trigger should be used. I think that's a cleaner approach than having the (already quite cumbersome) aiedge-e2e pipeline needing to know all of the extra parameters for the GitOps Update pipeline.
I see, so these extra parameters would be hard-coded in the trigger template so the aiedge-e2e pipeline doesn't need to have these at the start.
JIRA: https://issues.redhat.com/browse/RHOAIENG-4982
This commit is stacked upon #267, and will show the changes from that PR until it's merged. This is one approach that could be taken–I'll open a separate PR with an alternative approach.
Description
This example shows how users can choose to optionally trigger the GitOps Update pipeline at the end of a successful run of the MLOps build pipeline.
Advantages of this approach
Disadvantages of this approach
How Has This Been Tested?
gitops-update-pipeline-eventlistener-url
param, and verified that the optional task to call the EventListener was skippedgitops-update-pipeline-eventlistener-url
param, and verified that the new optional task was executed, and the GitOps Update pipeline was triggered and completed successfully.Merge criteria: