~ in version string breaks git caching

[jessereynolds]

If you have a tilde character (~) in the package version string, the package builds fine but omnibus blows up when trying to cache the build in git, because ~ is not allowed in a git tag.

We are wanting to use tilde specifically in release candidate versions so that they sort earlier than the final release. Eg in Debian packages '1.0.0~rc3' sorts earlier than '1.0.0', whereas '1.0.0rc3' sorts later than '1.0.0'. If you have a release candidate version of 1.0.0 installed, you want to be able to install the 1.0.0 final when it's available. See the debian policy manual.

Would a PR be accepted that removes any ~ chars from candidate tag names before creating and using in git? (Or that replaces them with some other character?)

git --git-dir=/var/cache/omnibus/cache/install_path/opt/flapjack \
  --work-tree=/opt/flapjack tag -f \
  "flapjack-1.0.0~rc3~20140727T125000-9b1e831-1-d21c5f83ca481acd784f15b0429044339e88d6b59918af056029f825766e8ee1"

fatal: 'flapjack-1.0.0~rc3~20140727T125000-9b1e831-1-d21c5f83ca481acd784f15b0429044339e88d6b59918af056029f825766e8ee1' 
  is not a valid tag name.

more output:

      [Builder: flapjack] I | Build succeeded! (215.66244961s)
     [Software: flapjack] I | Caching build
                          I | $ git --git-dir=/var/cache/omnibus/cache/install_path/opt/flapjack --work-tree=/opt/flapjack add -A -f
                          I | $ git --git-dir=/var/cache/omnibus/cache/install_path/opt/flapjack --work-tree=/opt/flapjack commit -q -m "Backup of flapjack-1.0.0~rc3~20140727T125000-9b1e831-1-d21c5f83ca481acd784f15b0429044339e88d6b59918af056029f825766e8ee1"
                          I | $ git --git-dir=/var/cache/omnibus/cache/install_path/opt/flapjack --work-tree=/opt/flapjack tag -f "flapjack-1.0.0~rc3~20140727T125000-9b1e831-1-d21c5f83ca481acd784f15b0429044339e88d6b59918af056029f825766e8ee1"
/var/lib/gems/1.9.1/gems/mixlib-shellout-1.4.0/lib/mixlib/shellout.rb:257:in `invalid!': Expected process to exit with [0], but received '128' (Mixlib::ShellOut::ShellCommandFailed)
---- Begin output of git --git-dir=/var/cache/omnibus/cache/install_path/opt/flapjack --work-tree=/opt/flapjack tag -f "flapjack-1.0.0~rc3~20140727T125000-9b1e831-1-d21c5f83ca481acd784f15b0429044339e88d6b59918af056029f825766e8ee1" ----
STDOUT:
STDERR: fatal: 'flapjack-1.0.0~rc3~20140727T125000-9b1e831-1-d21c5f83ca481acd784f15b0429044339e88d6b59918af056029f825766e8ee1' is not a valid tag name.
---- End output of git --git-dir=/var/cache/omnibus/cache/install_path/opt/flapjack --work-tree=/opt/flapjack tag -f "flapjack-1.0.0~rc3~20140727T125000-9b1e831-1-d21c5f83ca481acd784f15b0429044339e88d6b59918af056029f825766e8ee1" ----
Ran git --git-dir=/var/cache/omnibus/cache/install_path/opt/flapjack --work-tree=/opt/flapjack tag -f "flapjack-1.0.0~rc3~20140727T125000-9b1e831-1-d21c5f83ca481acd784f15b0429044339e88d6b59918af056029f825766e8ee1" returned 128
    from /var/lib/gems/1.9.1/gems/mixlib-shellout-1.4.0/lib/mixlib/shellout.rb:244:in `error!'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/util.rb:77:in `shellout!'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/install_path_cache.rb:85:in `incremental'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/software.rb:623:in `execute_build'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/software.rb:451:in `build_me'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/project.rb:95:in `block in build_me'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/project.rb:94:in `each'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/project.rb:94:in `build_me'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/cli.rb:72:in `build'
    from /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    from /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    from /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/cli/base.rb:33:in `dispatch'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/cli/deprecated.rb:128:in `dispatch'
    from /var/lib/gems/1.9.1/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/lib/omnibus/cli.rb:41:in `execute!'
    from /var/lib/gems/1.9.1/bundler/gems/omnibus-ruby-5ad405c915e4/bin/omnibus:11:in `<top (required)>'
    from bin/omnibus:16:in `load'
    from bin/omnibus:16:in `<main>'

[sethvargo]

@jessereynolds I would much prefer a Pull Request that removes all invalid characters, rather than just ~. I realize this is the only problem in your scope, but this will likely come up again with a different character.

[sethvargo]

Alternatively, we could generate a SHA for the tag instead. So, build it the same, but then SHA that value and use it for the tag.

[sethvargo]

In either case, this will invalidate all existing git caches. That's fine, but something we will need to make note of in the release notes.

[seth]

The downside of putting the digest of the version into the tag is that human debugging of the cache becomes much harder. If we can convince ourselves that there is a reasonably small set of illegal characters, it might be worth going that route.

For my use, since I don't make funny version numbers, going to SHA for version in tag is a net loss.

[sethvargo]

@seth yup - @schisamo and I discussed that this morning. I think I would prefer something like:

tag = version.gsub(/[SOME_MAGICAL_REGEX_OF_VALID_CHARACTERS]+/, '-')

AKA, replace all "bad" version characters with a valid one, logging a debug or warn message when doing so.

[seth]

+1

[jessereynolds]

Great! I'll give that a shot.

[jessereynolds]

Hmmm, it seems I must have been running an older version of omnibus when I encountered the above error. With current master I cannot reproduce the error. The reason is that the tag is now generated just from software.name and the version string doesn't come into it at all.