Skip to content

Release Process

Jump to bottom
Eugen C edited this page Nov 29, 2023 · 69 revisions

Table Of Contents

Overview

Before you start

Please get familiar with the Useful Info for Release Managers and Release Management Rotation.

Repositories

We have four different Packagecloud (RPM/Deb) package repositories:

Environment staging production
unstable 1 2
stable 3 4

Code gets promoted through the following repositories:

  1. StackStorm/staging-unstable - the current state of master
  2. StackStorm/unstable - latest master that passed end-to-end tests and promotion workflows at the scheduled daily time
  3. StackStorm/staging-stable - current “release candidate”, aka the latest commit on a release branch (should only change while a release is actively taking place)
  4. StackStorm/stable - tagged releases, i.e. 3.0.0, 3.1.0, 3.1.1 - should only get updated when there is a release

Promotion of packages into staging-unstable and then into unstable is handled automatically by our pull request and nightly CI/CD workflows.

The release process carries the packages from unstable into staging-stable, and it is here where all of the testing and churn related to the new release is done. Release candidate testing is performed using the staging-stable repositories, and this is usually where the release workflow bugs are found. These bugfixes and workflow churn is usually related to the addition or removal of supported operating systems and major architectural changes like removing Mistral support. The churn also included Python 2 vs Python 3 issues and Node.js version issues in the past, and likely will in the future.

Once all of the release workflow churn is complete, and all release testing is done and passing, the staging packages are promoted to the stable repository.

The StackStorm release and promotion workflows do a lot of the heavy lifting for release managers.

Preparation

Get access to st2cicd environment

Release management requires access to our st2cicd installation which is currently hosted in AWS. Talk with a senior maintainer to get VPN and st2 credentials if you don't already have it.

The CICD server is not up all the time, and is stopped/started via EventBridge rules StartCICD and StopCICD rules. Currently it starts on Tuesday at 24:00 UTC, and stops on a Friday at 04:00 UTC). During the release process you will want to disable the two rules, and start the CICD server.

In addition, the unstable build and promote jobs only run on Weds and Thursdays, so you may need to run these jobs manually or alter the schedule using the st2ci rules. The jobs that build and move the built packages from staging-unstable to unstable are st2ci.st2ci.st2_pkg_test_and_promote runs, controlled by the st2ci.st2_pkg_test_and_promote_unstable_ rules.

Testing Before Starting Release

Note that the below walkthrough calls out explicit testing at step 5. However, before starting the release process, it is highly encouraged that critical testing is performed on StackStorm/unstable packages first - that is, the latest changes to master branch that pass end-to-end testing.

Typically, the testing process highlights numerous bugs that need to be fixed, and if you've started this process, then those changes must be cherry-picked into the release branch. It's better instead to go through a "first wave" of this testing before going down this path, to make things easier on everyone. If done correctly, step 5, or testing after release branch has been cut, should be minimal.

While this does require master to be "frozen" for some time, which can be an inconvenience for the team, it can end up saving a lot of time in the long run because it will cut way down on cherry-picks into the release branch.

Note also that packages are promoted to StackStorm/unstable on a schedule (20:00 server time, every day) so be sure to manually promote packages before each round of testing, and after each fix.

Testing Process

  1. Clone StackStorm/st2vagrant and clean out any old vagrant boxes you don't need:

    git clone https://github.com/StackStorm/st2vagrant
cd st2vagrant
vagrant status
vagrant destroy

    If you're using virtualbox, you may have to clean up any old VMs that vagrant lost track of (due to upgrades, etc).

    VBoxManage list vms
VBoxManage unregistervm st2vagrant --delete

  2. Start up vagrant boxes:

    # unstable, specific version (before you start the release)
BOX=centos/7 RELEASE=unstable VERSION=3.9dev vagrant up
BOX=rockylinux/8 RELEASE=unstable VERSION=3.9dev vagrant up
BOX=ubuntu/bionic64 RELEASE=unstable VERSION=3.9dev vagrant up
BOX=ubuntu/focal64 RELEASE=unstable VERSION=3.9dev vagrant up

# staging-stable, latest version (after you've run e2e tests and are running this from Step #6 in the release process)
BOX=centos/7 REPO_TYPE=staging RELEASE=stable vagrant up
BOX=rockylinux/8 REPO_TYPE=staging RELEASE=stable vagrant up
BOX=ubuntu/bionic64 REPO_TYPE=staging RELEASE=stable vagrant up
BOX=ubuntu/focal64 REPO_TYPE=staging RELEASE=stable vagrant up

