feat(cmd): kamel promote --push-gitops-dir

[michalvavrik]

closes: #6137

Changes:

• introduce --push-gitops-dir flag which tells the promote command to commit the base overlay to the gitops export dir, push it to the origin remote and open new GitHub PR

How I tested that the feature opens GitHub PR:

1. used GH CLI to authentication and get token
2. set GITHUB_TOKEN
3. created directory with git repository that cloned https://github.com/michalvavrik/camel-k-gitops-pr-creation-test
4. run the promote command (frankly I tweaked test to create the command for me and used the test to run it)
5. result:

• for git@github.com:michalvavrik/camel-k-gitops-pr-creation-test.git I got:
  • chore: add GitOps base overlay for "my-pipe-test" Pipe michalvavrik/camel-k-gitops-pr-creation-test#5
  • chore: update GitOps base overlay for "my-pipe-test" Pipe michalvavrik/camel-k-gitops-pr-creation-test#6
• for https://github.com/michalvavrik/camel-k-gitops-pr-creation-test.git I got:
  • chore: add GitOps base overlay for "my-pipe-test" Pipe michalvavrik/camel-k-gitops-pr-creation-test#7
  • chore: update GitOps base overlay for "my-pipe-test" Pipe michalvavrik/camel-k-gitops-pr-creation-test#8

Release Note

NONE

[michalvavrik]

\cc @squakez

[squakez]

Nice. I will have a look ASAP. Yesterday I started the release 2.8.0 process, I thought this feature was going to take longer. Is it okey if we slip this one into 2.9?

[github-actions]

✔️ Unit test coverage report - coverage increased from 51.1% to 51.3% (+0.2%)

[michalvavrik]

Nice. I will have a look ASAP. Yesterday I started the release 2.8.0 process, I thought this feature was going to take longer. Is it okey if we slip this one into 2.9?

2.9 is fine. Thanks

[squakez]

First of all, thanks for taking the time to work on this. Having this feature on the CLI is surely useful but it will be quite limited to whichever is the workflow of the user. I think I missed to provide a bit more of design context around the potential feature.

Originally I was thinking to have the Git PR on the operator side, not on the CLI as an additional step after the Integration was built (and executed). In fact, this feature makes sense when the user is building directly from GIT, in order to provide the source repository where the operator would close the cycle after performing a build and a container push to the registry.

In summary the use case could be like this:

• User creates an Integration with a git repository (ie, kamel run --git).
• The operator performs the build and push the container to the registry as it happens normally
• The operator creates a structure overlay reusing the same code we have in kamel promote --export-gitops-dir. It could save the files in some /cicd/ directory for example.
• The operator add and commit such cicd folder and creates a PR towards the same git repository/branch.

I expect this workflow to decouple the build part (on the operator side) from the promoting part (which could be performed by some CICD tool instead). Imagine an argoCD pipeline listening on the given repository in the proper Integration folder. Once the user merge the PR, the pipeline will take care to release in the upper environment.

Hope it makes sense.

[michalvavrik]

I'll implement what you instead of this promote --push-gitops-dir. I can see that the issue description says the operator creates a PR with something like a base overlay.

[squakez]

I'll implement what you instead of this promote --push-gitops-dir. I can see that the issue description says the operator creates a PR with something like a base overlay.

Thanks. Feel free to ask if you have any doubt or you hit some blocker.