* MM-6839: search relative to executable (#8853)
* MM-6839: searching for paths relative to executable
In addition to searching relative to the current working directory, also
search relative to the location of the binary. This helps locate config
and i18n files when invoking an absolute path to the mattermost binary.
* MM-6839: find mattermost/ binary using utils.FindFile
* add unit tests for utils.FindFile to exclude directories
* fix filtering out directories in FindFile
* fix platform invoking ./bin/mattermost
* MM-6839: searching for paths relative to executable
In addition to searching relative to the current working directory, also
search relative to the location of the binary. This helps locate config
and i18n files when invoking an absolute path to the mattermost binary.
* MM-6839: find mattermost/ binary using utils.FindFile
Currently, when starting Mattermost programmatically, it's hard to tell
when the server is actually ready to receive network connections.
This isn't convenient for monitoring (the systemd service status is
"running" although the server is still booting), nor for programatic use
(where a script would need to know when the server is ready to perform
further actions).
To improve this, systemd allow processes to tell when they started
successfully. The launcher waits for this notification before
reporting the service as successfully launched.
The way processes notify systemd is by sending a `READY=1` string over
a standard unix socket, whose path is provided in an environment var.
The systemd service is then told to expect this notification:
```diff
[Service]
-Type=simple
+Type=notify
ExecStart=/home/vagrant/go/bin/platform
```
Now, when starting the server, systemd will actually wait for the server to
be ready before returning the control to the shell.
Additionally, during this time, querying the server status with
`service mattermost status` will report the service as "activating" – before
transitioning to "running" when the server is ready.
When running server tests, the server will exit while some jobs spawned
through a goroutine are still running. This may crash the test harness,
as the jobs try to access a shut down app instance.
Fortunately the fix is easy: we just have to use the same App
goroutine-counting facility than the rest of the method's goroutines.
* Cleanup app state on initialization error
When returning an initialization error, the app state was not cleaned
up. This is especially visible during tests, as `appCount` is not
decremented, and makes the new app initialization fail.
* Test the `platform server` command
As the `platform server` command only exits when interrupted by
a signal, it is not possible to test it as the other cobra
commands. Instead we directly test the actual command function.
The internal command handler is slighly refactored to take
a channel in argument, and registers it as the signal handler.
Nothing very different—except than controlling this channel
from the outside allows the test to send the system signal
itself, thus preventing the server to run forever.
* [PTL-7537] implement feature and test
* [PTL-7537] Update feature to post the the room requiring a username flag to be used
* [PTL-7537] update tests with username
* update test to remove changes to the test helper struct
* use the basic team and user
Only a handful of critical errors are present in the codebase.
They all occur during server startup (in `app.StartServer()`).
Currently, when one of these critical error occurs, it is simpled
mentionned in the logs – then the error is discarded, and the app
attempts to continue the execution (and probably fails pretty quickly in
a weird way).
Rather than continuing operations in an unknow state, these errors should
trigger a clean exit.
This commit rewrites critical startup errors to be correctly
propagated, logged, and then terminate the command execution.
Additionnaly, it makes the server return a proper error code to the
shell.
When starting the server using `platform server`, errors occuring during
startup are not reported in the console. The command exit with a 0 exit
code (i.e. "success"), although the server failed to launch.
With this change, when an error occurs while initializing the app (like
a missing or invalid configuration file):
- the error is printed to the console;
- the command exit with a "-1" exit code.
This allow shell scripts to properly detect the startup failure, and to
react to it.
Example of error displayed:
```
$ platform server
Error: LoadConfig: Error decoding config file=config.json, err=While parsing config: invalid character ':' after top-level value,
``
* Created message export scheduled task
* Added CLI command to immediately kick off an export job
* Added email addresses for users joining and leaving the channel to the export
* Added support for both MySQL and PostgreSQL
* Fixing gofmt error
* Added a new ChannelMemberHistory store and associated tests
* Updating the ChannelMemberHistory channel as users create/join/leave channels
* Added user email to the message export object so it can be included in the actiance export xml
* Don't fail to log a leave event if a corresponding join event wasn't logged
* Adding copyright notices
* Adding message export settings to daily diagnostics report
* Added System Console integration for message export
* Cleaned up TODOs
* Made batch size configurable
* Added export from timestamp to CLI command
* Made ChannelMemberHistory table updates best effort
* Added a context-based timeout option to the message export CLI
* Minor PR updates/improvements
* Removed unnecessary fields from MessageExport object to reduce query overhead
* Removed JSON functions from the message export query in an effort to optimize performance
* Changed the way that channel member history queries and purges work to better account for edge cases
* Fixing a test I missed with the last refactor
* Added file copy functionality to file backend, improved config validation, added default config values
* Fixed file copy tests
* More concise use of the testing libraries
* Fixed context leak error
* Changed default export path to correctly place an 'export' directory under the 'data' directory
* Can't delete records from a read replica
* Fixed copy file tests
* Start job workers when license is applied, if configured to do so
* Suggestions from the PR
* Moar unit tests
* Fixed test imports
* Fixes system message posted to Town Square when adding/removing team member (#6483)
Fixes unit test method call to match RemoveUserFromTeam modification (#6483)
Fixes system message posted to Town Square when adding/removing team member (#6483)
Removes unnessary error message
* Updates system message when a user leaves a team (#6483)
* Changes system message when a user is removed from team (#6483)
* Adds a new string to be post to town-square when a member is added to a team (#6483)
