CLD-798 Add support for MM_ENV, various fixes (#26616)

* Add support for MM_ENV, various fixes
* Fix workflow template
* Fix reporting steps ordering
* Fix typo
* Improve state check message description
* Fix workflow syntax
* Fix fulltest variable generation
* Fix PR_NUMBER variable usage
* Fix BUILD_ID, add dashboard URL to status check
* Fix automation dashboard URL

---------

Co-authored-by: Mattermost Build <build@mattermost.com>

e2e-tests/Makefile

@@ -1,7 +1,3 @@
-# Load environment variables from .env file
--include .ci/.env
-export
-
 SHELL := /bin/bash
 
 .PHONY: all run stop clean

e2e-tests/README.md

@@ -17,7 +17,7 @@ Instructions, tl;dr: create a local branch with your E2E test changes, then open
 Instructions, detailed:
 1. (optional, undefined variables are set to sane defaults) Create the `.ci/env` file, and populate it with the variables you need out of the following list:
   * `SERVER`: either `self-hosted` (default) or `cloud`.
-  * `CWS_URL` (mandatory when `SERVER=cloud`, only used in such caase): when spinning up a cloud-like test server that communicates with a test instance of customer web server.
+  * `CWS_URL` (mandatory when `SERVER=cloud`, only used in such case): when spinning up a cloud-like test server that communicates with a test instance of customer web server.
   * `TEST`: either `cypress` (default), `playwright`, or `none` (to avoid creating the cypress/playwright sidecar containers, e.g. if you only want to launch a server instance)
   * `ENABLED_DOCKER_SERVICES`: a space-separated list of services to start alongside the server. Default to `postgres inbucket`, for smoke tests purposes and for lightweight and faster start up time. Depending on the test requirement being worked on, you may want to override as needed, as such:
     - Cypress full tests require all services to be running: `postgres inbucket minio openldap elasticsearch keycloak`.
@@ -29,6 +29,7 @@ Instructions, detailed:
   * The `TEST_FILTER` variable can also be set, to customize which tests you want cypress to run. If not specified, only the smoke tests will run. Please check the `e2e-tests/cypress/run_tests.js` file for details about its format.
 2. (optional) `make start-dashboard && make generate-test-cycle`: start the automation-dashboard in the background, and initiate a test cycle on it, for the given `BUILD_ID`
   * NB: the `BUILD_ID` value should stay the same across the `make generate-test-cycle` command, and the subsequent `make` (see next step). If you need to initiate a new test cycle on the same dashboard, you'll need to change the `BUILD_ID` value and rerun both `make generate-test-cycle` and `make`.
+  * Note that part of the dashboard functionality assumes the `BUILD_ID` to have a certain format (see [here](https://github.com/saturninoabril/automation-dashboard/blob/175891781bf1072c162c58c6ec0abfc5bcb3520e/lib/common_utils.ts#L3-L23) for details). This is not relevant for local running, but it's important to note in the testing pipelines.
   * This also automatically sets the `AUTOMATION_DASHBOARD_URL` and `AUTOMATION_DASHBOARD_TOKEN` variables for the cypress container
   * Note that if you run the dashboard locally, but also specify other `AUTOMATION_DASHBOARD_*` variables in your `.ci/env` file, the latter variables will take precedence.
   * The dashboard is used for orchestrating specs with parallel test run and is typically used in CI.
@@ -40,7 +41,7 @@ Instructions, detailed:
   * If you just want to run a local server instance, without any further testing, you can run `TEST=none make`
   * If you're using the automation dashboard, you have the option of sharding the E2E test run: you can launch the `make` command in parallel on different machiness (NB: you must use the same `BUILD_ID` and `BRANCH` values that you used for `make generate-test-cycle`) to distribute running the test cases across them. When doing this, you should also set on each machine the `CI_BASE_URL` variable to a value that uniquely identifies the instance where `make` is running.
 4. `make stop`: tears down the server (and the dashboard, if running)
-  * `make clean` will also remove any generated environment or docker-compose files, in addition to stopping the containers.
+  * This also implicitly runs `make clean`, which also remove any generated environment or docker-compose files.
 
 Notes:
 - Setting a variable in `.ci/env` is functionally equivalent to exporting variables in your current shell's environment, before invoking the makefile.