# stable, latest version (after you've promoted to stable and are running this from Step #8 in the release process to validate new production packages)
BOX=centos/7 RELEASE=stable vagrant up
BOX=rockylinux/8 RELEASE=stable vagrant up
BOX=ubuntu/bionic64 RELEASE=stable vagrant up
BOX=ubuntu/focal64 RELEASE=stable vagrant up

    If you have vagrant instances you want to keep, you can start these with an alternate hostname:

    VAGRANT_HOSTNAME=st2el7 BOX=centos/7 RELEASE=unstable VERSION=3.9dev vagrant up
VAGRANT_HOSTNAME=st2el8 BOX=rockylinux/8 RELEASE=unstable VERSION=3.9dev vagrant up
VAGRANT_HOSTNAME=st2bionic BOX=ubuntu/bionic64 RELEASE=unstable VERSION=3.9dev vagrant up
VAGRANT_HOSTNAME=st2focal BOX=ubuntu/focal64 RELEASE=unstable VERSION=3.9dev vagrant up

  3. For each box, login, sudo to root and run st2-self-check, at a minimum:

    $ vagrant ssh
[vagrant@st2vagrant ~]$ sudo su -
[root@st2vagrant ~]# sudo ST2_AUTH_TOKEN=$(st2 auth st2admin -p 'Ch@ngeMe' -t) /opt/stackstorm/st2/bin/st2-self-check

    NOTE The st2-self-check CLI may report that all of its actions returned "OK" on the CLI, even though the actions/tests it ran failed. You should double check that everything worked using st2 execution list and/or the Web UI.

  4. Run Manual Testing for Web and Flow UI

  5. Run ad-hoc tests manually.

Suggested "Order of Operations"

Based on the suggestions in the last section, here is the recommended order in which you perform release tasks:

  1. MAKE A PLAN. Document all remaining issues to be fixed before proceeding, and manage the list down.
  2. Assign and perform user acceptance testing of the current unstable packages
  3. Start the release process below once you're confident that the current master could easily be a release candidate

Work off fresh st2ci and st2cd repos

Make sure you do a fresh "git pull" for the st2ci and st2cd packs on the build node, and run st2ctl reload --register-all before starting any of this. It's important that each of these are working off the latest master, and that the running StackStorm instance has loaded all of these artifacts.

Process for Major Release

NOTE: PLEASE pay attention to each parameter in each command below. It's easy to just copy and paste these commands, but some of them refer to versions only relevant to previous releases. Before running any of these commands, please read each of the parameters and ensure it's accurate for the release you're running.

NOTE2: The github repositories st2, st2web, st2chatops and st2-packages have their master branch protected from updates by requiring approval by at least 2 reviewers. This protection must be disabled prior to running the release process workflows or they will be unable to update the master branch.

  1. STOP. Go back up and manually test along with the other work in the Preparation

  2. Login to the st2cicd server via SSH

    As a release manager you will be provided VPN and SSH access to the st2cicd server.

    Login to st2

    st2 login <username>
st2 whoami

  3. Set the release version in the datastore so we can just copy and paste the commands below. Change the versions in the examples below accordingly. For the NEXT version, please make sure version is the next ${major}.${minor} version you want on master. For example, if you are releasing THIS version 3.5.0, the NEXT version value you want is 3.6.0. If you are releasing THIS version 3.6.0, the NEXT version should be 3.7.0. Note that even if you know there will be a follow-up patch release, you should still increment the minor version here. For instance if you are finishing 3.5.0 release and you know there will be a 3.5.1 release, you should still set NEXT version to 3.6.0. The 3.5.1 release will be taken care of in the v3.5 branch that will be automatically created.

    # Set the version for the PREVIOUS release
st2 key set st2_prev_release "3.8.0"

# Set the version for THIS release
st2 key set st2_this_release "3.9.0"

# Set the version for the NEXT release.
st2 key set st2_next_release "3.10.0"

3b. If you want to stop the daily builds from running during the release process, then disable the following rules:

  • st2cd.st2_pkg_test_stable_rhel7
  • st2cd.st2_pkg_test_stable_rhel8
  • st2cd.st2_pkg_test_stable_u18
  • st2cd.st2_pkg_test_stable_u20
  • st2ci.st2_pkg_test_and_promote_unstable_el7
  • st2ci.st2_pkg_test_and_promote_unstable_el8
  • st2ci.st2_pkg_test_and_promote_unstable_u18
  • st2ci.st2_pkg_test_and_promote_unstable_u20

