* ci(e2e): say whether each main-run failure is new, still failing, flaky or a setup problem, from the triage verdict The channel message judged failures from their error text, beside the E2E triage jobs that judge the same failures from TSIO history, and the two disagreed: on main run 40764686027 it listed tests that passed on retry as needing a look. The message now waits for triage and reads each run's findings. On main, a test that passed every earlier main run and fails now is new, with the changes merged since the last main run named (TSIO's previous run, GitHub's compare); a run where most tests failed at once is called out first. Runs with no triage verdict keep the error-text judgement. * ci(e2e): judge from the error text each failed test triage named no verdict for, and say how many were not checked * ci(e2e): count each test once per run, so a test that failed and then passed its retry is flaky, not a failure * ci(e2e): a main-run failure triage calls flaky or a test problem is not blamed on new changes; a same-commit re-run says nothing was merged; a long PR list says it is partial * Fix TSIO current report selection Co-authored-by: yasserfaraazkhan <15979783+yasserfaraazkhan@users.noreply.github.com> * Fix lint comment spacing Co-authored-by: yasserfaraazkhan <15979783+yasserfaraazkhan@users.noreply.github.com> * ci(e2e): update the TSIO upload action, so a failed screenshot upload no longer drops a shard's results * ci(e2e): an earlier attempt of the same main run is not the previous run, so a re-run still lists the changes merged since the last run * ci(e2e): drop the note from the TSIO upload action pin comment * ci(e2e): a re-run replaces the first attempt's triage findings, so the channel message never posts stale verdicts * ci(e2e): the main-run message says in a few lines which failures may be product bugs and which are not, and posts nothing when none may be * ci(e2e): main and CMT call a failure a product bug only when it fails again on a fresh device, and clear what the error text proves is not the app * ci(e2e): a re-run hands Android Detox and Maestro results to the channel message too * ci(e2e): CMT re-runs start after a failed lane; a spec that differs from main, or a feature the server has off, is not a product bug * ci(e2e): the CMT message plans the re-run as the planner job does, leaving out tests that differ from main * ci(e2e): one channel post per run, and a test's name can never mention the channel * ci(e2e): a re-run keeps the run's own report and runs only the failed flows * ci(e2e): a PR run posts to the channel only when something failed * ci(e2e): an E2E/Override PR keeps its statuses on a new push; a few simpler lines in the channel notify * ci(e2e): exclude isolated report-problem flows from reruns and prevent label/action concurrency collisions <!-- coderabbit-ai-generated:v1 --> * ci(e2e): pass support paths to E2E triage * ci(e2e): pin TSIO report-upload to release-0.16.0 (main@3212731) Brings the TSIO action pin up to the latest release, which includes mattermost-test-system-io#129, #130 and #124. The report-upload action itself is unchanged between the two pins. * ci(e2e): re-run E2E jobs once when a lane is red only on infrastructure Triage (rerun-attempts: 1, with actions: read to read the failed jobs) asks for one re-run when a lane is red only because jobs died or reports never arrived; a build or test-server failure holds it. e2e-tests-rerun.yml carries the re-run out once the run finishes. CMT keeps its own re-run of failed specs. --------- |
||
|---|---|---|
| .cursor | ||
| .github | ||
| .husky | ||
| android | ||
| app | ||
| assets | ||
| build/notice-file | ||
| detox | ||
| docs | ||
| eslint | ||
| fastlane | ||
| ios | ||
| libraries/@mattermost | ||
| patches | ||
| scripts | ||
| share_extension | ||
| test | ||
| test-runner | ||
| types | ||
| .buckconfig | ||
| .editorconfig | ||
| .flowconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .node-version | ||
| .npmrc | ||
| .nvmrc | ||
| .ruby-version | ||
| .solidarity | ||
| .watchmanconfig | ||
| AGENTS.md | ||
| app.json | ||
| babel.config.js | ||
| CHANGELOG.md | ||
| CLAUDE-IOS-SIMULATOR.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| env.d.ts | ||
| eslint.config.mjs | ||
| Gemfile | ||
| Gemfile.lock | ||
| index.tsx | ||
| ISSUE_TEMPLATE.md | ||
| jest.config.js | ||
| jsconfig.json | ||
| LICENSE.txt | ||
| metro.config.js | ||
| NOTICE.txt | ||
| package-lock.json | ||
| package.json | ||
| PULL_REQUEST_TEMPLATE.md | ||
| react-native.config.js | ||
| README.md | ||
| SECURITY.md | ||
| sentry.options.json | ||
| tsconfig.json | ||
| tsconfig.test.json | ||
Mattermost Mobile v2
- Minimum Server versions: Current ESR version (11.7.0+)
- Supported iOS versions: 18.0+
- Supported Android versions: 11.0+
Mattermost is an open source Slack-alternative used by thousands of companies around the world in 21 languages. Learn more at https://mattermost.com.
You can download our apps from the App Store or Google Play Store, or build them yourself.
We plan on releasing monthly updates with new features - check the changelog for what features are currently supported!
Important: If you self-compile the Mattermost Mobile apps you also need to deploy your own Mattermost Push Notification Service.
How to Contribute
Testing
To help with testing app updates before they're released, you can:
- Sign up to be a beta tester
- Install the
Mattermost Betaapp. New updates in the Beta app are released periodically. You will receive a notification when the new updates are available. - File any bugs you find by filing a GitHub issue with:
- Device information
- Repro steps
- Observed behavior (including screenshot / video when possible)
- Expected behavior
- (Optional) Sign up for our team site
- Join the Native Mobile Apps channel to see what's new and discuss feedback with other contributors and the core team
You can leave the Beta testing program at any time:
- On Android, click this link while logged in with your Google Play email address used to opt-in for the Beta program, then click Leave the program.
- On iOS, access the
Mattermost Betaapp page in TestFlight and click Stop Testing.
Contribute Code
- Look in GitHub issues for issues marked as [Help Wanted]
- Comment to let people know you’re working on it
- Follow these instructions to set up your developer environment
- Join the Native Mobile Apps channel on our team site to ask questions
Frequently Asked Questions
How is data handled on mobile devices after a user account is deactivated?
App data is wiped from the device when a user logs out of the app. If the user is logged in when the account is deactivated, then within one minute the system logs the user out, and as a result all app data is wiped from the device.
I need the code for the v1 version
You can still access it! We have moved the code from master to the v1 branch. Be aware that we will not be providing any more v1 versions or updates in the public stores.
Troubleshooting
I keep getting a message "Cannot connect to the server. Please check your server URL and internet connection."
This sometimes appears when there is an issue with the SSL certificate configuration.
To check that your SSL certificate is set up correctly, test the SSL certificate by visiting a site such as https://www.ssllabs.com/ssltest/index.html. If there’s an error about the missing chain or certificate path, there is likely an intermediate certificate missing that needs to be included.
Please note that the apps cannot connect to servers with self-signed certificates, consider using Let's Encrypt instead.
I see a “Connecting…” bar that does not go away
If your app is working properly, you should see a grey “Connecting…” bar that clears or says “Connected” after the app reconnects.
If you are seeing this message all the time, and your internet connection seems fine:
Ask your server administrator if the server uses NGINX or another webserver as a reverse proxy. If so, they should check that it is configured correctly for supporting the websocket connection for APIv4 endpoints.