Useful info for Release Managers

Interesting stuff

Verifying commits in a build

Useful for making sure the repository has the latest commit you think it should have - though this requires you install it on a VM first:

	[vagrant@st2test ~]$ cat /opt/stackstorm/st2/package.meta
	[server]
	version = 2.2dev
	git_sha = 74d3dbd

Packaging

PackageCloud Repositories

Here is a brief description of each repo:

• StackStorm/stable - tagged releases, i.e. 2.1, 2.1.1, 2.2 - should only get updated when there is a release
• StackStorm/unstable - latest master that passed e2e tests and promotion workflows at the scheduled daily time
• StackStorm/staging-stable - current “release candidate”, aka the latest commit on a release branch (should only change while a release is actively taking place)
• StackStorm/staging-unstable - the current state of master

User-Acceptance Testing Before Starting Release

Previously most releases cut a release branch and promoted packages to staging-stable - then, manual user acceptance testing was done on these packages. Nowadays testing occurring before even starting the release process - it was done using packages in unstable - or in other words, the latest master, before cutting a release branch.

While this did require master to be "frozen" for some time, which can be an inconvenience for the team, it usually saves a lot of time in the long run because, since issues were ironed out before cutting a release branch, no cherry-picks were required.

Package Promotion

Unstable packages are promoted from staging-unstable to unstable on a schedule. There are rules in place that kick these off at the same time daily. At this time, end-to-end tests are run on staging packages. If they pass, the package promotion workflows kick off, and the packages are promoted to StackStorm/unstable repo in packagecloud.

During a release, you may want to promote packages yourself instead of waiting for the daily promotion time. These workflows are what get kicked off by this rule, so you can just run these manually:

Community packages

st2 run st2ci.st2_pkg_test_and_promote hostname=st2-pkg-unstable-el7 distro=RHEL7 release=unstable
st2 run st2ci.st2_pkg_test_and_promote hostname=st2-pkg-unstable-el8 distro=RHEL8 release=unstable
st2 run st2ci.st2_pkg_test_and_promote hostname=st2-pkg-unstable-u16 distro=UBUNTU16 release=unstable
st2 run st2ci.st2_pkg_test_and_promote hostname=st2-pkg-unstable-u18 distro=UBUNTU18 release=unstable

Debugging E2E Testing Temporary AWS Instances

If you encounter a failure on one of the temporarily built AWS nodes, it's normally destroyed and you can't troubleshoot. Use debug flag on root e2e test workflow, and the machine will stick around

st2 run st2ci.st2_pkg_e2e_test hostname=st2-pkg-stable-el7 distro=RHEL7 pkg_env=production release=stable debug=true -a

Don't forget to destroy it manually after investigation.