3c. At moment the st2/st2client README can pass all our tests, but will fail on attempting to upload to pypi. See https://github.com/StackStorm/st2/issues/5191. If appropriate lint checks have not been added to release, then it is suggested to verify the st2client README.rst with the following commands:

```
git clone https://github.com/StackStorm/st2.git
cd st2
cd st2client
python setup.py check -r -s
```

4a. Ensure that the AWS instances ubuntu-build-itest001, ubuntu-build002 and ubuntu-build003 EC2 instances are all started.

  1. Prepare the release branches for the st2 repos. Once release branches are created, circleci jobs will be kicked off automatically to build the new packages for the release version. Login to circleci and wait for appropriate builds to complete. There should be a build on the release branch for each affected git repos. Rerun the circleci builds as necessary. Login to packagecloud to check for the new packages in staging-stable.

    st2 run --async st2cd.st2_prep_release version={{st2kv.system.st2_this_release}}

    What is this actually doing? This step creates vX.Y branches, based on your {{st2kv.system.st2_this_release}} key, across the various repos. It also updates changelog files and moves all of the things in the # Development section into a section for this currently release vX.Y.

    From here on forward, if you have fixes that need to be applied to the various repos, you need to do what is called "cherry picking". Basically, if you have a fix to apply, create a PR to merge that fix into master as well as another PR to merge that fix into the vX.Y branch for the repo. This will include your changes into the release that has been started.

    There is a known race issue between st2 and st2-packages. The workflow st2cd.st2_prep_release triggers circleci jobs for both repos which build and upload new st2 packages to packagecloud. One of the circleci jobs will fail. When the dust settles, delete the st2 packages from staging-stable and rerun the failed circleci job.

    We temporarily shutdown AWS instances to save costs, if there are problems connecting to 10.0.1.23 then it may be because the AWS instance has been shutdown, and will need re-starting. Need to ensure that the AWS instances ubuntu-build-itest001, ubuntu-build002 and ubuntu-build003 EC2 instances are all started at the start of release process, and shutdown at the end.

    Worth checking staging-unstable and unstable packagecloud before running release process, to ensure that no new packages have been created since the pre-release testing.

  2. Use the following actions to test the packages for new install and upgrade from the last released version. For any more bug fixes during this step, the best practice is to commit to master and then cherry pick the fix to the release branch. When the fix is merged into the release branch, circleci should kick off builds for the affected repo automatically. Please remember to regression test the packages. Don't forget to provide the correct version (including patch) in the version parameter:

    # Clean install
st2 run --async st2ci.st2_pkg_e2e_test hostname=st2-pkg-staging-stable-u18 distro=UBUNTU18 pkg_env=staging release=stable version={{st2kv.system.st2_this_release}} chatops=true
st2 run --async st2ci.st2_pkg_e2e_test hostname=st2-pkg-staging-stable-u20 distro=UBUNTU20 pkg_env=staging release=stable version={{st2kv.system.st2_this_release}} chatops=true
st2 run --async st2ci.st2_pkg_e2e_test hostname=st2-pkg-staging-stable-el7 distro=CENTOS7 pkg_env=staging release=stable version={{st2kv.system.st2_this_release}} chatops=true
st2 run --async st2ci.st2_pkg_e2e_test hostname=st2-pkg-staging-stable-el8 distro=ROCKY8 pkg_env=staging release=stable version={{st2kv.system.st2_this_release}} chatops=true

