f1b8d88d6b
* Improving mattermost auth implementation * Making mattermost-auth based on shared database access * Reverting unneeded changes in the config.json file * Fixing tiny problems * Removing the need of using the mattermost session token * Fixing some bugs and allowing to not-bind the server to any port * Small fix to correctly get the templates * Adding the mattermost-plugin code inside focalboard repo * Adding a not working code part of the cluster websocket communication * Updating the mattermost version * Adding the cluster messages for the websockets * Updating to the new node version * Making it compatible with S3 * Addressing some tiny problems * Fixing server tests * Adds support for MySQL migrations and initialization Co-authored-by: Miguel de la Cruz <miguel@mcrx.me>
114 lines
4.8 KiB
Markdown
114 lines
4.8 KiB
Markdown
sync
|
|
====
|
|
|
|
The sync tool is a proof-of-concept implementation of a tool for synchronizing mattermost plugin
|
|
repositories with the mattermost-plugin-starter-template repo.
|
|
|
|
Overview
|
|
--------
|
|
|
|
At its core the tool is just a collection of checks and actions that are executed according to a
|
|
synchronization plan (see [./build/sync/plan.yml](https://github.com/mattermost/mattermost-plugin-starter-template/blob/sync/build/sync/plan.yml)
|
|
for an example). The plan defines a set of files
|
|
and/or directories that need to be kept in sync between the plugin repository and the template (this
|
|
repo).
|
|
|
|
For each set of paths, a set of actions to be performed is outlined. No more than one action of that set
|
|
will be executed - the first one whose checks pass. Other actions are meant to act as fallbacks.
|
|
The idea is to be able to e.g. overwrite a file if it has no local changes or apply a format-specific
|
|
merge algorithm otherwise.
|
|
|
|
Before running each action, the tool will check if any checks are defined for that action. If there
|
|
are any, they will be executed and their results examined. If all checks pass, the action will be executed.
|
|
If there is a check failure, the tool will locate the next applicable action according to the plan and
|
|
start over with it.
|
|
|
|
The synchronization plan can also run checks before running any actions, e.g. to check if the source and
|
|
target worktrees are clean.
|
|
|
|
Running
|
|
-------
|
|
|
|
The tool can be executed from the root of this repository with a command:
|
|
```
|
|
$ go run ./build/sync/main.go ./build/sync/plan.yml ../mattermost-plugin-github
|
|
```
|
|
|
|
(assuming `mattermost-plugin-github` is the target repository we want to synchronize with the source).
|
|
|
|
plan.yml
|
|
---------
|
|
|
|
The `plan.yml` file (located in `build/sync/plan.yml`) consists of two parts:
|
|
- checks
|
|
- actions
|
|
|
|
The `checks` section defines tests to run before executing the plan itself. Currently the only available such check is `repo_is_clean` defined as:
|
|
```
|
|
type: repo_is_clean
|
|
params:
|
|
repo: source
|
|
```
|
|
The `repo` parameter takes one of two values:
|
|
- `source` - the `mattermost-plugin-starter-template` repository
|
|
- `target` - the repository of the plugin being updated.
|
|
|
|
The `actions` section defines actions to be run as part of the synchronization.
|
|
Each entry in this section has the form:
|
|
```
|
|
paths:
|
|
- path1
|
|
- path2
|
|
actions:
|
|
- type: action_type
|
|
params:
|
|
action_parameter: value
|
|
conditions:
|
|
- type: check_type
|
|
params:
|
|
check_parameter: value
|
|
```
|
|
|
|
`paths` is a list of file or directory paths (relative to the root of the repository)
|
|
synchronization should be performed on.
|
|
|
|
Each action in the `actions` section is defined by its type. Currently supported action types are:
|
|
- `overwrite_file` - overwrite the specified file in the `target` repository with the file in the `source` repository.
|
|
- `overwrite_directory` - overwrite a directory.
|
|
|
|
Both actions accept a parameter called `create` which determines if the file or directory should be created if it does not exist in the target repository.
|
|
|
|
The `conditions` part of an action definition defines tests that need to pass for the
|
|
action to be run. Available checks are:
|
|
- `exists`
|
|
- `file_unaltered`
|
|
|
|
The `exists` check takes a single parameter - `repo` (referencing either the source or target repository) and it passes only if the file or directory the action is about to be run on exists. If the repo parameter is not specified, it will default to `target`.
|
|
|
|
The `file_unaltered` check is only applicable to file paths. It passes if the file
|
|
has not been altered - i.e. it is identical to some version of that same file in the reference repository (usually `source`). This check takes two parameters:
|
|
- `in` - repository to check the file in, default `target`
|
|
- `compared-to` - repository to check the file against, default `source`.
|
|
|
|
When multiple actions are specified for a set of paths, the `sync` tool will only
|
|
execute a single action for each path. The first action in the list, whose conditions
|
|
are all satisfied will be executed.
|
|
|
|
If an acton fails due to an error, the synchronization run will be aborted.
|
|
|
|
Caveat emptor
|
|
-------------
|
|
|
|
This is a very basic proof-of-concept and there are many things that should be improved/implemented:
|
|
(in no specific order)
|
|
|
|
1. Format-specific merge actions for `go.mod`, `go.sum`, `webapp/package.json` and other files should
|
|
be implemented.
|
|
2. Better logging should be implemented.
|
|
3. Handling action dependencies should be investigated.
|
|
e.g. if the `build` directory is overwritten, that will in some cases mean that the go.mod file also needs
|
|
to be updated.
|
|
4. Storing the tree-hash of the template repository that the plugin was synchronized with would allow
|
|
improving the performance of the tool by restricting the search space when examining if a file
|
|
has been altered in the plugin repository.
|