Tag creation in wrong order

[akerl]

Howdy!

I'm running into some weird behavior with tag creation: bundle exec rake module:release appears to push the current version and then tag a new one immediately, so I end up with a new tag that isn't on puppetforge.

I'm using http://github.com/halyard/puppet-test as a test case.

Here's the output showing what happens:

~/src/halyard/puppet-test () bean
❯ gc -am 'initial commit'
[master (root-commit) a825486] initial commit
 7 files changed, 76 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 Gemfile
 create mode 100644 LICENSE
 create mode 100644 README.md
 create mode 100644 Rakefile
 create mode 100644 manifests/init.pp
 create mode 100644 metadata.json
~/src/halyard/puppet-test () bean
❯ git tag
~/src/halyard/puppet-test () bean
❯ bundle install
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Unable to use the platform-specific (universal-darwin) version of facter (2.5.1) because it has different dependencies from the ruby version. To use the platform-specific version of the gem, run `bundle config specific_platform true` and install again.
Unable to use the platform-specific (universal-darwin) version of puppet (5.3.3) because it has different dependencies from the ruby version. To use the platform-specific version of the gem, run `bundle config specific_platform true` and install again.
Using rake 12.3.0
Using public_suffix 3.0.1
Using addressable 2.5.2
Using bundler 1.16.0
Using diff-lcs 1.3
Using unf_ext 0.0.7.4
Using unf 0.1.4
Using domain_name 0.5.20170404
Using facter 2.5.1
Using fast_gettext 1.1.0
Using locale 2.1.2
Using text 1.3.1
Using gettext 3.2.4
Using gettext-setup 0.29
Using hiera 3.4.2
Using http-cookie 1.0.3
Using json-schema 2.8.0
Using metaclass 0.0.4
Using spdx-licenses 1.1.0
Using metadata-json-lint 2.0.2
Using mime-types-data 3.2016.0521
Using mime-types 3.1
Using mocha 1.3.0
Using netrc 0.11.0
Using puppet 5.3.3
Using rest-client 2.0.2
Using puppet-blacksmith 4.1.0
Using puppet-lint 2.3.3
Using puppet-syntax 2.4.1
Using rspec-support 3.7.0
Using rspec-core 3.7.0
Using rspec-expectations 3.7.0
Using rspec-mocks 3.7.0
Using rspec 3.7.0
Using rspec-puppet 2.6.9
Using puppetlabs_spec_helper 2.5.1
Using semantic_puppet 1.0.1
Bundle complete! 6 Gemfile dependencies, 37 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
~/src/halyard/puppet-test () bean
❯ bundle exec rake module:release
Cleaning for module build
Bumping version from 0.0.0 to 0.0.1
Uploading to Puppet Forge halyard/test
Pushing to remote git repo
~/src/halyard/puppet-test () bean  11s
❯ git tag
0.0.1
~/src/halyard/puppet-test () bean
❯ cat metadata.json
{
  "name": "halyard-test",
  "version": "0.0.1",
  "author": "Les Aker",
  "summary": "Test repo",
  "license": "MIT",
  "source": "https://github.com/halyard/puppet-test",
  "project_page": "https://github.com/halyard/puppet-test",
  "issues_url": "https://github.com/halyard/puppet-test/issues",
  "dependencies": [

  ],
  "operatingsystem_support": [

  ]
}

The end result on the Forge is https://forge.puppet.com/halyard/test

So I end up w/ a "0.0.0" release on Puppet Forge, 0.0.1 as a tag, and 0.0.1 in the metadata file.

This differs from what used to happen, where it would tag 0.0.0, push the tag to GitHub and Puppetforge, and then bump the 0.0.1 in the metadata file.

[akerl]

It feels like this may be linked to https://github.com/voxpupuli/puppet-blacksmith/issues/38

[ekohl]

Personally I think the release job should be removed. You should never automatically bump and push in the same command unless you can specify if it's a patch, minor or major version. Another thing that I dislike is that push does pattern matching in the pkg directory rather than request an explicit version.

[akerl]

Both of those seem like totally reasonable concerns. In the interim though, until release gets deprecated and/or push gets upgraded, can we revert the change to the release task so it at least pushes a tag that matches the module it's releasing?

[antaflos]

I have run into the same issues which makes the workflow a bit awkward compared to blacksmith prior to the 4.0 release.

In order to avoid having useless or wrong tags, what would be the currently recommended workflow for creating releases for major, minor and patch versions?

[deric]

I'm having the same problem rake module:release pushes module to forge with correct version, bumps version and tags it incorrectly on github (with unreleased tag). It seems to be caused by this commit. So, currently the workaround is:

gem 'puppet-blacksmith', '< 4.0.0'

Btw. the rake task description is obviously incorrect:

desc "Release the Puppet module, doing a clean, build, tag, push, bump_commit and git push."
release_dependencies = @build ? [:clean, :build, :bump_commit, :tag, :push] : [:clean, :bump_commit, :tag]

as the job does something completely different.

@TheKangaroo IMHO a breaking change like f5f1bc0b58e35a254571b4c900f41f790edf8bf5 should be covered by tests, as it covers commonly used use-cases.

[mattock]

Same problem here.

[tohuwabohu]

Thanks everyone involed in creating and maintaining this super useful extension :pray: .

Having run into this problem myself, is there a plan to fix or at least announce this problem on the README? IMHO it is a significant bug which many may run into especially when forced to upgrade to a more recent version. At first I've tried to downgrade but run into issues with Ruby and rest client which left me no choice but overwrite the Ruby task as mentioned by @deric .

[akerl]

Seems like overriding the behavior is the path forward for folks who want to use blacksmith.