Support monorepo release versions for plugins

[bharathkkb]

Introduction

We manage some of our TF tooling in a mono repo and would like to keep our custom plugin also in the mono repo. We follow a convention like pkg/vM.m.p when tagging releases (example: tflint-ruleset-foo/v0.1.0).

I tried to configure this like:

plugin "foo" {
    enabled = true
    version = "tflint-ruleset-foo/v0.1.0"
    source  = "github.com/org/monorepo"
}

However it seems like this does not working when installing plugins via tflint --init when as a "v" is prepended to resolve the tag name.

Proposal

One approach could be skipping the prepend of v if a semver with version is explicitly specified like version = "tflint-ruleset-foo/v0.1.0". Alternatively we could support an additional tag attrib like tag = "tflint-ruleset-foo/v0.1.0".

References

[wata727]

Personally, I support adding the tag as a optional attribute. The logic for deciding whether to add v to the beginning of the version attribute is non-trivial, so there is a concern that it will become too complex.

However, if the tag attribute is introduced, the role of the version attribute will almost disappear, so I'm concerned that this will lead to unintuitive behavior for users. I think there is room for consideration on this point.

[bharathkkb]

Thank you @wata727!

Personally, I support adding the tag as a optional attribute. The logic for deciding whether to add v to the beginning of the version attribute is non-trivial, so there is a concern that it will become too complex.

I agree it might be non trivial but my naive approach was check if semver format if yes without v, prefix v. Everything else pass as is.

However, if the tag attribute is introduced, the role of the version attribute will almost disappear, so I'm concerned that this will lead to unintuitive behavior for users. I think there is room for consideration on this point.

I think version would still be useful incase tflint had plans of introducing something like #1181

[wata727]

my naive approach was check if semver format if yes without v, prefix v. Everything else pass as is.

Yeah, but semver's format determination is actually quite complicated.
https://github.com/hashicorp/go-version/blob/644291d14038339745c2d883a1a114488e30b702/version.go#L26-L30
For these reasons, I recommended adding the tag attribute.

I think version would still be useful incase tflint had plans of introducing something like #1181

Makes sense. I don't know yet whether version constraints are really necessary, but I agree that there is room for such expansion.

[wata727]

See also this discussion: #2005

How to extend the syntax is debatable. Simply adding the attribute will look like this:

plugin "foo" {
    enabled = true
    version = "0.1.0"
    source  = "github.com/org/monorepo"
    tag     = "tflint-ruleset-foo/v0.1.0"
}

However, the GitHub release tag name is associated with the "source" attribute, so we might have an idea to structure it like this:

plugin "foo" {
    enabled = true
    version = "0.1.0"

    source {
        url = "github.com/org/monorepo"
        tag = "tflint-ruleset-foo/v0.1.0"
    }
}

Or maybe we should introduce a github block in case we support another plugin sources in the future #1202:

plugin "foo" {
    enabled = true
    version = "0.1.0"
    source  = "github.com/org/monorepo"

    github {
        tag = "tflint-ruleset-foo/v0.1.0"
    }
}

We should also be aware that top-level attributes and block names in the plugin blocks may conflict with names already used by the plugins (this issue will be resolved in #1953)