An example showing what it would be like to have the aiedge-e2e pipeline duplicate all of the gitops update pipeline tasks

grdryn commented 2 months ago

JIRA: https://issues.redhat.com/browse/RHOAIENG-4982

Description

This shows what it would be like to have the aiedge-e2e pipeline also include all of the tasks from the gitops update pipeline.

There are advantages and disadvantages to this approach:

Advantages:

Compared to the EventListener/Trigger approach, no Tekton EventListener pod needs to be running all the time.

Disadvantages:

The aiedge-e2e pipeline becomes significantly more complex, and it now needs to know how to do everything that the gitops update pipeline knows how to do.
If we change anything in the gitops update pipeline, we need to remember to also update that in this pipeline.
Making it optional (for example, for users who don't us a forge that implements the GitHub PR API) would require a 10th additional parameter

How Has This Been Tested?

Minimally. If this is the chosen path, I'll spend more time on it

Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work

openshift-ci[bot] commented 2 months ago

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

openshift-ci[bot] commented 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.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/opendatahub-io/ai-edge/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

adelton commented 2 months ago

Would we be able to simplify the code by defining the most complex tasks as kind: Task and then just refer to them from both Pipelines?

As for making things optional, could we use somethings like optional gitops-git-server or gitops-git-token-secret-name to skip the parts of the Pipeline that the user might not want to run?

adelton commented 2 months ago

@MarianMacik Would we be able to do CI for both the e2e and the original Pipeline? Perhaps have the e2e create PR to one git branch (like qe) and then have another pipeline to duplicate that SHA256 in another git branch (like stage, or prod) ...

grdryn commented 2 months ago

Would we be able to simplify the code by defining the most complex tasks as kind: Task and then just refer to them from both Pipelines?

That's already how this works: it expects the gitops-update-pipeline/tasks to be rolled out, and both pipelines refer to those (and shared ClusterTasks).

As for making things optional, could we use somethings like optional gitops-git-server or gitops-git-token-secret-name to skip the parts of the Pipeline that the user might not want to run?

Yeah the new tasks here could easily be skipped by checking for existence of a value on one or more of the needed parameters.

MarianMacik commented 2 months ago

@MarianMacik Would we be able to do CI for both the e2e and the original Pipeline? Perhaps have the e2e create PR to one git branch (like qe) and then have another pipeline to duplicate that SHA256 in another git branch (like stage, or prod) ...

@adelton Sorry, I have just noticed your comment. Yes, that could be done, of course.

opendatahub-io / ai-edge