# Upgrade from previous version of StackStorm packages
st2 run --async st2ci.st2_pkg_upgrade_e2e_test hostname=st2-pkg-upgrade-staging-stable-u18 distro=UBUNTU18 pkg_env=staging release=stable upgrade_from_version={{st2kv.system.st2_prev_release}} upgrade_to_version={{st2kv.system.st2_this_release}} chatops=true
st2 run --async st2ci.st2_pkg_upgrade_e2e_test hostname=st2-pkg-upgrade-staging-stable-u20 distro=UBUNTU20 pkg_env=staging release=stable upgrade_from_version={{st2kv.system.st2_prev_release}} upgrade_to_version={{st2kv.system.st2_this_release}} chatops=true
st2 run --async st2ci.st2_pkg_upgrade_e2e_test hostname=st2-pkg-upgrade-staging-stable-el7 distro=CENTOS7 pkg_env=staging release=stable upgrade_from_version={{st2kv.system.st2_prev_release}} upgrade_to_version={{st2kv.system.st2_this_release}} chatops=true
st2 run --async st2ci.st2_pkg_upgrade_e2e_test hostname=st2-pkg-upgrade-staging-stable-el8 distro=ROCKY8 pkg_env=staging release=stable upgrade_from_version={{st2kv.system.st2_prev_release}} upgrade_to_version={{st2kv.system.st2_this_release}} chatops=true

    If need to re-run these workflows, then it is worth checking if the VMs created by these workflows have been destroyed. Problems can occur for example if the upgrade workflows are re-run when the test VMs from previous run still exist (the destroy_vm subworkflow can be run to destroy any hanging around).

  3. Assign team to manually test web and flow UIs on all supported distros and browsers.

    For steps, see:

  4. Promote final set of packages from staging to production (st2, st2web, st2chatops). Visit PackageCloud to check for the new packages in stable.

    st2 run --async st2cd.st2_release_packages version={{st2kv.system.st2_this_release}}

    Validate that the following packages exist:

    • st2
    • st2web
    • st2chatops

    Validate that those packages exist for all supported OSes:

    • el/7
    • el/8
    • ubuntu/bionic (18.04)
    • ubuntu/focal (20.04)

  5. Test the packages after they are promoted to production including manual testing for web/flow UIs. Again, don't forget to provide the correct version (including patch) in the version parameter

    # Community
st2 run --async st2ci.st2_pkg_e2e_test hostname=st2-pkg-stable-u18 distro=UBUNTU18 pkg_env=production release=stable version={{st2kv.system.st2_this_release}}
st2 run --async st2ci.st2_pkg_e2e_test hostname=st2-pkg-stable-u20 distro=UBUNTU20 pkg_env=production release=stable version={{st2kv.system.st2_this_release}}
st2 run --async st2ci.st2_pkg_e2e_test hostname=st2-pkg-stable-el8 distro=ROCKY8 pkg_env=production release=stable version={{st2kv.system.st2_this_release}}
st2 run --async st2ci.st2_pkg_e2e_test hostname=st2-pkg-stable-el7 distro=CENTOS7 pkg_env=production release=stable version={{st2kv.system.st2_this_release}}

    Run through the manual testing for these stable packages:

  6. Tag release, update docs, and additional finalize activities (st2, st2web, st2chatops). Go to docs sites and make sure docs are updated. Go to pypi to make sure the clients are updated.

    st2 run --async st2cd.st2_finalize_release version={{st2kv.system.st2_this_release}}
st2 run --async st2cd.docker_finalize_release version={{st2kv.system.st2_this_release}}

    Check for new versions:

  7. Create rules to watch release branch to trigger e2e tests appropriately.

    st2 run --async st2cd.st2_prep_release_rules version={{st2kv.system.st2_this_release}} prev_version={{st2kv.system.st2_prev_release}}

  8. Load fresh copies of st2cd and st2ci. Go into each of these pack directories, ensure they're on master branch, do a git pull on each, and run st2ctl reload --register-all to ensure st2 has loaded everything fresh. This will include the rules that the previous step automatically updated. NB. This will re-enable any rules that were previously manually disabled, so if need to disable any this will need to be done manually. But at this stage the daily builds should be able to be re-enabled (unless due to run before complete remaining steps)

  9. Manually create a GitHub release on the st2 git repo.

    • st2

      • https://github.com/StackStorm/st2/releases

      • Create a new release

      • Use the tag, should already exist, for this release vX.Y.Z example v3.9.0

      • Copy the CHANGELOG entries into the release notes body

      • You'll need to change the headers for each section (Changed, Added, Removed, Fixed) and convert them from RST to Markdown (remove the line ~~~~~ underneath the title and add a # before the title).

        RST

        Changed
~~~~~~~

        Markdown

        # Changed

  10. Update the next development version on master branches. Once master branches are updated with the new dev version, circleci jobs will be kicked off automatically to build the new packages for the development version. Login to circleci and wait for appropriate builds to complete. There should be a build on the master branch for each affected git repos. Rerun the circleci builds as necessary. Login to packagecloud to check for the new packages in staging-unstable. When running the following command, please make sure version is the next ${major}.${minor} version you want on master. For example, if you are releasing 3.6.0, the version value you want is 3.7.0. If you are releasing 3.7.0, version should be 3.8.0.

    Note

    st2 run --async st2cd.st2_prep_dev version={{st2kv.system.st2_next_release}}

    Check Circle CI for successful builds on the following repos:

    Note that even if you know there will be a follow-up patch release, you should still provide a minor release here. For instance if you are finishing the 3.7.0 release and you know there will be a 3.7.1 release, you should still provide version=3.8.0. The 3.7.1 release will be taken care of in the v3.7 branch.

  11. Promote st2 dev packages from staging-unstable to unstable. Make sure the circleci jobs from step 13 are completed successfully and the packages are in staging-unstable.

    # Community
