gen-csv should find out the latest CSV version

[aliok]

Feature Request

Is your feature request related to a problem? Please describe.

Assume this tree:

$ tree deploy/
deploy/
└── olm-catalog
    └── knative-eventing-operator
        ├── 0.9.0
        │   ├── 300-eventing-v1alpha1-knativeeventing-crd.yaml
        │   └── knative-eventing-operator.v0.9.0.clusterserviceversion.yaml
        ├── 0.10.0
        │   ├── eventing_v1alpha1_knativeeventing_crd.yaml
        │   └── knative-eventing-operator.v0.10.0.clusterserviceversion.yaml
        └── knative-eventing-operator.package.yaml

and assume I want to generate the CSV for version 0.11.0.

Currently I have to do this:

operator-sdk olm-catalog gen-csv            \
  --from-version  0.10.0                    \
  --csv-version   0.11.0                    \
  [...]

I have to find out the from-version myself and feed it to operator-sdk olm-catalog gen-csv, which is not easy (details at the bottom).

Describe the solution you'd like

I would like to have a call like this:

operator-sdk olm-catalog gen-csv            \
  --from-latest-version                     \
  --csv-version   0.11.0                    \
  [...]

and operator-sdk should figure out the --from-version for me.

--from-latest-version (just made it up) is the important thing here! I suggest creating a flag like that.

Outcome would be:

$ tree deploy/
deploy/
└── olm-catalog
    └── knative-eventing-operator
        ├── 0.9.0
        │   ├── 300-eventing-v1alpha1-knativeeventing-crd.yaml
        │   └── knative-eventing-operator.v0.9.0.clusterserviceversion.yaml
        ├── 0.10.0
        │   ├── eventing_v1alpha1_knativeeventing_crd.yaml
        │   └── knative-eventing-operator.v0.10.0.clusterserviceversion.yaml
        ├── 0.11.0
        │   ├── eventing_v1alpha1_knativeeventing_crd.yaml
        │   └── knative-eventing-operator.v0.11.0.clusterserviceversion.yaml
        └── knative-eventing-operator.package.yaml

Additional info
In our project, we want to call gen-csv subcommand with a Bash script.
However, finding out the previous version and passing it as --from-version is hard with Bash. That is because of semver complexities. For example, 0.10.0 is a greater version than 0.9.0, but not when you simply sort nested directory names. So, alphabetic sorting won't work.

However, if the CLI would do that for me, that would be great! CLI could simply use https://github.com/coreos/go-semver.

[aliok]

cc @camilamacedo86

[camilamacedo86]

I am not sure if I follow up properly the feature request here.

Would you like to run operator-sdk olm-catalog gen-csv and then it automatically set the from and the new version following up semver? Am I right?

I think finding out the new version is kind of easy with Bash scripts (we have a version.go file which can be read by the script).

The version.go is not necessarily the same version of CSV. Note that the tags of CSV not necessarily will be or follow up the project tags as well.

[aliok]

I am more interested in that cli sets from version automatically.

…

On Tue, Nov 26, 2019, 3:28 PM Camila Macedo ***@***.***> wrote: I am not sure if I follow up properly the feature request here. Would you like to run operator-sdk olm-catalog gen-csv and then it automatically set the from and the new version following up semver? Am I right? I think finding out the new version is kind of easy with Bash scripts (we have a version.go file which can be read by the script). The version.go is not necessarily the same version of CSV. Note that the tags of CSV not necessarily will be or follow up the project tags as well. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2267?email_source=notifications&email_token=AAC37HHCIA75FQKUNZDUKYDQVUI5NA5CNFSM4JRP2OE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFF2U6Q#issuecomment-558606970>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC37HE3HEOTLYCPK6XLORTQVUI5NANCNFSM4JRP2OEQ> .

[camilamacedo86]

Sorry, it still not clear for me. Could you please exemplify as for example?

• For the example in the first comment of this issue; I'd like to run the command x
• Then, I would expect the result y.(e.g the files x,y, z updated with the new version)

[aliok]

Ok, will do that when I get home

…

On Tue, Nov 26, 2019, 3:35 PM Camila Macedo ***@***.***> wrote: It still not clear for me. Could you please exemplify as for example? - For the example in the first comment of this issue; I'd like to run the command x - Then, I would expect the result X. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2267?email_source=notifications&email_token=AAC37HF4A6JT3XERENG4SD3QVUJ2TA5CNFSM4JRP2OE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFF3HTI#issuecomment-558609357>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC37HGQFZBIP2EDYCP5ZE3QVUJ2TANCNFSM4JRP2OEQ> .

[aliok]

@camilamacedo86 Updated the issue description. Let me know if you need further clarification.

[camilamacedo86]

Hi @aliok,

Yes, it is clear enough now. Really thank you for the clarifications.
It needs to be discussed, then I will label it. Also, feel free to collab with a PR if you think that you could easily provide the solution as well.

[aliok]

Also, feel free to collab with a PR if you think that you could easily provide the solution as well.

I was planning to give it a try already :)

[camilamacedo86]

Hi @joelanford, @hasbro17 and @estroz,

WDYT? It shows reasonable for me but low priority. It would be adding new flag as for example --from-latest-version to the operator-sdk olm-catalog gen-csv command which would automatically identify the latest tag used for the CSV.

[estroz]

@aliok you can sort by semantic version with GNU sort:

$ echo -e "0.1.0\n0.2.0\n3.0.0\n0.0.5\n0.0.12" | sort -V
0.0.5
0.0.12
0.1.0
0.2.0
3.0.0

You can do something like:

$ find deploy/olm-catalog/operator-name/* -maxdepth 1 -type d -exec basename {} \; | sort -V | tail -1

to get the latest version. Does that solve your issue?

[aliok]

hi @estroz
thanks, it does actually.

I would still prefer the hypothetical --from-latest-version though :)
Let me know what you guys think and I can send a PR for that.

[estroz]

@aliok sounds good. I'll let a few others comment on this, and if we find its a feature we want in operator-sdk then you can spend time on the PR.

One goal of the SDK is to have a low-complexity CLI, so we strive to keep the number of flags to a minimum, especially when there are 1-2 line bash wrappers that give you the same functionality of 10+ lines of Go code. This is the main reason why I hesitate to ok this right now, not that it isn't a useful feature.

[camilamacedo86]

Hi @aliok,

After @estroz solution in #2267 (comment) it shows that could be solved by creating a Makefile target with.

In this way, it is the same scenario of #1600 (comment) and then, I am afraid that we should NOT move forward with. As an example of a similar scenario that was decided not to move forward was well see #1964 (comment).

So, I am closing this one since a solution was already provided and it can be done by customizations in the Makefile. However, please, feel free to re-open if you think that it still required.

c/c @estroz