feat: version lock/update of variant module

[mumoshu]

b9f9c89 introduced version locking for files and binaries managed by a variant module.

For example, coreos variant module can be used to fetch the latest version number of coreos stable release channel and save it in variant.lock. The version number can be used for templating files and other useful things. Running mod up command re-fetches the version number and updates variant.lock.

However there's no way to update coreos variant module itself. This issue is to track the progress towards widening the version locking feature to support variant modules as well.

Perhaps this can be used only when a variant module is sourced from a git repo.

Assume you currently have a variant.mod like:

modules:
- source: github.com/variantdev/modules//coreos@variant.mod?ref=v1.0.0

Obviously v1.0.0 is a fixed value that can't be updated automatically.

Alter this to:

modules:
- source: github.com/variantdev/modules//coreos@variant.mod
  version: >= 1.0.0

On first mod up run, it fetches all the tags and branches in the github.com/variantdev/modules repositories and build a list of semantic versions.

It then uses the version range version: >= 1.0.0 to filter semantic versions larger than or equal to 1.0.0 and chooses the largest version number to be saved to variant.lock.

[mumoshu]

This requires fetching list of git tags and determining the latest acceptable tag according to a semver range.

Fortunately, awesome folks at gruntwork has shared the exact functionality in their fetch:

https://github.com/gruntwork-io/fetch/blob/cb1f57e9b83db45ff702d2a3b67cc8e1d3e09853/tag.go#L29

[mumoshu]

Maybe we'd need to make distinction between the version number of the module itself and the version number of the app dep-managed by the module.

In the below example, moduleVersion should be used to update thegithub.com/variantdev/modules//coreos module, whereas version is used to update the coreos version managed by it:

dependencies:
- source: github.com/variantdev/modules//coreos@variant.mod
  version: >= 1.0.0
  moduleVersion: >= 1.0.0

[mumoshu]

Otherwise should we differentiate dependencies and module dependencies?

modules:
- source: github.com/variantdev/modules//coreos@variant.mod
  version: >= 1.0.0 #=moduleVersion in the above example

dependencies:
  coreos:
    version: >= 1.0.0 # coreos version range, where the coreos dependency is provided and managed by the coreos module above

[mumoshu]

In my mental model, this:

modules:
- source: github.com/variantdev/modules//coreos
  version: >= 1.0.0 #=moduleVersion in the above example

dependencies:
  coreos:
    version: >= 1.0.0 # coreos version range, where the coreos dependency is provided and managed by the coreos module above

which equals to:

modules:
- source: github.com/variantdev/modules//coreos@variant.mod
  version: >= 1.0.0 #=moduleVersion in the above example

dependencies:
  coreos:
    version: >= 1.0.0 # coreos version range, where the coreos dependency is provided and managed by the coreos module above

can be equivalent or a syntax sugar to:

releaseChannels:
- name: coreosModule
  versionsFrom:
    githubReleases:
        source: variantdev/mod/modules/coreos

directories:
- source: "github.com/variantdev/modules//coreos?ref={{.releases.coreosModule.version}}"

modules:
- source: .variant/cache/CACHE_KEY_TO_COREOS_MODULE/variant.mod

dependencies:
  coreosModule:
    version: >= 1.0.0 #=moduleVersion in the above example
  coreos:
    version: >= 1.0.0 # coreos version range, where the coreos dependency is provided and managed by the coreos module above

[mumoshu]

Modules can be considered as module dependencies. If we make it a YAML dict, each key can be used as a ID of a non-module dependency:

# Or moduleDependencies
modules:
  coreos:
    source: github.com/variantdev/modules//coreos
    version: >= 1.0.0 #=moduleVersion in the above example

# A.k.a "releaseDependencies", former "dependencies"
releases:
  coreos:
    version: >= 1.0.0 # coreos version range, where the coreos dependency is provided and managed by the coreos module above

[mumoshu]

Should we move two types of dependencies under the same top-level key like dependencies?

dependencies:
  modules:
    coreos:
      source: github.com/variantdev/modules//coreos
      version: >= 1.0.0 #=moduleVersion in the above example
      versionsFrom:
          githubReleases:
              source: variantdev/mod/modules/coreos
  releases:
    coreos:
      version: >= 1.0.0 # coreos version range, where the coreos dependency is provided and managed by the coreos module above