V1.x Release

[YOU54F]

Hey all,

Just to let you know we will be promoting to a V1.x release very shortly,

It will do the following at the moment

• Promote to 1.x (long overdue
• Drop the -latest suffix from images, and produce multi-arch images against the latest tag
  • This will allow arm64/arm users to natively use the latest flag without having to force a linux/amd64 platform. #116
• Revert to the previous version scheme
  • New changes were introduced and documented here
  • The versioning scheme used the M.m.p from the Pact Cli gem, with an additional RELEASE number at the end (eg. 0.51.0.4)
  • pact-cli gem version number https://github.com/pact-foundation/pact-ruby-cli/blob/master/lib/pact/cli/version.rb

[YOU54F]

So,

1. first off, I am a numpty. I did a minor release, rather than a major!

2. For reasons I cannot fathom at the moment, the only one now with a multi arches, is the major tag 0

It doesn't make sense as the script is running the same command , albeit with a different tag, each time

https://github.com/pact-foundation/pact-ruby-cli/blob/master/script/release-workflow/docker-push.sh

[YOU54F]

Pulled the changes into my fork, released, and the manifests are correct 🤔

[YOU54F]

Right, so it doesn't look like the version increment is considered in this release workflow, so regardless of the user input, its defaulting to minor

1. on release workflow, we set an increment, this might be set manually when dispatching the workflow, or automatically by the gem update, which invokes the release workflow
   • https://github.com/pact-foundation/pact-ruby-cli/blob/bff4fe64fdaae6f5990c703884cebfd5cba834d5/.github/workflows/release_image.yml#L10-L17
2. we pass it through to script/release-workflow/run.sh
   • https://github.com/pact-foundation/pact-ruby-cli/blob/bff4fe64fdaae6f5990c703884cebfd5cba834d5/.github/workflows/release_image.yml#L54
3. The env vars are setup in this script . ${script_dir}/set-env-vars.sh
   • https://github.com/pact-foundation/pact-ruby-cli/blob/bff4fe64fdaae6f5990c703884cebfd5cba834d5/script/release-workflow/run.sh#L12
4. set-env-vars.sh calls out to script/release-workflow/next-docker-tag.sh to get the docker tag name
   • https://github.com/pact-foundation/pact-ruby-cli/blob/bff4fe64fdaae6f5990c703884cebfd5cba834d5/script/release-workflow/set-env-vars.sh#L19

5. the docker tag is computed and constructed using the version from lib/pact/cli/version.rb

   • uses the format ${gem_version}-<dupe_identifier>
   • This provides a distinct docker tag, where a new Docker image is released, and the underlying gems haven't been updated (example would be alpine base image update, or ruby version update with no updates to the gems)
   • https://github.com/pact-foundation/pact-ruby-cli/blob/bff4fe64fdaae6f5990c703884cebfd5cba834d5/script/release-workflow/next-docker-tag.sh#L20

   How should we compute the Docker tag version?

   Should we record all the changes, simply, in the pact cli gem version?

   • major/minor/patch update to pact cli gem version depending on the update of a packaged pact-* gem
   • triggers a release of the workflow, with the major/minor/patch INCREMENT set, as triggered by the underlying pact-* gem update
   • a major/minor/patch update to the docker image, but not the gem, should trigger a pact cli gem version update

[YOU54F]

hmm

snags.

1. incorrect referencing of pact broker here
   • https://github.com/pact-foundation/pact-ruby-cli/blob/7ea69c6b61a261adad61cbda6d152322c4507018/script/release-workflow/next-docker-tag.sh#L6
   • this means we wont get the right value here
   • https://github.com/pact-foundation/pact-ruby-cli/blob/7ea69c6b61a261adad61cbda6d152322c4507018/script/release-workflow/next-docker-tag.sh#L14

do we want something like

  if [ -n "$INCREMENT" ]; then
    bundle exec bump $INCREMENT --no-commit --replace-in $PWD/lib/pact/cli/version.rb > /dev/null
  fi

in

https://github.com/pact-foundation/pact-ruby-cli/blob/7ea69c6b61a261adad61cbda6d152322c4507018/script/release-workflow/next-docker-tag.sh#L8

and commit back the updated versions, as part of the docker release, which will catch docker release changes, and also releases triggered by gem updates

[YOU54F]

also wat?! These were the same codebases albeit in different forks. - still not publishing multi manifests correctly

but did on the fork see https://github.com/pact-foundation/pact-ruby-cli/issues/117#issuecomment-1714206821

[YOU54F]

Published 0.56.0.5 and oddly, one of the pushes gets associated with @bethesque account, but the other two which are published linux/amd64 only are associated with the pactfoundation account.

This doesn't really make sense, as there is only one set of credentials (DOCKERHUB_USERNAME and DOCKERHUB_TOKEN which are set at the pactfoundation org level, so not sure why Beth's account is being picked up here)

I tested out again on my fork, but forget there was a hard-coded org name, so I published to the pact-foundation account.

This has published the multi-manifests across all builds, with no other code changes. Could it be that we just need to update the org wide docker account and token in gh actions. Such confuse 😬

[bethesque]

I'm as confused as you are, if not more.

[YOU54F]

So I've worked it out now, there was an automated build trigger in docker, which was clobbering the multi-manifest builds, with an amd64 only. Disabled now in Dockerhub and pushed out a patch version to go out.

What a doozy! I thought I was literally going mad.