feat(cli): Init CLI to create arbitrary upgrade-prs

[zkdev]

Not sure about the standalone CLI.
We might offer a cicd-cli v2 without Concourse dependencies via a lightweight python distribution package on PyPi.
Open for suggestions here 🙂

Release note:

NONE

[ccwienk]

CLIs we have as part of our actions thus-far were crafted with the intention to test to action's code itself, and typically reuse the action. It might be considered to deviate from this pattern. However, in this case, I think it is not a good fit.

Also, it mixes different aspects:

• retrieve a repository
• create diff for OCM-Upgrade
• create pullrequest

the first part is IMO not relevant for local uses: If pipeline should not be used, it is to be expected users will already have a copy of the git-repository that should receive a pullrequest. Typically, authentication is also already setup.

As for the publishing-part, that can also be handled by gh-cli (making this CLI overlapping w/ GH-CLI).

Hence, I would suggest to consider dropping the first and latter parts, and keep the middle one: create diff for OCM-Upgrade.

However, I think this also should be split:

• CLI-command for printing effective component-descriptor (with GHA as we by now have them, this will likely only work for a subset, as we cannot easily cover dynamic modifications); something along the lines of what base-component-descriptor-action does (something like [python -m] ocm base-component-descriptor (maybe we should consider to create a new package, such as gardener_gha, or a new sub-command, like ocm gardener (that one already exists as a module), or ocm gha))
• CLI-command for discovering available upgrade-vectors:
• given a (base-)component-descriptor + at least one OCM-Repository, this command shall determine greater component-versions, and print them (in a way that is easy to parse..)
• CLI-Command for creating upgrade-diff for a given upgrade-vector

All of those commands can either work fully on local git-repository, or will work (authentication-wise) by reading from local user's docker-cfg.

[ccwienk]

If this CLI is intended for local usage, I think including the code to retrieve the repository is not a good fit.

This makes the underlying operation more expensive, and at the same time makes it less convenient to use (as users have to provide an access-token).

In addition, this partially overlaps w/ gh-CLI.

[gardener-robot]

@8R0WNI3, @TuanAnh17N You have pull request review open invite, please check

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:

• After 30d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 14d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as active with /lifecycle active
• Mark this PR as fresh with /remove-lifecycle stale
• Mark this PR as rotten with /lifecycle rotten
• Close this PR with /close

/lifecycle stale

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:

• After 30d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 14d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as active with /lifecycle active
• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close

/lifecycle rotten