st2 run --async st2ci.st2_pkg_test_and_promote hostname=st2-pkg-unstable-u18 distro=UBUNTU18 release=unstable
st2 run --async st2ci.st2_pkg_test_and_promote hostname=st2-pkg-unstable-u20 distro=UBUNTU20 release=unstable
st2 run --async st2ci.st2_pkg_test_and_promote hostname=st2-pkg-unstable-el8 distro=ROCKY8 release=unstable
st2 run --async st2ci.st2_pkg_test_and_promote hostname=st2-pkg-unstable-el7 distro=CENTOS7 release=unstable

    Check PackageCloud for new packages in unstable channel

    Validate that the following packages exist:

    • st2
    • st2web
    • st2chatops

    Validate that those packages exist for all supported OSes:

    • el/7
    • el/8
    • ubuntu/bionic (18.04)
    • ubuntu/focal (20.04)

  12. Prep development version on master branch of st2-dockerfiles. The docker builds will be looking for st2 packages in unstable. This is the reason why we promote the unstable packages in the previous step.

    st2 run --async st2cd.docker_prep_dev version={{st2kv.system.st2_next_release}}

  13. Ensure that the AWS instances ubuntu-build-itest001, ubuntu-build002 and ubuntu-build003 EC2 instances are all stopped.

  14. Delete the datastore keys so we won't get messed up in the next release.

    st2 key delete st2_prev_release
st2 key delete st2_this_release
st2 key delete st2_next_release

  15. Update the version numbers in steps 3 and 12 for the next release manager.

