Feature request: Allow version value to be set by an environmental variable

[RoyWarps]

We have a peculiar use case, which we resolved by producing our own gem for now. But it could be useful in the official GVB.
In order to test our tool it is ran inside another repository. Typically GVB would then be use in such a way that it would retrieve the version from the gemspec. However as the tool is being tested it is not yet published and as such there is no .gemspec to retrieve a value from.
This causes a fallback to the version value of the local git repo which is not of the tool itself and thus results in a invalid version value.
We solved kinda quick and dirty by setting an environment variable GVB_NO_GEMSPEC_NO_GIT with a test version value.
If GVB finds the environment variable GVB_NO_GEMSPEC_NO_GIT with a value other than false its value is returned as the version.
If the environment variable GVB_NO_GEMSPEC_NO_GIT is not found or its value is false GVB will opperate normally.

	def self.version(use_local_dir=false, include_lite_tags=false)
		return ENV['GVB_NO_GEMSPEC_NO_GIT'] if ENV.key?('GVB_NO_GEMSPEC_NO_GIT') and !ENV['GVB_NO_GEMSPEC_NO_GIT'].eql?('false')
		if use_local_dir
			repo_version(true, include_lite_tags)
		else
			gem_version || repo_version(false, include_lite_tags)
		end
	end

The value false is necessary as Jenkins has the limitation that stages can only override environment variables not define additional ones. That unfortunately made the solution somewhat less pretty as it now has to perform multiple checks

[mpalmer]

Interestingly, I've had a need to override the version using an env var before -- although in my case, I still had a gemspec, so I could do version = ENV.fetch("GVB_VERSION_OVERRIDE", GVB.version). But I'm not against the idea of embedding that behaviour into GVB itself if we can figure out a sensible approach.

First up -- can you set an env var with an empty value by default in Jenkins, and then override that in a later stage? I'd prefer if the "don't actually do the overriding" value was something that could not possibly be a version (such as the empty string), rather than run the (infinitesimally small) risk that someone out there, one day, would want to actually set the version to the string false.

Second, I worry about the chance that multiple GVB-using packages in the same process would all pick up this env var override and potentially cause Confusion and Delay. Are you open to some other mechanism for overriding the version? I'm thinking that setting a config value in the git repo that you're running from could be a potential solution for your particular case. Thus, the lookup logic would be something like:

1. Check if we're running in a gem, and if so, use the version in the corresponding gemspec.
2. Check if we're running in a git repo. If not, assplode.
3. Check if the local git repo has a (local) variable set, say version-bump.version_override, and if so, use that value as the version.
4. Try and derive the version number from the tags in the git repo. If that works, return that version.
5. If all else fails, fall back to assploding.

I can't see any obvious problems with that logic -- it's backwards-compatible (nothing changes if the config isn't set), it's compatible with CI, and doesn't have the "duelling GVBs" problem, unless you're running multiple things outside of a gem (in which case, you'd be having bigger problems now, anyway).

Would this work for you?

[RoyWarps]

I do also prefer to not set, or set an empty environment variable instead of making the checking logic so muddy.
Unfortunately this is not the first time some one has ran into this environment variable issue in Jenkins https://issues.jenkins.io/browse/JENKINS-43632
I don't expect Jenkins to support empty environment variables any time soon. The empty space workaround is also not great, though it does allow you rule out the possibility of some one using "false" for a version. Of course in the source that would look really questionable to do a .strip.empty? check on a ENV value.

Indeed my suggested approach could have multiple GVB picking up the environment variable and reporting the same version value. Though that would not be an issue while running integration tests.
This environment variable is obviously only indented for testing purposes. Granted that does have a bit of a smell.
For the building/packaging stage I indeed had to set it to false to restore the original GVB behavior.
Having revisited the problem I also noted a potential security issue in that approach. One could thru the environment variables potentially spoof a version or possibly execute some code, if the gem implementing GVB has another flaw where it would interpret the version value.

I am not tied to any particular solution direction my suggestion is just what I came up with to quickly solve the problem I was having. Not sure how a git config value could be used. But that does sound like a more robust solution to the problem. One that is much less likely to cause mishaps or be abused.

[mpalmer]

This environment variable is obviously only indented for testing purposes.

Unfortunately, what one intends a feature to be used for, and what someone who just glances at the docs will use a feature for, are quite different things.

Given that you don't seem to be against a git config variable, I'll whip that up and see whether it fits your needs in practice. Will be sometime next week at the earliest.

[mpalmer]

OK, this is done -- it's next to a week, after all... 😁 If you're able to give that a whirl in your environment and let me know that it works for you, I'll cut a new release.

[RoyWarps]

OK, this is done -- it's next to a week, after all... 😁 If you're able to give that a whirl in your environment and let me know that it works for you, I'll cut a new release.

I would need to find some time to do so.
Probably wont be to soon I am afraid.

[mpalmer]

Totally understand. I might just cut a release anyway, then, as it shouldn't get in the way of anyone who doesn't want to use it.