mirror of
https://github.com/mattermost/mattermost.git
synced 2026-09-19 10:12:47 +08:00
Remove internal only pages from develop (#37436)
This commit is contained in:
Eva Sarafianou
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
@@ -1,124 +0,0 @@
|
||||
---
|
||||
title: "Desktop Release Process"
|
||||
sidebar_position: 101
|
||||
---
|
||||
|
||||
***NOTE**: For the purposes of this document, the letter `X` will refer to the major version number, `Y` will refer to the minor version number, and `Z` will refer to the patch (dot) version number.*
|
||||
|
||||
## Before you begin
|
||||
|
||||
Before starting a new release, you want to make sure you do a few things:
|
||||
- Check to make sure that there are no further Bug or Story tickets waiting to be merged. You can check JIRA to see if there are any tickets with the Fix version: `vX.Y Desktop App`. If there are, you'll want to wait until those have been merged.
|
||||
- For major/minor releases, check to make sure that an Electron upgrade has been done shortly before the release. It's important to keep up with the latest security changes in Electron and Chrome.
|
||||
|
||||
- If you work off of a fork of the `mattermost/desktop` repository, make sure your local master branch is up to date:
|
||||
```
|
||||
git checkout master && git fetch --all && git merge upstream/master`
|
||||
```
|
||||
- You might need to install `jq`, a parsing tool for JSON files:
|
||||
```
|
||||
// macOS
|
||||
brew install jq
|
||||
|
||||
// Linux (Ubuntu/Debian)
|
||||
sudo apt-get install jq
|
||||
|
||||
// Windows
|
||||
choco install jq
|
||||
```
|
||||
|
||||
## Start a new release
|
||||
|
||||
1. For a new major or minor release, check out the `master` branch and create a new release branch from it
|
||||
```
|
||||
git checkout master
|
||||
git checkout -b release-X.Y
|
||||
```
|
||||
For a patch release, or if the branch already exists, just check out the existing release branch matching the version you're patching.
|
||||
```
|
||||
git checkout release-X.Y
|
||||
```
|
||||
|
||||
2. Run the release script to create the first release candidate.
|
||||
Major/Minor release:
|
||||
```
|
||||
./scripts/release.sh rc
|
||||
```
|
||||
Patch release:
|
||||
```
|
||||
./scripts/release.sh patch
|
||||
```
|
||||
|
||||
3. When the script is finished, if it worked successfully, you should see an output like this:
|
||||
```
|
||||
[INFO ] Generating X.Y.Z release candidate 1
|
||||
[INFO ] Locally created an rc. In order to build you'll have to:
|
||||
[INFO ] $ git push --follow-tags upstream release-X.Y:release-X.Y
|
||||
```
|
||||
If so, you can run the provided command.
|
||||
|
||||
```text
|
||||
If **not**, you may need to:
|
||||
- Make sure there are no local uncommitted changes
|
||||
- Make sure there are no tags matching the new version you're trying to create
|
||||
```
|
||||
|
||||
4. **For major/minor releases only**: Once you have pushed the new release branch and tags, switch back to the `master` branch, and edit the `package.json` and `package-lock.json` files to reflect the next minor version. For example, if the version you're releasing is `5.0.0`, change the version number to `5.1.0`. When done, create a PR to bump `master` to the next release.
|
||||
|
||||
5. Wait for the release candidate to finish building. You can monitor the progress [here](https://github.com/mattermost/desktop/actions/workflows/release.yaml). When it's finished, there will be a post in the `Release: Desktop Apps` channel with the new version number and a changelog.
|
||||
|
||||
6. When the release process is finished, go to the `mattermost/desktop` GitHub repository and select **Releases**.
|
||||
7. There should be a draft release of your new release candidate. Click the Pencil icon to edit.
|
||||
8. Make sure it's checked off as a pre-release, then select **Publish Release**.
|
||||
|
||||
## Generate additional release candidates
|
||||
|
||||
If there are any bugs reported by QA, once they are fixed we will need to generate an additional release candidate to verify that any issues have been fixed.
|
||||
|
||||
To generate additional release candidates, you'll simply run the following commands to kick it off:
|
||||
```
|
||||
git checkout release-X.Y
|
||||
./scripts/release.sh rc
|
||||
git push --follow-tags upstream release-X.Y:release-X.Y
|
||||
```
|
||||
|
||||
You can then follow steps **5-8** above to make sure the release is published.
|
||||
|
||||
## Mac App Store
|
||||
|
||||
Once the final release candidate has been approved by QA, you will need approval from the Mac App Store. To do so, we create a special release for them:
|
||||
```
|
||||
git checkout release-X.Y
|
||||
./scripts/release.sh pre-final
|
||||
git push --follow-tags upstream release-X.Y:release-X.Y
|
||||
```
|
||||
|
||||
### Submit to App Review
|
||||
|
||||
In this case, you won't get any notifications from Mattermost or GitHub, as we are submitting directly to Apple at this point. From here, we will need to submit the app for review:
|
||||
|
||||
1. Go to our app on [App Store Connect](https://appstoreconnect.apple.com/apps/1614666244/appstore) and log in with your credentials.
|
||||
- If you do not have access to App Store Connect, you'll have to ask your team lead.
|
||||
2. If there is not an unreleased version, select the **+** button in the top-left next to "macOS App", and fill out the version number (should just be `X.Y.Z`)
|
||||
3. Copy the changelog for this version into the **"What's New in This Version"** section.
|
||||
4. In the Build section, select **Add Build**. Find the build corresponding to the version that was just built.
|
||||
- You should be able to recognize it by timestamp, but if not, grab the build from TestFlight and verify that the version number is correct.
|
||||
5. Make sure under Version Release that "Manually release this version" is selected.
|
||||
6. Once that's all done, you can select the **Add for Review** button and follow the prompts to submit a review.
|
||||
|
||||
The review process is relatively quick in most cases, usually taking up to about 24 hours to complete.
|
||||
|
||||
If the app is **approved** by App Review, you will get an email from App Store Connect saying "Your submission was accepted". From there, you can go back and release the app once the final release has been cut.
|
||||
|
||||
If the app is **rejected** by App Review, you will get an email from App Store Connect saying "We noticed an issue with your submission". At that point, you'll need to log back into App Store Connect and review their comments. Make the necessary changes and you can follow the same process as above to re-submit for review until the app has been approved.
|
||||
|
||||
## Cut the final release
|
||||
|
||||
Once the app has been approved by all parties, we can cut the final release:
|
||||
```
|
||||
git checkout release-X.Y
|
||||
./scripts/release.sh final
|
||||
git push --follow-tags upstream release-X.Y:release-X.Y
|
||||
```
|
||||
|
||||
You can then follow steps **5-8** from the "Start a new release" section above to make sure the release is published, but make sure that the checkbox for 'Set as pre-release` is unchecked.
|
||||
@@ -1,238 +0,0 @@
|
||||
---
|
||||
title: "GitLab Omnibus"
|
||||
sidebar_position: 130
|
||||
---
|
||||
|
||||
GitLab's Omnibus package bundles Mattermost Team Edition (TE) as an optional feature that can be enabled during installation. While GitLab maintains most of this integration, we send them new versions of Mattermost and occasionally assist with support on issues that relate to Mattermost.
|
||||
|
||||
For every monthly GitLab release, we submit a merge request (MR) to [GitLab's repository](https://gitlab.com/gitlab-org/omnibus-gitlab/) to update the embedded version of Mattermost. GitLab releases in the middle of the month, so we'll generally submit the newest version of Mattermost to them at the start of the month to give time for the review process to happen.
|
||||
|
||||
### Setting up GitLab Omnibus for development
|
||||
|
||||
We maintain [our own fork of GitLab Omnibus](https://gitlab.com/mattermost/omnibus-gitlab) for use when submitting merge requests upstream. This should be cloned and kept up to date to ensure that we're testing and submitting against the latest code.
|
||||
|
||||
These are the steps for checking out GitLab Omnibus and installing its dependencies:
|
||||
|
||||
1. Clone our fork.
|
||||
|
||||
```bash
|
||||
git clone https://gitlab.com/mattermost/omnibus-gitlab.git
|
||||
```
|
||||
|
||||
2. Add the upstream repository as a git remote.
|
||||
|
||||
```bash
|
||||
git remote add upstream https://gitlab.com/gitlab-org/omnibus-gitlab.git
|
||||
```
|
||||
|
||||
3. Install Docker. GitLab packages all dependencies for building GitLab Omnibus in a Docker image which will be pulled later.
|
||||
|
||||
### Submitting a new version of Mattermost
|
||||
|
||||
These are the steps to update GitLab Omnibus with a new version of Mattermost:
|
||||
|
||||
1. Ensure our fork's master branch is up to date with upstream.
|
||||
|
||||
```bash
|
||||
git checkout master
|
||||
git fetch upstream
|
||||
git pull upstream master
|
||||
git push
|
||||
```
|
||||
|
||||
2. Create a branch for the new version of Mattermost.
|
||||
|
||||
```bash
|
||||
git checkout -b mattermost-X.Y
|
||||
```
|
||||
|
||||
3. Update the version of Mattermost downloaded at build time by modifying `config/software/mattermost.rb`. The `default_version` and `md5` fields need to be set to the match the latest release of Mattermost TE.
|
||||
|
||||
4. Add an entry to the table in `doc/gitlab-mattermost/README.md` that maps GitLab versions to the corresponding Mattermost version. This step is not necessary for dot releases of Mattermost.
|
||||
|
||||
5. Commit the changes made to `config/software/mattermost.rb` and `doc/gitlab-mattermost/README.md`. The commit message is used to generate a changelog entry, so it must include a second line containing the type of change made. For regular releases, it should be the following:
|
||||
|
||||
```
|
||||
Update Mattermost to X.Y
|
||||
|
||||
Changelog: other
|
||||
```
|
||||
|
||||
For security backports, the type should be changed to "security".
|
||||
|
||||
You can now test the build and submit an MR upstream. For an example of how the branch should look after that, see [here](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5068).
|
||||
|
||||
### Building GitLab Omnibus
|
||||
|
||||
As mentioned above, GitLab Omnibus is built in a Docker container containing all of the needed dependencies. To test it, the generated `.deb` package needs to be copied off of the Docker container and installed locally on the test server. Details on how to do that follow.
|
||||
|
||||
These steps differ slightly from the more detailed ones available from GitLab ([link](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/doc/build/build_package.md)) since they were changed to keep the Git repository outside of Docker container, but they still work as of March 4, 2021.
|
||||
|
||||
1. Get the current `BUILDER_IMAGE_REVISION` value from `.gitlab-ci.yml`.
|
||||
|
||||
2. Run the builder in a Docker container. You may have to run these with `sudo` depending on permissions. This assumes you're using Ubuntu 18.04, but there are other Docker images available for different OSes.
|
||||
|
||||
```bash
|
||||
docker pull registry.gitlab.com/gitlab-org/gitlab-omnibus-builder/ubuntu_18.04:${BUILDER_IMAGE_REVISION}
|
||||
docker run -it registry.gitlab.com/gitlab-org/gitlab-omnibus-builder/ubuntu_18.04:${BUILDER_IMAGE_REVISION} bash
|
||||
```
|
||||
|
||||
3. Inside the container, clone the repo and change to the folder. Note that we're cloning our fork here.
|
||||
|
||||
```bash
|
||||
git clone https://gitlab.com/mattermost/omnibus-gitlab.git ~/omnibus-gitlab
|
||||
cd ~/omnibus-gitlab
|
||||
```
|
||||
|
||||
4. Change to the correct branch.
|
||||
|
||||
```bash
|
||||
git checkout mattermost-X.Y
|
||||
```
|
||||
|
||||
5. Specify where to grab GitLab dependencies and assets from.
|
||||
|
||||
```bash
|
||||
export ALTERNATIVE_SOURCES=true
|
||||
export ASSET_REGISTRY=registry.gitlab.com
|
||||
export COMPILE_ASSETS=true
|
||||
```
|
||||
|
||||
6. Install Ruby dependencies.
|
||||
|
||||
```bash
|
||||
bundle install
|
||||
bundle binstubs --all
|
||||
```
|
||||
|
||||
7. Build everything. This can take a couple of hours, so go grab lunch.
|
||||
|
||||
```bash
|
||||
bin/omnibus build gitlab
|
||||
```
|
||||
|
||||
8. From the host machine, copy the compiled package out of the Docker container.
|
||||
|
||||
```bash
|
||||
docker cp <container>:/root/omnibus-gitlab/pkg/<package>.deb .
|
||||
```
|
||||
|
||||
Note that Docker likes to eat up space on the disk without cleaning up after itself, so you'll want to remove old Docker containers with `docker rm` after building and copying the package to the host machine.
|
||||
|
||||
### Installing and configuring GitLab Omnibus
|
||||
|
||||
To install GitLab Omnibus with Mattermost, you'll need to configure your DNS with two domain names for the test server: one for GitLab and one for Mattermost. The following steps will use `gitlab.dev.mm` and `mattermost.dev.mm` as those domains.
|
||||
|
||||
The package generated above can be installed with `sudo dpkg -i <package>.deb`.
|
||||
|
||||
After first installing GitLab Omnibus, the external URLs for GitLab need to be configured, and Mattermost needs to be enabled in the GitLab config. To do that:
|
||||
|
||||
1. Open `/etc/gitlab/gitlab.rb` using vi or your preferred text editor.
|
||||
|
||||
```bash
|
||||
sudo vi /etc/gitlab/gitlab.rb
|
||||
```
|
||||
|
||||
2. Set the `external_url` to set GitLab's external URL.
|
||||
|
||||
```ruby
|
||||
external_url "http://gitlab.dev.mm"
|
||||
```
|
||||
|
||||
3. Find and uncomment the line which sets `mattermost_external_url` and set it to Mattermost's external URL.
|
||||
|
||||
```ruby
|
||||
mattermost_external_url "http://mattermost.dev.mm"
|
||||
```
|
||||
|
||||
4. Find and uncomment the line which sets `mattermost['enable']` and set it to `true`.
|
||||
|
||||
```ruby
|
||||
mattermost['enable'] = true
|
||||
```
|
||||
|
||||
5. Leave your editor and use `gitlab-ctl` to reconfigure and restart its services.
|
||||
|
||||
```bash
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
After a few minutes, Mattermost and GitLab should be accessible from their respective URLs and GitLab sign-in should be automatically configured in Mattermost. The default admin login on GitLab has the username `root` and the password `5iveL!fe`.
|
||||
|
||||
A few more commands for working with GitLab can be found [in our support documentation](https://docs.mattermost.com/process/support.html#other-debugging-information).
|
||||
|
||||
### Testing Mattermost in GitLab Omnibus
|
||||
|
||||
To test a new version of Mattermost running in GitLab, you'll have to test the three main ways they interact: logging in, creating a Mattermost team for a GitLab group, and adding notifications/slash commands to Mattermost. Using the same URLs as above, the steps for testing are:
|
||||
|
||||
1. Test signing into Mattermost, once when not logged into GitLab and then again after having already logged in.
|
||||
|
||||
1. Visit `http://mattermost.dev.mm` in a browser.
|
||||
|
||||
2. Select **Sign in with GitLab**. You should be directed to the GitLab login screen.
|
||||
|
||||
3. Log in as any user. You should be sent back to Mattermost and logged in.
|
||||
|
||||
4. Log out and back in through the same process. You should skip the GitLab login screen since you were still logged into GitLab.
|
||||
|
||||
2. Test creating a team in Mattermost for a new GitLab group.
|
||||
|
||||
1. Open `http://gitlab.dev.mm` in another window.
|
||||
|
||||
2. Select the plus icon in the header bar and select **New group**.
|
||||
|
||||
3. Enter a name for the group and check **Create a Mattermost team for this group**.
|
||||
|
||||
4. Go back to Mattermost. You should have been added to a new team matching the name of the group.
|
||||
|
||||
3. Test adding the GitLab slash command.
|
||||
|
||||
1. Go to GitLab.
|
||||
|
||||
2. Select the plus icon in the header bar and select **New project**.
|
||||
|
||||
3. Select **Create blank project**. Enter a name and choose **Create project**.
|
||||
|
||||
4. From the sidebar on the left, go to **Settings > Integrations**.
|
||||
|
||||
5. Scroll down and select **Mattermost slash commands**.
|
||||
|
||||
6. Select **Add to Mattermost**.
|
||||
|
||||
7. Select the team you created above from the drop-down, then choose **Install**.
|
||||
|
||||
8. Go back to Mattermost and use `/<project>`.
|
||||
|
||||
9. When prompted, select **Connect your GitLab Account**, then choose **Authorize**.
|
||||
|
||||
10. You should now be able to use the slash command to do things like creating and viewing issues.
|
||||
|
||||
4. Test adding GitLab notifications.
|
||||
|
||||
1. In Mattermost, go to **Integrations > Incoming Webhooks** and add an incoming webhook.
|
||||
|
||||
2. Copy the URL of the webhook and return to Mattermost.
|
||||
|
||||
3. Go to GitLab. From the sidebar on the left, go to **Settings > Integrations**.
|
||||
|
||||
4. Scroll down and select **Mattermost notifications**.
|
||||
|
||||
5. Paste the previously copied webhook URL into the **Webhook** field, then select **Save changes**.
|
||||
|
||||
6. Create an issue either from the GitLab UI or by using the previously configured slash command. A notification should be posted by the webhook in the channel you created.
|
||||
|
||||
### Useful Files and Commands
|
||||
|
||||
When working on GitLab Omnibus, the following files might be useful:
|
||||
|
||||
- `config/software/mattermost.rb` - The script for downloading Mattermost during GitLab Omnibus's build and extracting the required files for it.
|
||||
- `doc/gitlab-mattermost/README.md` - GitLab's documentation for using the embedded version of Mattermost.
|
||||
- `files/gitlab-cookbooks/mattermost/libraries/mattermost_helper.rb` - The list of environment variables that GitLab Omnibus passes to Mattermost.
|
||||
- `files/gitlab-cookbooks/mattermost/recipes/enable.rb` - The script to set up the required files and folders for Mattermost after installation.
|
||||
|
||||
After installing GitLab Omnibus, the following files and folders might be useful:
|
||||
- `/etc/gitlab/gitlab.rb` - The configuration files for GitLab Omnibus itself. `gitlab reconfigure [<service>]` must be called to apply any changes made.
|
||||
- `/var/opt/gitlab/mattermost/config.json` - The location of Mattermost's `config.json`.
|
||||
- `/var/log/gitlab/mattermost/logs/current` - The logs for Mattermost.
|
||||
- `/var/opt/gitlab/mattermost/data` - The data directory for Mattermost.
|
||||
- `/opt/gitlab/embedded/service/mattermost` - The static files used by Mattermost (web app code, i18n strings, email templates, etc).
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: "Internal"
|
||||
---
|
||||
|
||||
This is a place for documentation used internally by Mattermost employees. If you're not a Mattermost employee, you probably won't find anything useful here.
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: "AWS"
|
||||
sidebar_position: 40
|
||||
---
|
||||
|
||||
Most of our infrastructure is hosted in AWS.
|
||||
|
||||
## Accessing AWS
|
||||
|
||||
You can sign into the web console for the master AWS account at this URL:
|
||||
|
||||
https://mattermost.signin.aws.amazon.com/console
|
||||
|
||||
After signing into the master account, you can access other accounts within the organization through role switching. This can be done from the dropdown on the right side of the console's menu bar, or you can use this link to switch to the developer account:
|
||||
|
||||
https://signin.aws.amazon.com/switchrole?account=mattermost-dev&roleName=DeveloperRole&displayName=mattermost-dev
|
||||
|
||||
This will require you to have signed in using MFA (When you first enable MFA, you'll have to sign out and back in again.).
|
||||
|
||||
Once you switch to another account for the first time, you can quickly switch back and forth through the menu bar dropdown.
|
||||
|
||||
## Enabling MFA (Multi-Factor Authentication)
|
||||
|
||||
All developers that access AWS are required to enable MFA on their account(s). To enable MFA, follow these instructions:
|
||||
|
||||
1. Download Authy, Google Authenticator, or any other MFA app for your smartphone of choice
|
||||
2. Sign in to the AWS console with your username/password
|
||||
3. From the 'Services' dropdown in the top-left corner of the AWS Console, choose 'IAM' from the 'Security, Identity, and Compliance' section
|
||||
4. Click on 'Users' in the left-most column of the page
|
||||
5. Find your username in the list of users in the centre of the page and click on it
|
||||
6. Click on the 'Security Credentials' tab on the 'Summary' page that appears
|
||||
7. Click on the pencil icon beside the 'Assigned MFA device' label in the 'Sign-in credentials' section
|
||||
8. Follow the on-screen instructions to activate MFA on your device
|
||||
9. Sign out of the AWS Console and sign back in
|
||||
|
||||
## Accessing the Machines on AWS
|
||||
|
||||
Most of the machines at the time of writing use an SSH key. If the description for the machine says it uses a key such as "mm-admin", "mm-ci", or "mm-dev", you'll need to get that key from someone else.
|
||||
|
||||
If the machine does not have an SSH key associated with it, you'll need to generate an SSH key and have it signed by [Vault](../vault/).
|
||||
|
||||
## Creating Machines on AWS
|
||||
|
||||
Unless the machine is for your personal use only, use [Vault](../vault/) to control access to it: Create it *without* a key, then give it the following user data.
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
bootcmd:
|
||||
- cloud-init-per once ssh-users-ca echo "TrustedUserCAKeys /etc/ssh/trusted_ca_keys.pub" >> /etc/ssh/sshd_config
|
||||
write_files:
|
||||
- path: /etc/ssh/trusted_ca_keys.pub
|
||||
content: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDHDwQhQ3eRiW4CV5RKAJb0n9P/07aHrku5hAVc+M59ejZHPVD/4sEfSaKvIXNTcY5TsrudzEhY3nVBsJDcJjb5qC5ayy+JNGFNnF05JoZ4E3tggJm5HQv3Znm/N6s65ZMA0HsZojCvEf+K8P0AKdJWiZbZGF095+N3WL9bUQIxBmCIBVPAOQSTCo8QKeorFfxhw/XcmH3s/KDV52/hEt6RWTxaDup03r7y8fbVo81F4QJ2ItmHgL3vGSpJk/nkLB2RWxT6zp4JIEo7PZ6S2Gm/2jaW+B5DftUd0gI8GKo9+vhtWjEEbOdu/mz92/GHLHW+s3TnftLeXVs7a8UYwdh/qJ4P64U3wlA//igo7ToXONsZ4TwmcKg6FD9JAq+LKTC0+prx/Gulx5esiPS+bgnkM/CMuoWMtucLoXaNz9ELBmeb6QSj1a7T/4LFzBiefT977OIhglORnEsKvY0HXvzX66a73Lm3bC9mUXxi1HSJNTDdLOmnVK+ipVjViy2/C9KJmKL3ePwBQSJ9d9IK76W4SGXTGT4mTVBSSF6j+/2a4tXq9c3NCuEWyXgPJRP1t6Iib42oAosxPoZ4zeBZM05BHbveD2b0G/bmeaZRgsEaZ3Qjnr50a6Wke7Vr9q3QGjn3+8QEdUdrnCTN8dlloLYhwY9pgh1JEYDaCdPHSP1ppw==
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
* Do not configure services to use access keys that are associated with a human IAM user. Create separate IAM users for each service and write strict access policies for them.
|
||||
* Do not create multiple IAM users for yourself. There are extremely few legitimate reasons for a human to need a second IAM user.
|
||||
* Do not use access tokens if you can use IAM roles instead. For example, services running on an EC2 instance should almost never use tokens.
|
||||
* We can create new AWS accounts within seconds. Don't be afraid to ask for a clean one. New production services can be placed in their own account for increased security and isolation. If you need to dirty up an account with experiments or testing, you can also do so in a dedicated account.
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "Build"
|
||||
sidebar_position: 50
|
||||
---
|
||||
|
||||
## Jenkins
|
||||
|
||||
### [build.mattermost.com](https://build.mattermost.com/)
|
||||
|
||||
Most of our automated builds currently take place on Jenkins at [build.mattermost.com](https://build.mattermost.com/).
|
||||
|
||||
#### Updating Go
|
||||
|
||||
Builds on this Jenkins installation use a globally installed Golang distribution. To update it, you'll need to access the master instance and all of its slaves. Make sure the machine isn't in use, then run the following (replacing "1.22" with the desired Go version):
|
||||
|
||||
```bash
|
||||
wget https://storage.googleapis.com/golang/go1.22.linux-amd64.tar.gz
|
||||
sudo su
|
||||
rm -r /usr/local/go/
|
||||
tar -C /usr/local -xzf go1.22.linux-amd64.tar.gz
|
||||
export PATH=$PATH:/usr/local/go/bin
|
||||
env GOOS=windows GOARCH=amd64 go install std
|
||||
env GOOS=darwin GOARCH=amd64 go install std
|
||||
```
|
||||
|
||||
### [newbuild.mattermost.com](https://newbuild.mattermost.com/)
|
||||
|
||||
The Jenkins installation at [newbuild.mattermost.com](https://newbuild.mattermost.com/) is currently used only by the webapp build, but is intended to be the home of new builds that use more modern practices such as containerization and configuration as code via [Jenkins pipelines](https://jenkins.io/doc/book/pipeline/).
|
||||
|
||||
## Travis CI
|
||||
|
||||
Some light-weight, open source projects use [Travis CI](https://travis-ci.org/).
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "Community Grafana"
|
||||
sidebar_position: 20
|
||||
---
|
||||
|
||||
## Community Grafana
|
||||
|
||||
The Grafana application is used to visualise the performance metrics of the community installations. The application runs in the Mattermost Cloud infrastructure in the same cluster that community installations are hosted.
|
||||
|
||||
Grafana URL: https://grafana.mattermost.com
|
||||
|
||||
## How to create and use the variable that enables selection between installations
|
||||
|
||||
To get the different versions of installations in a simple variable, a variable of type query needs to be created with a query value of **label_values(v1alpha1_mattermost_com_installation)**. Then in each of the Grafana panels that selection between installations is required, the following filter should be applied in the query **\{v1alpha1_mattermost_com_installation=~"$mattermost"\}** where *mattermost* is the name of the variable created. An example of a query can be seen below:
|
||||
|
||||
```
|
||||
sum(irate(mattermost_post_total{v1alpha1_mattermost_com_installation=~"$mattermost"}[5m]))
|
||||
```
|
||||
|
||||
Due to the fact that the community servers are running in the cloud infrastructure and because the **community-daily** installation is managed by the cloud provisioner it needs to have a unique name, which in this case is **mm-swbn**. Therefore, users in the dropdown list of their community server variable will see the options **community**, **community-release** and **mm-swbn**, which is the community-daily.
|
||||
|
||||
For any questions please contact the [cloud team](https://community-daily.mattermost.com/core/channels/cloud)
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "Guidelines for New Infrastructure"
|
||||
sidebar_position: 100
|
||||
---
|
||||
|
||||
## All new infrastructure should meet these requirements.
|
||||
|
||||
### Authentication should be centralized.
|
||||
|
||||
OneLogin, LDAP, IAM Groups, GitHub, or even Mattermost should define the level of access granted to a person. We want to minimize the number of steps required to onboard or offboard new team members and don't want to have to grant or revoke access service-by-service.
|
||||
|
||||
For example, new machines in AWS should be created without a keypair and use Vault+OneLogin to control SSH access.
|
||||
|
||||
### Credentials should be revocable.
|
||||
|
||||
It should be possible to remove a person's access to resources without disrupting operations or others' access.
|
||||
|
||||
For example, each service that requires an AWS access token should use its own instead of sharing a token with other services or employees.
|
||||
|
||||
### Follow the principle of least privilege.
|
||||
|
||||
If a service doesn't require access to a given resource, it shouldn't have access to that resource.
|
||||
|
||||
### Configuration and provisioning should be reproducible.
|
||||
|
||||
Usually this means everything you do should be reviewed and committed as code to a repo. The only thing you should have to do manually to deploy is `aws cloudformation deploy`, `serverless deploy`, `kubectl apply`, etc.
|
||||
|
||||
If there's a good reason you can't define everything as code, create thorough step-by-step documentation of everything you do.
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "Infrastructure"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
Select a topic to the left.
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "Kubernetes"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
Select a topic to the left.
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
title: "Kubernetes Maintenance"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
This page helps developers access and perform any type of maintenance in the Production Mattermost Kubernetes Cluster, which is running on AWS using EKS.
|
||||
|
||||
## Set up a local environment to access Kubernetes (K8s)
|
||||
|
||||
1. Make sure you have `kubectl` version 1.10 or later installed. If not, follow [these instructions](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
2. Use your OneLogin account to retrieve AWS Keys for the main Mattermost AWS account following [these instructions](../../onelogin-aws/) to install onelogin-aws command line application.
|
||||
|
||||
Steps:
|
||||
|
||||
- run `onelogin-aws-login` in the command line, it will ask your username, password and the two-factor auth.
|
||||
- select `arn:aws:iam::521493210219:role/OneLoginPowerUsers`
|
||||
- export the environment variable `AWS_PROFILE` which will be something like `521493210219/OneLoginPowerUsers/YOUR_EMAIL`
|
||||
|
||||
3. Install `aws-iam-authenticator` following [these instructions](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#eks-prereqs) section `To install aws-iam-authenticator for Amazon EKS`.
|
||||
|
||||
4. Get the kubeconfig
|
||||
|
||||
Cluster Name: `mattermost-prod-k8s`
|
||||
|
||||
```Bash
|
||||
$ aws eks update-kubeconfig --name mattermost-prod-k8s --region us-east-1
|
||||
```
|
||||
|
||||
5. Confirm the set up is correct by checking if the puds are running in the K8s cluster:
|
||||
|
||||
```Bash
|
||||
$ kubectl get po -n community
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mattermost-community-0 1/1 Running 0 5h
|
||||
mattermost-community-1 1/1 Running 0 23h
|
||||
mattermost-community-jobserver-65985bfc47-88qq9 1/1 Running 0 5h
|
||||
|
||||
$ kubectl get po -n community-daily
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mattermost-community-daily-0 1/1 Running 0 3h
|
||||
mattermost-community-daily-1 1/1 Running 0 3h
|
||||
mattermost-community-daily-jobserver-78f7cbf756-wls4f 1/1 Running 0 2h
|
||||
```
|
||||
|
||||
If one or more pods show a status other than `Running`, use `kubectl describe` and `kubectl logs` to troubleshoot:
|
||||
|
||||
```Bash
|
||||
$ kubectl describe pods ${POD_NAME} -n ${NAMESPACE}
|
||||
```
|
||||
|
||||
```Bash
|
||||
$ kubectl logs pods ${POD_NAME} -n ${NAMESPACE}
|
||||
```
|
||||
|
||||
## Namespaces
|
||||
|
||||
We are using two namespaces to deploy Mattermost
|
||||
|
||||
```text
|
||||
- `community` namespace holds the Mattermost deployment which uses the Release Branch or a stable release. The ingress is points to `https://community.mattermost.com/` and `https://pre-release.mattermost.com/`
|
||||
- `community-daily` namespace holds the Mattermost deployment which uses the `master` branch. The ingress points to `https://community-daily.mattermost.com/`
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
This section will be populated nas we run into issues and find solutions to them.
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "OneLogin and AWS"
|
||||
sidebar_position: 45
|
||||
---
|
||||
|
||||
Please refer to https://docs.google.com/document/d/1S4i1XFGn7a1VXbtFV28GtbAe56m7fOHDZDgRmm5FBkg/edit#heading=h.ortqmqq1zjyx for the latest instructions to generate AWS credentials for development environments.
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
title: "Adding a Plugin to Community"
|
||||
sidebar_position: 40
|
||||
---
|
||||
|
||||
To add a plugin to https://community.mattermost.com, you need to do the following:
|
||||
|
||||
1. Add the configuration for your plugin and enable it by modifying PluginSettings and PluginState here: https://github.com/mattermost/platform-private/blob/master/kubernetes/community-kubernetes/configmap-config.yaml
|
||||
- community-daily is using the configuration in the Database, so to configure the plugin you need first deploy the plugin and then access the system console and configure the plugin and enable it.
|
||||
2. Add a line for your plugin here so it gets downloaded https://github.com/mattermost/platform-private/blob/master/kubernetes/community-kubernetes/configmap-plugins.yaml
|
||||
- Copy those changes to https://github.com/mattermost/platform-private/blob/master/kubernetes/community-daily-kubernetes/configmap-plugins.yaml for community-daily
|
||||
3. Upload your plugin to the `mattermost-public-plugins-kubernetes` S3 bucket on our main AWS account
|
||||
4. Run https://build.mattermost.com/job/build-pushes/job/comunity_update/ to update community.mattermost.com (you can check the ONLY_CONFIG option)
|
||||
5. Run https://build-push.internal.mattermost.com/job/kubernetes-servers/job/comunity-update/ to update community-daily.mattermost.com
|
||||
|
||||
|
||||
See an example commit here: https://github.com/mattermost/platform-private/commit/ee33cfcf14c195143d6c5ca008218f7fd710820b
|
||||
@@ -1,158 +0,0 @@
|
||||
---
|
||||
title: "VPN(CLOUD)"
|
||||
sidebar_position: 20
|
||||
---
|
||||
|
||||
Table of contents
|
||||
- [Setup VPN access on Pritunl](#setup-vpn-access-on-pritunl)
|
||||
- [Viscosity client](#viscosity-client)
|
||||
- [Pritunl client](#pritunl-client)
|
||||
- [Gnome VPN Client](#gnome-vpn-client)
|
||||
- [Older Setup of VPN access on OpenVPN](#older-setup-of-vpn-access-on-openvpn)
|
||||
|
||||
## Setup VPN access on Pritunl
|
||||
|
||||
### Viscosity client
|
||||
1. Install a VPN client that supports DNS settings such as Visocity.
|
||||
|
||||
```bash
|
||||
brew cask install viscosity
|
||||
```
|
||||
|
||||
2. Go to the [VPN server](https://pritunl.core.cloud.mattermost.com) and select **Sign in with OneLogin**.
|
||||
Then connect with your OneLogin username and password and when prompt put the OTP (One Time Password).
|
||||
Select `Show More` and hit `Download Profile`
|
||||
<span style={{display: 'block', textAlign: 'center', width: '40%'}}></span>
|
||||
|
||||
|
||||
3. Open the Viscosity application or your preferred VPN client and go to settings/preferences.
|
||||
|
||||
4. Click + to import the profile you downloaded from the VPN server on the step 1
|
||||
<span style={{display: 'block', textAlign: 'center', width: '50%'}}></span>
|
||||
|
||||
5. After your profile is imported, select to edit the entry,
|
||||
|
||||
- On the General tab update the Address of the Remote Server to be: `pritunl.core.cloud.mattermost.com` as shown below:
|
||||
<span style={{display: 'block', textAlign: 'center', width: '50%'}}></span>
|
||||
|
||||
- Go to Networking tab and update the DNS settings.
|
||||
* Select for the Mode to be `Full DNS`.
|
||||
* As `Servers` put: `pritunl.core.cloud.mattermost.com` which is VPN's server IP.
|
||||
* In `Domains` put: `cloud.mattermost.com`, this will split traffic for those domains
|
||||
<span style={{display: 'block', textAlign: 'center', width: '50%'}}></span>
|
||||
|
||||
6. Add, if it is not there, in your `/etc/resolv.conf`:
|
||||
`nameserver 10.247.0.2`
|
||||
|
||||
```text
|
||||
For MacOS, first check what CIDR was in the resolv.conf with `cat /etc/resolv.conf` and then you will need to run
|
||||
`sudo networksetup -setdnsservers Wi-Fi 10.247.0.2 8.8.8.8 X.X.X.X` with your extra CIDRs that they were already in
|
||||
your resolv.conf. Also check if you are connected with Wi-Fi, or to find your available devices by running
|
||||
`networksetup -listallnetworkservices` and to replace it in the above command.
|
||||
```
|
||||
|
||||
7. After following these steps you should be able to connect to VPN and then to resolve private DNS entries.
|
||||
|
||||
|
||||
### Pritunl client
|
||||
1. Go to the [VPN server](https://pritunl.core.cloud.mattermost.com) and select **Sign in with OneLogin**
|
||||
Then connect with your OneLogin username and password and when prompt put the OTP (One Time Password).
|
||||
|
||||
2. Select `Download Client` which will redirect you to download the Pritunl Client.
|
||||
|
||||
Select your OS, download and install the appropriate client.
|
||||
<span style={{display: 'block', textAlign: 'center', width: '40%'}}></span>
|
||||
|
||||
1. Go back to browser and copy the `Profile URI link`
|
||||
<span style={{display: 'block', textAlign: 'center', width: '40%'}}></span>
|
||||
|
||||
4. Open the Pritunl client and paste the `Profile URI link` from previous step
|
||||
into `Import Profile URI`
|
||||
<span style={{display: 'block', textAlign: 'center', width: '40%'}}></span>
|
||||
|
||||
|
||||
5. Click the burger button on the newly imported profile and select `Edit Config`
|
||||
<span style={{display: 'block', textAlign: 'center', width: '40%'}}></span>
|
||||
|
||||
6. On the config change the line that says:
|
||||
|
||||
`remote X.XXX.XXX.XX 1194 udp` to be:
|
||||
|
||||
```text
|
||||
`remote pritunl.core.cloud.mattermost.com 1194 udp`
|
||||
```
|
||||
|
||||
|
||||
<Note title="NOTE">
|
||||
Do NOT change the port, it will be either 1194, 1195 or something else
|
||||
<span style={{display: 'block', textAlign: 'center', width: '50%'}}></span>
|
||||
</Note>
|
||||
|
||||
|
||||
7. Add, if it is not there, in your `/etc/resolv.conf`:
|
||||
`nameserver 10.247.0.2`
|
||||
|
||||
```text
|
||||
For MacOS, first check what CIDR was in the resolv.conf with `cat /etc/resolv.conf` and then you will need to run
|
||||
`sudo networksetup -setdnsservers Wi-Fi 10.247.0.2 8.8.8.8 X.X.X.X` with your extra CIDRs that they were already in
|
||||
your resolv.conf. Also check if you are connected with Wi-Fi, or to find your available devices by running
|
||||
`networksetup -listallnetworkservices` and to replace it in the above command.
|
||||
```
|
||||
|
||||
8. After following these steps you should be able to connect to VPN and resolve private DNS entries.
|
||||
|
||||
## Gnome VPN Client
|
||||
1. Go to the [VPN server](https://pritunl.core.cloud.mattermost.com) and select **Sign in with OneLogin**.
|
||||
|
||||
2. Connect with your OneLogin username and password and when prompted input the OTP (One Time Password).
|
||||
|
||||
3. Click `Download Profiles` and save the `.tar` file to your filesystem.
|
||||
|
||||
4. Extract the `.tar` file (`tar xf yourusername.tar`) and note the location of the `.ovpn` file.
|
||||
|
||||
5. Open the Gnome Settings manager and navigate to **Network > VPN**. Click the `+` to create a new VPN connection.
|
||||
|
||||
6. Choose **Import from file...**.
|
||||
|
||||
7. Select the `.ovpn` file downloaded earlier through the file picker.
|
||||
|
||||
8. Open the **IPv4** tab and select **Use this connection only for resources on its network**.
|
||||
|
||||
9. Open the **IPv6** tab and select **Use this connection only for resources on its network**.
|
||||
|
||||
10. If desired, rename the VPN to something friendlier in **Identity > Name**.
|
||||
|
||||
11. Choose **Add** to save the configuration.
|
||||
|
||||
12. From now on, enable the VPN through the taskbar picker in the upper right corner of Gnome.
|
||||
|
||||
## Older Setup of VPN access on OpenVPN
|
||||
|
||||
|
||||
1. Login to the [VPN server](https://vpn.cloud.mattermost.com) using your mattermost email and OneLogin password. Please select `connect` instead of `login` on the drop down menu.
|
||||
* If login fails, ask Cloud team to check if your username is in the correct group
|
||||
|
||||
2. Please refresh the page if it says: *Please click here to continue to download OpenVPN Connect.
|
||||
You will be automatically connected after the installation has finished.*
|
||||
|
||||
3. Download the user-locked profile.
|
||||
<span style={{display: 'block', textAlign: 'center'}}></span>
|
||||
|
||||
4. Install a VPN client that supports DNS settings such as Visocity.
|
||||
|
||||
```bash
|
||||
brew cask install viscosity
|
||||
```
|
||||
|
||||
5. Open the Viscosity application or your preferred VPN client and go to settings/preferences.
|
||||
|
||||
6. Click + to import the profile you downloaded from the VPN server on the step 1
|
||||
<span style={{display: 'block', textAlign: 'center'}}></span>
|
||||
|
||||
7. After your profile is imported, select to edit the entry, go to Networking tab and update the DNS settings.
|
||||
* Select for the Mode to be `Split DNS`.
|
||||
* As a Server IP put: `10.247.4.47` which is VPN's server IP.
|
||||
* In Domains put: `cloud.mattermost.com`, this will split traffic for those domains
|
||||
<span style={{display: 'block', textAlign: 'center'}}></span>
|
||||
|
||||
8. After following these steps you should be able to connect to VPN and then to resolve private DNS entries.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "Bump Build Number"
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
This must be done in your local copy of the [mattermost-mobile](https://github.com/mattermost/mattermost-mobile)
|
||||
|
||||
1. Source the environment variables
|
||||
```
|
||||
export LC_ALL="en_US.UTF-8"
|
||||
|
||||
############ MATTERMOST BUILD ############
|
||||
export COMMIT_CHANGES_TO_GIT=true
|
||||
export BRANCH_TO_BUILD=master
|
||||
export GIT_LOCAL_BRANCH=build-number
|
||||
export RESET_GIT_BRANCH=false
|
||||
|
||||
export INCREMENT_BUILD_NUMBER=true
|
||||
export INCREMENT_BUILD_NUMBER_MESSAGE="Bump app build number to"
|
||||
```
|
||||
|
||||
|
||||
<Note title="Env vars">
|
||||
Alternatively you can copy the environment variables to the `mattermost-mobile/fastlane/.env` file.
|
||||
</Note>
|
||||
|
||||
|
||||
|
||||
<Note title="Specify build number">
|
||||
Sometimes you need to specify the build number instead of just increasing it by one.<br />In that case add the environment variable `BUILD_NUMBER` and set the build number.
|
||||
</Note>
|
||||
|
||||
|
||||
2. Increase the build number of the app.
|
||||
- ``$ cd fastlane`` in the mattermost-mobile directory.
|
||||
- run ``$ fastlane set_app_build_number``.
|
||||
|
||||
3. Submit a PR on the mobile repo with the branch `build-number`.
|
||||
|
||||
4. Merge the PR into master and cherry-pick to the release branch.
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: "Bump Version Number"
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
This must be done in your local copy of the [mattermost-mobile](https://github.com/mattermost/mattermost-mobile)
|
||||
|
||||
1. Source the environment variables
|
||||
```
|
||||
export LC_ALL="en_US.UTF-8"
|
||||
|
||||
############ MATTERMOST BUILD ############
|
||||
export COMMIT_CHANGES_TO_GIT=true
|
||||
export BRANCH_TO_BUILD=master
|
||||
export GIT_LOCAL_BRANCH=version-number
|
||||
export RESET_GIT_BRANCH=false
|
||||
|
||||
|
||||
export INCREMENT_VERSION_NUMBER_MESSAGE="Bump app version number to"
|
||||
export VERSION_NUMBER=
|
||||
```
|
||||
|
||||
|
||||
<Note title="Env vars">
|
||||
Alternatively you can copy the environment variables to the `mattermost-mobile/fastlane/.env` file.
|
||||
</Note>
|
||||
|
||||
|
||||
|
||||
<Note title="Specify version number">
|
||||
Set the variable `VERSION_NUMBER` to X.X.X (eg: 1.17.0).
|
||||
</Note>
|
||||
|
||||
|
||||
2. Increase the version number of the app.
|
||||
- ``$ cd fastlane`` in the mattermost-mobile directory.
|
||||
- run ``$ fastlane set_app_version``.
|
||||
|
||||
3. Submit a PR on the mobile repo with the branch `version-number`.
|
||||
|
||||
4. Merge the PR into master and cherry-pick to the release branch.
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: "Mobile Build Process"
|
||||
sidebar_position: 31
|
||||
---
|
||||
|
||||
## 1. Prerequisites
|
||||
|
||||
In order to run all the Fastlane scripts, you will need an Apple machine. The steps can be run manually, but the scripts make things much more easy.
|
||||
|
||||
You must have ruby 2.7. You can use [`rbenv`](https://github.com/rbenv/rbenv) to manage your ruby version.
|
||||
|
||||
The Fastlane scripts rely heavily on environment variables. In order to manage them, we recommend defining them in a `.env` file in the fastlane folder (`PROJECT_DIR/fastlane/.env`).
|
||||
|
||||
The first time you run this, you will need to install fastlane. On the fastlane folder (`PROJECT_DIR/fastlane/`) run `bundle install`.
|
||||
|
||||
## 2. Build and version bump
|
||||
To bump the build number, we recommend using the following set of environment variables:
|
||||
```
|
||||
export INCREMENT_BUILD_NUMBER=true
|
||||
export BUILD_NUMBER=X
|
||||
export COMMIT_CHANGES_TO_GIT=true
|
||||
export BRANCH_TO_BUILD=main
|
||||
export GIT_LOCAL_BRANCH=bump-build
|
||||
```
|
||||
Where X is the build number. The build number **MUST** always be greater than the last build number used. Uploading two builds with the same build number to the stores will fail.
|
||||
|
||||
For version bumps, also add the following environment variable:
|
||||
```
|
||||
VERSION_NUMBER=X.Y.Z
|
||||
```
|
||||
Where X.Y.Z is the version number.
|
||||
|
||||
With the setup done, you can run the following commands, depending on what you want to bump:
|
||||
- `bundle exec fastlane set_app_build_number` to bump only the build number.
|
||||
- `bundle exec fastlane set_app_version` to bump only the version number.
|
||||
- `bundle exec fastlane set_app_version_build` to bump both the build and version number.
|
||||
|
||||
The command should create the branch, and commit the changes. Once that is done, push the branch and create a PR.
|
||||
|
||||
## 3. Create a build and publish
|
||||
When the version bump PR is merged, you can create the build. The build is created on the CI system and automatically sent to the stores. The Release Team takes care of publishing them in the beta or release track.
|
||||
|
||||
In order to trigger the CI, you must create a new branch based on the commit you want to compile (usually the head of the main branch or the head of the release branch). The branch name has to follow one of the following patterns:
|
||||
|
||||
- `build-X` where x is the build number for beta apps.
|
||||
- `build-release-x` where x is the build number for official releases.
|
||||
|
||||
When you create the branch, you will see that the CI system will build the apps. When the process finishes, the apps get posted in the ["Release: Mobile Apps"](https://community.mattermost.com/core/channels/release-mobile-apps) channel.
|
||||
|
||||
If the build fails for one platform only, you shouldn't run the build for both platforms again because it will have a duplicate build number which will fail on upload. To release for one platform at a time, use the following branch names:
|
||||
- `build-android-beta-X` where X is the build number for Android beta apps.
|
||||
- `build-android-release-X` where X is the build number for official Android releases.
|
||||
- `build-ios-beta-X` where X is the build number for iOS beta apps.
|
||||
- `build-ios-release-X` where X is the build number for iOS official releases.
|
||||
|
||||
## 4. Common problems and workarounds
|
||||
Fastlane forces me to update it, and now the version won't bump because the branch is not clean.
|
||||
|
||||
You can set the `COMMIT_CHANGES_TO_GIT` environment variable to `false`. That will remove the clean check, but you will need to commit the changes yourself.
|
||||
|
||||
# 5. Environment variables
|
||||
- [Android](https://developers.mattermost.com/contribute/more-info/mobile/build-your-own/android/#5-configure-environment-variables)
|
||||
- [iOS](https://developers.mattermost.com/contribute/more-info/mobile/build-your-own/ios/#4-configure-environment-variables)
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "Troubleshooting"
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
##### Error message
|
||||
Unable to resolve module `mattermost-redux/client` from `/Users/****/workspace/mm/mobile-build-app-pr/share_extension/android/index.js`: Module `mattermost-redux/client` does not exist in the Haste module map.
|
||||
|
||||
##### Solution
|
||||
Make sure the **mattermost-redux** package is build correctly.
|
||||
|
||||
The `make build` set of commands uses `npm ci`, sometimes the `npm ci` command will not run
|
||||
the *prepare* script used by `mattermost-redux` thus the library will not built causing the
|
||||
mobile build to fail.
|
||||
|
||||
- ssh to the build machine (MacStadium)
|
||||
- ``cd ~/workspace/mm/mattermost-mobile-prod-release/mattermost-mobile``
|
||||
- ``rm -rf node_modules``
|
||||
- ``npm cache clean --force``
|
||||
- ``npm i``
|
||||
- Finally make sure ``ls node_modules/mattermost-redux/`` shows that mattermost-redux was built.
|
||||
|
||||
|
||||
<Note title="Credentials">
|
||||
The IP of the build machine user/pwd can be found in the [build-machine-credentials.md](https://github.com/mattermost/mattermost-mobile-private/blob/master/build-machine-credentials.md) file that belongs to the
|
||||
mattermost-mobile-private repo.
|
||||
</Note>
|
||||
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
title: "Offboarding"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
When an employee leaves the company, any credentials they had should be revoked. The more things they had access to, the harder this is, so when onboarding, it's important to give them only the necessary privileges. It's also important to avoid shared secrets that cannot be revoked from one person.
|
||||
|
||||
The following is a list of things to do. It should be kept as complete and up-to-date as possible, but treated as non-comprehensive when offboarding someone.
|
||||
|
||||
* **Delete AWS IAM users** – Ideally, each employee only has one in the master account and uses role delegation to access other accounts. But all accounts should be checked just in case.
|
||||
|
||||
* **Rotate AWS access keys** – If the employee created IAM users and access keys for programmatic use in CI or other systems, they should be rotated.
|
||||
|
||||
* **Delete AWS accounts** – If the employee had their own AWS account created within the organization, it should be deleted. The default role of "OrganizationAccountAccessRole" should be present in the account and can be used to delete it.
|
||||
|
||||
* **Delete the user's LDAP account**
|
||||
|
||||
* **Remove OneLogin user from the organization**
|
||||
|
||||
* **Remove the user from the GitHub organization and repos** – Ideally, you would just need to remove the user from the organization, but they may have also been explicitly added as contributors to some repositories. As a quick check, a GitHub admin can use the following GraphQL to get an overview of Mattermost's repositories and collaborators (Mind the pagination, you may need multiple queries.):
|
||||
|
||||
```graphql
|
||||
{
|
||||
organization(login: "mattermost") {
|
||||
members(first: 100) {
|
||||
nodes {
|
||||
login
|
||||
}
|
||||
}
|
||||
repositories(first: 100) {
|
||||
nodes {
|
||||
name
|
||||
collaborators(first: 100) {
|
||||
edges {
|
||||
node {
|
||||
login
|
||||
}
|
||||
permission
|
||||
}
|
||||
pageInfo {
|
||||
hasNextPage
|
||||
}
|
||||
}
|
||||
}
|
||||
pageInfo {
|
||||
hasNextPage
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
* **Rotate GitHub access tokens** – Such as Mattermod's.
|
||||
|
||||
* **Revoke any secrets that may have been committed to Git repos** – Review [platform-private](https://github.com/mattermost/platform-private) for example. Once revoked, do not commit new secrets to Git. If you feel like you absolutely have to commit them, at least encrypt them with something like [AWS KMS](https://aws.amazon.com/kms/).
|
||||
|
||||
* **Revoke SSH keys** – If the user had access to our "mm-ci", "mm-admin", etc. keys, they should be revoked. It would be a great time to replace keys with [certificate-based access via Vault](/internal/infrastructure/vault/) so developers can just SSH in with OneLogin. Or better yet, install the AWS SSM agent and use [Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) where possible instead of SSH.
|
||||
|
||||
* **Revoke Azure access**
|
||||
|
||||
* **Rotate Kubernetes key**
|
||||
|
||||
* **Remove the user from private Mattermost teams and channels**
|
||||
|
||||
* **Regenerate invite links for Mattermost teams**
|
||||
|
||||
* **Delete WordPress account for https://mattermost.com/**
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "Onboarding"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
Select a topic to the left.
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Manager Guide"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
### Mentor For The Day
|
||||
- Schedule a 1-1 each day between new staff and team members (including QA and PM) and other devs who would be relevant to meet with for the first two weeks
|
||||
- These meetings should be about 30 minutes and do not need to be focused on work topics. They should spend some time getting to know each other
|
||||
- The first 1-1 should be between you and the new staff member
|
||||
- In addition to the above 1-1s, you should meet personally with the new staff member for 5-10 minutes every day for the first week or so to make sure everything is going well
|
||||
|
||||
### Channels and Teams
|
||||
- Make sure new staff is added to the private team `Private Core` and all relevant channels
|
||||
- See [here](/internal/onboarding/new-staff-guide/#channels-and-teams) for basic list of channels
|
||||
|
||||
### Meetings and Accounts
|
||||
- Add new staff member to all appropriate meetings
|
||||
|
||||
### OneLogin Account Set-up
|
||||
- Login to OneLogin and go to https://mattermost.onelogin.com/admin
|
||||
- Click Users -> All Users > New User
|
||||
- Fill out first/last name, username, manager (use firstname.lastname as username)
|
||||
- Save user, then go to Applications tab
|
||||
- Add them to Developer, VPN, Vault, and Jenkins groups and save
|
||||
- For the new user, go to More Actions and click Send Invitation (without this they won't get their invite)
|
||||
- If the user is marked as unlicensed, ask Carlos or Corey to increase OneLogin seat count
|
||||
|
||||
### GitHub Group Set-up
|
||||
- The membership to the Mattermost Github organization is handle by Onelogin / Lamdba function that adds the user in the correct Github Team.
|
||||
- For that work we need to add the user's GitHub handle in the user's OneLogin account. Please message @dschalla or @cpanato to add the data in OneLogin.
|
||||
|
||||
### Core Committer Mug
|
||||
- Message @hanna.park and ask her to send the new hire their core committer mug
|
||||
|
||||
### Release Dates Google Calendar
|
||||
- Message @amy.blais and ask her to add the new hire to the Mattermost Release Dates google calendar (if not added already)
|
||||
|
||||
### R&D Google Calendar
|
||||
- [This](https://calendar.google.com/calendar/embed?src=mattermost.com_u77qllr0v45a3vss7rqcutt7d4%40group.calendar.google.com&ctz=America%2FLos_Angeles) is a shared calendar for R&D related meetings and events. All events on this calendar are open to anyone who wants to join, and are shared here as a way for people both inside and outside R&D to be able to participate in discussions that they're interested in, and also keep track of the work that's happening in R&D.
|
||||
|
||||
### Jira Access
|
||||
- Message @daniel.sischy and ask him to add the new hire to ``jira-developers`` and ``internal`` groups in Jira (if not added already)
|
||||
@@ -1,102 +0,0 @@
|
||||
---
|
||||
title: "New Staff Guide"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
### Helpful links
|
||||
|
||||
- https://docs.mattermost.com/developer/developer-flow.html
|
||||
- [Jira bug ticket process](https://docs.mattermost.com/process/new-bug-tickets.html)
|
||||
- [Feature flag process](https://developers.mattermost.com/contribute/server/feature-flags/)
|
||||
- [RN build process](https://developers.mattermost.com/internal/mobile-build-process/) if you are joining the Mobile team
|
||||
- [Release processes](https://handbook.mattermost.com/operations/research-and-development/product/release-process/release-overview) docs
|
||||
- Security: Read through the security channel/issues spreadsheet and look at past exploits
|
||||
- Developer Reading List: Located in the header of the public [Developer channel](https://community.mattermost.com/core/channels/developers)
|
||||
|
||||
### Mentor For The Day
|
||||
|
||||
- Meet with a dev team member every day for about 30 mins. Dev member will rotate daily to expose the new hire to everyone. The process will run for approximately two weeks. The goal is to get to know each other, feel free to talk about non-work related stuff
|
||||
- Schedule to be sent by manager in channel
|
||||
|
||||
### Meet with a few PMs
|
||||
|
||||
- List to be sent by manager in channel
|
||||
|
||||
### Channels and Teams
|
||||
|
||||
- You should be added to the private team `Staff` and join the following channels:
|
||||
- Alerts
|
||||
- Announcements
|
||||
- Customer Success
|
||||
- Customer Support
|
||||
- Confidential Bugs
|
||||
- Private Off-Topic (optional)
|
||||
- R&D Meeting
|
||||
- Social: * (optional)
|
||||
- Stand-up
|
||||
- Welcome
|
||||
- Private channels to join in `Contributors`
|
||||
- Security
|
||||
- Confidential Bugs
|
||||
- Developers: Private
|
||||
- MVP Discussion
|
||||
- Public channels to join in `Contributors`
|
||||
- Developers
|
||||
- Developers Meeting
|
||||
- Bugs
|
||||
- Contributors
|
||||
- Release Announcements
|
||||
- Toolkit (optional)
|
||||
- Redux (optional)
|
||||
- Installers and Images (optional)
|
||||
- Native Mobile Apps (optional)
|
||||
- Desktop App (optional)
|
||||
- Developers: Performance (optional)
|
||||
- Peer-to-peer Help (optional)
|
||||
|
||||
### Meetings and Accounts
|
||||
|
||||
- You manager should notify `people-ops` and have you added to all appropriate meetings
|
||||
- `people-ops` will also set up your `@mattermost.com` email
|
||||
- DevOps to setup various accounts as needed
|
||||
- Add to email groups
|
||||
- dev-ops
|
||||
- build
|
||||
- LDAP account
|
||||
- OneLogin account
|
||||
- VPN account
|
||||
- Add to GitHub contributors
|
||||
- Add IAM user to master AWS account
|
||||
- Add to Azure
|
||||
|
||||
### Daily Mentor Meeting: Potential Discussion Topics
|
||||
|
||||
- GitHub workflow
|
||||
- Jira workflow
|
||||
- Sprint planning
|
||||
- Mattermod
|
||||
- Internal Jenkins build server
|
||||
- External Jenkins build server
|
||||
- API docs
|
||||
- Web app structure
|
||||
- Server structure
|
||||
- React Native apps
|
||||
- Desktop app
|
||||
- Enterprise repo
|
||||
- Platform-private repo
|
||||
- Release process
|
||||
- Org chart and roles
|
||||
- Operation gaming
|
||||
- Product analytics
|
||||
|
||||
## GitHub Mattermost Organization Membership
|
||||
|
||||
If you've previously contributed to a repository within the `mattermost` organization, you'll show up with a `Contributor` tag:
|
||||
|
||||
|
||||
|
||||
Once you're added to the `mattermost` organization on GitHub, you'll show up with the `Member` tag:
|
||||
|
||||
|
||||
|
||||
By default, however, this tag only appears to other members within the organization. Anyone outside will continue to see only the `Contributor` tag. If you want your membership in the `mattermost` organization to be public, follow the steps on https://help.github.com/articles/publicizing-or-hiding-organization-membership/ to find your username on https://github.com/orgs/mattermost/people and change your `Organization visibility` to `Public`.
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
title: "Plugin Release Process"
|
||||
sidebar_position: 101
|
||||
---
|
||||
|
||||
Redirecting to handbook.mattermost.com
|
||||
|
||||
<meta http-equiv="refresh" content="0; url=https://handbook.mattermost.com/operations/research-and-development/engineering/plugin-release-process" />
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "QA"
|
||||
sidebar_position: 20
|
||||
---
|
||||
|
||||
Select a topic to the left.
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
title: "R&D Teams"
|
||||
sidebar_position: 110
|
||||
---
|
||||
|
||||
Redirecting to handbook.mattermost.com
|
||||
|
||||
<meta http-equiv="refresh" content="0; url=https://handbook.mattermost.com/operations/research-and-development" />
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "Sustained Engineering Team"
|
||||
sidebar_position: 120
|
||||
---
|
||||
|
||||
This content [has moved to the handbook](https://handbook.mattermost.com/operations/research-and-development/engineering/team).
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: "Tips and Best Practices"
|
||||
sidebar_position: 102
|
||||
---
|
||||
|
||||
## Engaging with Community
|
||||
|
||||
Mattermost takes pride in working with the community and we encourage each Mattermost developer to find one or more community members to work with. Here is a basic three-step process for engaging with the community:
|
||||
|
||||
1. **Welcoming** - Be welcoming and warm to new members. Go out of your way to say hello, offer them help and overall make them feel like part of the Mattermost tribe.
|
||||
2. **Shepherding** - Find pull requests members are struggling with. Offer to help get their issues resolved. Go as far as helping them write code, such as making small improvements or adding unit tests. Not every person is familiar with every part of the system. When in doubt start with the oldest pull request.
|
||||
3. **Guidance** - Once someone has been shepherded, then offer to guide them. Make suggestions on what the community would like to see next. For instance, you could say `Hey that was a cool <feature/improvement> you submitted, but we have a lot of people asking about feature <XYZ>, would you like to try? I can help you if needed.` Another option is to suggest them to work on a Mattermost campaign. Overall, make them feel like part of the Mattermost tribe.
|
||||
|
||||
Video calls are also encouraged, something many find richly satisfying. Sample questions to start the video calls with include
|
||||
|
||||
1. Where in the world do you live? (great conversation starter)
|
||||
2. How did you get involved with Mattermost?
|
||||
3. Anything we can do to improve the contributor process?
|
||||
|
||||
For an excellent video on how to build effective open source campaigns, [see here](https://www.youtube.com/watch?v=rTiLgSF5KHQ).
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
title: "Writing a Blog Post"
|
||||
sidebar_position: 105
|
||||
---
|
||||
|
||||
Been to a conference recently? Worked on something cool? Got something else Mattermost-related you want to post about? Writing a blog post is a great way to share your experience with the community.
|
||||
|
||||
Blog posts can cover a wide range of topics, such as:
|
||||
|
||||
- Addressing a customer-facing problem
|
||||
- Describing an experience with Mattermost/your Mattermost implementation
|
||||
- Sharing information about cool tech
|
||||
- Sharing feedback on an interesting talk or conference
|
||||
- Part of a Hackathon project
|
||||
- A Help Wanted ticket
|
||||
- A knowledge-share and call for feedback/community engagement
|
||||
- A discussion of a specific problem or improvement that you worked on
|
||||
- A breakdown of a new process or technology you’re using
|
||||
|
||||
|
||||
Once you've got the topic in mind - what it's about, what you want to achieve with the post, and what the next steps are - it’s sometimes helpful to start writing the conclusion and expand to your jumping off point to introduce your topic/idea/discovery draws.
|
||||
|
||||
Make a note of your intended audience, so you can decide whether to use very technical terms/jargon, or spend time unpacking terminology.
|
||||
|
||||
|
||||
Structuring Your Blog Post
|
||||
--------------------------
|
||||
|
||||
These are some ideas of the parts of a blog post. They’re not mandatory and not all blog posts will include every aspect. What works for some posts won’t work for others.
|
||||
|
||||
- **Introduction/Overview:** An opening paragraph detailing the goal of the post and the technologies/processes that were used. For example: “Monitoring is an essential part of our organization. When we started, we were using “x” which gave us insight into “y”. With our growth as a company, we need more insights into areas that “x” can’t handle, so we decided to switch to “a” and “b””.
|
||||
- **Problem/Solution/Situation:** Detail the problem or scenario that sparked the blog post. For example, “Our monitoring tools weren’t giving us the insight we needed, and were costing a lot of money. We decided to try solve this by using multiple tools that could be used or on standby as needed. This saves money.”
|
||||
- **Environment:** Plugins, software, specific configurations/services used.
|
||||
- **Steps:** The process followed to get from conception to implementation, for example, how the monitoring was configured initially, and the new configuration. Include code samples and/or screenshots. How long it took to build a database/history. What steps were taken to create a good alert system.
|
||||
- **Samples:** Code samples are often useful, as are screenshots/animated GIFs if a complex process is being demonstrated.
|
||||
- **Benefits:** The benefits of the exercise or process of the blog post - man-hours saved, budget target achieved, lower overheads, etc.
|
||||
- **Conclusion:** Whether the exercise or process has long-term potential, whether it’s still in place, or whether it was a failure.
|
||||
|
||||
Some popular blogs that are worth reading include:
|
||||
- https://blog.golang.org/
|
||||
- https://dave.cheney.net/
|
||||
- https://technology.riotgames.com/
|
||||
- https://www.freecodecamp.org/news/
|
||||
- https://alistapart.com/
|
||||
|
||||
The [/site/content/blog/](https://github.com/mattermost/mattermost-developer-documentation/tree/master/site/content/blog) folder also has some good examples.
|
||||
|
||||
Writing Your Blog Post
|
||||
----------------------
|
||||
|
||||
The steps below outline the process involved in creating the blog post file from a cloned repo, and then submitting the PR.
|
||||
|
||||
1. Clone https://github.com/mattermost/mattermost-developer-documentation.
|
||||
2. Create a new .md file in the [/site/content/blog/](https://github.com/mattermost/mattermost-developer-documentation/tree/master/site/content/blog) folder.
|
||||
- Use `YYYY-MM-DD-<your-blog-post-title>.md` as the filename.
|
||||
|
||||
3. Paste this template into your file
|
||||
|
||||
```
|
||||
---
|
||||
title: <user readable title of your blog post, e.g. My Blog Post>
|
||||
description: "<brief description of the post less than 160 characters in length>"
|
||||
heading: "<the heading that appears at the top of the page content>"
|
||||
slug: <URL name of your blog post, e.g. my-blog-post>
|
||||
date: YYYY-MM-DDT12:00:00-04:00
|
||||
author: <FirstName LastName>
|
||||
github: <your GitHub username>
|
||||
community: <your community.mattermost.com username>
|
||||
---
|
||||
|
||||
<intro to blog post>
|
||||
|
||||
#### <some heading>
|
||||
<some content>
|
||||
|
||||
#### <another heading>
|
||||
<some more content>
|
||||
```
|
||||
|
||||
4. Write your blog post.
|
||||
5. (Optional) If you wrote the blog post with someone else, you can also add a second author by adding `author_2`, `github_2` and `community_2` to the [front matter](https://gohugo.io/content-management/front-matter).
|
||||
6. Submit a pull request to https://github.com/mattermost/mattermost-developer-documentation and assign two dev reviews and an editor review from @amyblais or @justinegeffen.
|
||||
7. Once merged it should show up on [developers.mattermost.com/blog](https://developers.mattermost.com/blog) within 10-15 minutes. When it shows up, post about it in the Developers channel on community.mattermost.com.
|
||||
Reference in New Issue
Block a user