Process for Patch Release

  1. For repos that requires fixes/changes, create patch branch for the repos and accumulate the fixes. Be sure to cherry pick the changes back to master. Follow the format v{major}.{minor}.{patch} (i.e. v3.5.1) for the branch naming as convention so release manager knows this is the branch for the patch release. Update the version appropriately for this repo. This is the responsibility of the developers making the changes/fixes.

    NOTE 1: It's also important that you create a corresponding StackStorm/st2-packages branch which matches the name of the st2 PR branch. For example, if StackStorm/st2 branch name is v2.0.1_changes you should also create a branch with the same name in StackStorm/st2-packages repo based on v2.0 branch (git checkout v2.0 ; git checkout -b v2.0.1_changes ; git push origin v2.0.1_changes).

    This is important since it will ensure StackStorm/st2 PR tests run against the correct StackStorm/st2-packages branch (this is especially important if st2-packages branches contain braking / incompatible changes between releases. In such scenario, st2 PR tests will fail if a corresponding st2-packages branch doesn't exist).

  2. When ready for patch release, the release manager will create PRs for the affected repos if they're not already done, wait for review to complete, and merge the PRs into the release branch (i.e. v2.0). Please make sure circleci jobs for these affected repos succeeded and new packages are staged at staging-stable in Packagecloud. st2 is an exception since it's built by st2-packages and step 4 below will update the version number in st2-packages that triggers that build.

  3. Set the release version in the datastore so we can just copy and paste the commands below. Change the versions in the examples below accordingly.

    # Set the version for the PREVIOUS release
st2 key set st2_prev_release "3.5.0"

# Set the version for THIS release
st2 key set st2_this_release "3.5.1"

  4. Update the version (i.e. 3.5.1) in the release branches (i.e. v3.5) for any unaffected st2 repos in this patch release. If there are changes for the patch release for a given repo and the version is already updated in that repo, the automation here will skip it. Once versions are updated, circleci jobs will be kicked off automatically to build the new packages for the release version. Login to circleci and wait for appropriate builds to complete. There should be a build on the release branch for each affected git repos. Rerun the circleci builds as necessary. Login to packagecloud to check for the new packages in staging-stable.

    st2 run --async st2cd.st2_prep_patch version={{st2kv.system.st2_this_release}}

  5. Run steps 5 - 12 from the main release process above.

  6. Manually add release note to the tagged release at the st2 git repo.

  7. Update changelog in st2 master manually. This is hard to automate since changes not included in this patch is also interleaved here.

  8. Delete the datastore keys so we won't get messed up in the next release.

    st2 key delete st2_prev_release
st2 key delete st2_this_release

Manual Testing For StackStorm Services

  1. Install community packages to a VM

  2. Ensure the st2 services are still running with st2ctl status

  3. Reboot the VM

  4. Ensure st2 services are still running with st2ctl status

  5. Run the self-verification script:

    $ vagrant ssh
[vagrant@st2vagrant ~]$ sudo su -
[root@st2vagrant ~]# sudo ST2_AUTH_TOKEN=$(st2 auth st2admin -p 'Ch@ngeMe' -t) /opt/stackstorm/st2/bin/st2-self-check

Manual Testing for Web and Flow UI

The "Flow UI" is the Workflow Designer UI that was recently integrated into the "Web UI"/Workflow Composer UI.

In this Exploratory Testing stage the goal is to find any issues, new bugs, regressions, or cosmetic issues that couldn't or weren't discovered by the automated tests yet (unknowns). Be curious and creative, try to break StackStorm. If you found a bug or regression, - add a case to the st2web headless browser functional tests.

Please run the following steps in Firefox, in Chrome, and in Safari (if you're on a Mac).

  1. Login to st2 via the web UI
  2. Logout and sign back in
  3. Navigate to all of the tabs: History, Actions, Rules, Docs, Contact Us
  4. Go to Actions and test search filter
  5. Go to Actions, run an execution of core.local, and view output
  6. Go to History, make sure the execution is there, and view output
  7. Go to History and rerun the last execution w/ different parameters and view output
  8. Go to Rules and test search filter
  9. Go to Rules and create a new rule using core.st2.key_value_pair.create to trigger core.local, create a new key, and go to History to make sure the action is executed
  10. Symlink the examples pack at /usr/share/doc/st2/examples into /opt/stackstorm/packs and do a st2ctl reload
  11. Go to Actions, navigate to the examples pack, click on any Orquesta workflow(s) and click the edit button at the top of the right pane - make sure it opens to the Flow UI and the workflow is displayed
  12. Click on the settings icon and look at the metadata for the workflow
  13. Download the workflow definition
  14. Execute the workflow
  15. Go to Actions, and click the blue plus button to create a new workflow
  16. Create a new workflow, as simple or complex as you want it to be
  17. Save the new workflow in the default pack.
  18. Execute the new workflow from the flow UI

Releasing st2web

As of ST2 2.8 was packaged and delivered. The system uses lerna to manage the interfaces components and applications. There isn't any automation at the moment for releasing these modules in the st2ci/cd workflows. So for now the release manager needs to release these manually. This is only required if there have been changes in st2web during the previous release.

System Requirements

  • Install node/npm of the correct version (see st2web README)
  • You may have to use n, node version management utility, to set the correct version
  • Yarn: npm install -g yarn
  • lerna: npm install -g lerna
  • Ensure you're logged into NPM mirror with an account that has publish rights to the needed packages. opsadmin is one such account.

st2web

  1. Version st2web, tag release, and create new version of packages: lerna version
  2. Check and make sure the new packages are created locally: lerna list -l
  3. Login to npm locally (credential at lastpass): npm login
  4. Publish modules: lerna publish from-package
  5. Go to https://www.npmjs.com, search for StackStorm, and ensure new packages are uploaded.

Releasing st2chatops

If a new release of hubot-stackstorm is required, the following notes were recorded by @cognifloyd. The key point is that there is a StackStorm user account stormstanley that should be used for publishing hubot-stackstorm. This account is accessible only to senior maintainers so the release manager will need to coordinate publishing to npm with one of them.

Release steps (the example if the v0.12.0 release:

  1. created release+tag in github ui v0.12.0
  2. ran npm login on cli and logged in as myself
  3. ran npm publish in my clone of the hubot-stackstorm repo (checked out on master at tag v0.12.0)
  4. verified that it was published: https://www.npmjs.com/package/hubot-stackstorm/v/0.12.0

I have never made a release on NPM. It would have been simpler to just log in as storminstanley on the command line, and then get the OTP from a senior maintainer. But I didn't know that so, I logged in first on the website. Then, no senior maintainers were available to get me another OTP to login on CLI which is required to publish a release. That's why I created my own account and added myself to hubot-stackstorm so I could make the release.

Release known issues

  • When releasing st2client there is likely an issue with test packages that will cause the workflow to fail
  • If this release is the first to add support for a particular OS (or OS major version), skip running the upgrade end-to-end tests for it
Clone this wiki locally