Skip to content

Update Mattermost to 9.1.0

Akis Maziotis requested to merge mattermost/omnibus-gitlab:mattermost-9.1 into master

What does this MR do?

Update Mattermost to 9.1.0

Changelog: other

The full changelog for this release can be found here.

cc @amyblais @spirosoik @neil.barnett @jasonblais @toninis

Test plan

Build tests

  • Built on all supported platforms
  • Ran Trigger:ee-package and then qa-subset-test as well as manual qa-remaining-test-manual CI jobs on gitlab.com.

Fresh installation tests

Installed a Linux package created in the build system on a fresh OS installation and ran the following actions, checks, and tests:

  • Installed Linux package with the new Mattermost version:

    • Verified that package installation logs/output shows no errors.
    • Verified Mattermost version by running /opt/gitlab/embedded/bin/mattermost version.

  • Edited /etc/gitlab/gitlab.rb and set:

    • external_url
    • mattermost_external_url

    Both URLs should point to the same system so that GitLab and Mattermost are co-located. Example:

    external_url 'gitlab.example.com'
mattermost_external_url 'mattermost.example.com'

  • Ran gitlab-ctl reconfigure.

  • Connected to gitlab.example.com.

  • Navigated to Admin>Settings>Network>Outbound requests and added mattermost.example.com to Local IP addresses and domain names that hooks and services can accesss and clicked Save changes.

  • Navigated to mattermost.example.com.

  • Verified that single-sign on using GitLab credentials was working:

    1. Clicked on or create and account with GitLab.
    2. When presented with the Authorize GitLab Mattermost to use your account? page, clicked on Authorize. You should have landed on the Select teams page.

  • Verified that when creating a group in GitLab, checking the box for Create a Mattermost team for this group also created a team in Mattermost and the GitLab user is a member of that team.

  • Created a test project within the group created in the previous step and initialize with a README.

  • Verified Mattermost slash command operation:

    • Enabled slash commands using GitLab documentation.
    • Tested slash commands by creating a new issue from the Mattermost instance. After following the prompt to re-authorize, the issue should have been successfully created in GitLab.

  • Verified GitLab issue notification.

    • Configured incoming web hooks in Mattermost using the GitLab Documentation. Note that you have to configure both Mattermost and GitLab.
    • Using the created web hook, followed the documentation for adding notification support.
    • Created an issue in the test project. Verified that the notification for the issue appeared in Mattermost for the GitLab user.

Upgrade installation tests

Install a Linux package from the previous, latest minor number release on a fresh OS installation. Run the following actions, checks, and tests:

  • Installed Linux package from the previous, latest minor number release:

    • Verified that package installation logs/output showed no errors.
    • Verified Mattermost version by running /opt/gitlab/embedded/bin/mattermost version.

  • Edited /etc/gitlab/gitlab.rb and set:

    • external_url
    • mattermost_external_url

    Both URLs should point to the same system so that GitLab and Mattermost are co-located. Example:

    external_url 'gitlab.example.com'
mattermost_external_url 'mattermost.example.com'

  • Ran gitlab-ctl reconfigure.

  • Connected to gitlab.example.com.

  • Navigated to Admin>Settings>Network>Outbound requests and added mattermost.example.com to Local IP addresses and domain names that hooks and services can accesss and clicked Save changes.

  • Navigated to mattermost.example.com.

  • Verified that single-sign on using GitLab credentials is working:

    1. Clicked on or create and account with GitLab.
    2. When presented with the Authorize GitLab Mattermost to use your account? page, clicked on Authorize.
    3. You should have landed on the Select teams page.

  • Verified that when creating a group in GitLab, checking the box for Create a Mattermost team for this group also created a team in Mattermost and the GitLab user is a member of that team.

  • Created a test project within the group created in the previous step and initialized with a README.

  • Verified Mattermost slash command operation:

    • Enabled slash commands using GitLab documentation.
    • Tested slash commands by creating a new issue from the Mattermost instance. After following the prompt to re-authorize, the issue should have been successfully created in GitLab.

  • Verified GitLab issue notification.

    • Configured incoming web hooks in Mattermost using the GitLab Documentation. Note that you have to configure both Mattermost and GitLab.
    • Using the created web hook, followed the documentation for adding notification support.
    • Created an issue in the test project. Verified that the notification for the issue appears in Mattermost for the GitLab user.

Upgrade GitLab with a Linux package created with the new Mattermost version. Run the following actions, checks, and tests:

  • Upgraded to package with new Mattermost version:

    • Verified that package installation logs/output shows no errors.
    • Verified Mattermost version by running /opt/gitlab/embedded/bin/mattermost version.

  • Verified Mattermost slash command operation:

    • Tested slash commands by creating a new issue from the Mattermost instance. After following the prompt to re-authorize, the issue should have been successfully created in GitLab.

  • Verified GitLab issue notification.

    • Created an issue in the test project. Verified that the notification for the issue appeared in Mattermost for the GitLab user.

Related issues

Relates #8240 (closed)

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

  • MR title and description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • Latest Merge Result pipeline is green.
  • When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow.

For GitLab team members

If you don't have access to this, the reviewer should trigger these jobs for you during the review process.

  • The manual Trigger:ee-package jobs have a green pipeline running against latest commit.
  • If config/software or config/patches directories are changed, make sure the build-package-on-all-os job within the Trigger:ee-package downstream pipeline succeeded.
  • If you are changing anything SSL related, then the Trigger:package:fips manual job within the Trigger:ee-package downstream pipeline must succeed.
  • If CI configuration is changed, the branch must be pushed to dev.gitlab.org to confirm regular branch builds aren't broken.

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes.
  • Documentation created/updated.
  • Tests added.
  • Integration tests added to GitLab QA.
  • Equivalent MR/issue for the GitLab Chart opened.
  • Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.
Edited by Jason Plum

Merge request reports