Add version pattern for Github Source and correctly handle github tags

[olblak]

Fix #175
Fix #182

Add a new parameter versiontype which allows defining the kind of version we are fetching.
this new parameter accepts one of the two following values "semver" or "text". Default is set to semver
The parameter github.version can handle version pattern as explained in the following example

semver
If semver is used then it means we are looking for a version following the semantic versioning rules. we can provide a version pattern in the Github version and any rule explained here here can be used.
It's important to notice that in the process we drop any character not compliant with the semantic versioning like if a version starts with v, so this value must be added using transformers like in the example

text
If text is specified we can apply a simple string pattern where Github version will match the latest version returned by Github starting with the pattern

source:
  kind: githubRelease
  spec:
    owner: "jenkins-infra"
    repository: "jenkins-wiki-exporter"
    token: "{{ requiredEnv .github.token }}" 
    username: "john"
    #version: "latest"
    version: "~1.10"
    #version: "~9.10"
    #version: "v1.10"
    #versiontype: string
  transformers:
    - addPrefix: "v"

Add a new optional Github parameter "constraint".
"Constraint" can specify version constraint as explained

Signed-off-by: Olivier Vernin olivier@vernin.me

[dduportal]

Great job 👏 This will be really useful!

As per our discussion, WDYT about the following:

• Name change from versioning to filter / versionFilter, (or something like this) to express the intent of "filter the retrieved versions based on a given rule"
  ** 2 attributes for this key: kind and pattern for instance
• Add a new kind of "filter" named latest to handle the current case (when the attribute version is set to latest). Not only for backward compatibility, but also to provide this filter as a feature, to run efficiently (avoid retrieving a bunch of releases from the GitHub API while you want only 1)
• Name change from kind: text to kind: regex, after removing the latest case. The intent would be clear to the user that a regex is needed (and that the regex engine is loaded in this particular case)
• Make the attribute kind mandatory (instead of defaulting to semver), to ensure that the user chooses an explicit one (instead of guessing, which defeats the goal of semver)
• Limit the "fallback to tag" behavior as much as possible: this would be a case for a new kind of source: gitTag

Examples:

source:
  kind: githubRelease
  spec:
    owner: "jenkins-infra"
    repository: "jenkins-wiki-exporter"
    token: "{{ requiredEnv .github.token }}" 
    username: "john"
    versionFilter:
      kind: semVer
      pattern: '~1.10'
  transformers:
    - addPrefix: "v"
####
# => Return `v1.11.1` for instance

source:
  kind: githubRelease
  spec:
    owner: "kubernetes"
    repository: "kubectl"
    token: "{{ requiredEnv .github.token }}" 
    username: "john"
    versionFilter:
      kind: regex
      pattern: 'kubernetes-1.(\d*).(\d*)$'
####
# => Return `kubernetes-1.20` for instance

source:
  kind: githubRelease
  spec:
    owner: "hashicorp"
    repository: "terraform"
    token: "{{ requiredEnv .github.token }}" 
    username: "john"
    versionFilter:
      kind: regex
      pattern: 'v0.12.(\d*)'
####
# => Return `v0.12.30` for instance

[olblak]

Thanks for the feedback and I'll consider them but I am just pushing back for the following suggestions

Make the attribute kind mandatory (instead of defaulting to semver), to ensure that the user chooses an explicit one (instead of guessing, which defeats the goal of semver)
Instead of putting that field "mandatory", I prefer to default to "latest" as it the current situation. So we don't break the previous updatecli configurations. I'll provide some examples in the documentation so it's obvious when to use alternatives.

Name change from versioning to filter / versionFilter, (or something like this) to express the intent of "filter the retrieved versions based on a given rule"
** 2 attributes for this key: kind and pattern for instance
I definitely prefer "filter" as it's shorter, I'll adapt the PR

Also, version and filter.pattern are redundant because the version is a parameter specific to the "githubRelease" resource while filter.pattern is specific to the filter rule which will be reused from other components that manipulates list of versions like the "maven" resource so my plan is just to show a warning if filter.pattern is defined and mismatch version otherwise it fallback to the version value. Another approach would be to deprecate the parameter version. Version is already used while filter is introduced in the coming release

[dduportal]

• Deprecating version sounds a clean and nice idea
• WDYT about versionFilter instead of filter ? It avoids collision with other features and is quite clear about the intention