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. Remove the -multi tag from cross-platform images #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

• pact-ruby-cli/.github/workflows/release_image.yml

  Lines 10 to 17 in bff4fe6

  	increment:
  	description: Increment
  	default: minor
  	type: choice
  	options:
  	- major
  	- minor
  	- patch

2. we pass it through to script/release-workflow/run.sh

• pact-ruby-cli/.github/workflows/release_image.yml

  Line 54 in bff4fe6

  INCREMENT: ${{ github.event.client_payload.increment }}${{ github.event.inputs.increment }}

3. The env vars are setup in this script . ${script_dir}/set-env-vars.sh

• pact-ruby-cli/script/release-workflow/run.sh

  Line 12 in bff4fe6

  . ${script_dir}/set-env-vars.sh

4. set-env-vars.sh calls out to script/release-workflow/next-docker-tag.sh to get the docker tag name

• pact-ruby-cli/script/release-workflow/set-env-vars.sh

  Line 19 in bff4fe6

  export TAG=$(script/release-workflow/next-docker-tag.sh)

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)

• pact-ruby-cli/script/release-workflow/next-docker-tag.sh

  Line 20 in bff4fe6

  tag="${gem_version}.${next_release_number}"

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

• pact-ruby-cli/script/release-workflow/next-docker-tag.sh

  Line 6 in 7ea69c6

  grep "pact_broker (" pact_broker/Gemfile.lock | awk -F '[()]' '{print $2}'

• this means we wont get the right value here

• pact-ruby-cli/script/release-workflow/next-docker-tag.sh

  Line 14 in 7ea69c6

  last_release_number=$(printf "0\n${existing_release_numbers_for_current_gem_version}" | sort -g | tail -1)

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

pact-ruby-cli/script/release-workflow/next-docker-tag.sh

Line 8 in 7ea69c6

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 #117 (comment)

[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.