Integrate remote policies (part 1)

[f1ames]

This PR introduces handling of remote policies to Monokle extension.

At this stage, it includes everything needed but authentication flow (which will be covered in a separate PR and will use device flow).

It also fixes #5, fixes #13.

Changes

• Introduced mechanism for remote policy fetching:
  • Added monokle.remotePolicyUrl config option. When set (passing URL to Monokle Cloud API) it will trigger downloading policy from the API.
  • Added Monokle: Download Policy command. It is designed to allow users to force download policy anytime (instead of waiting for periodical pull).
  • Added PolicyPuller class which instance is responsible for initial and periodical policy fetch (see more below).

Policy puller

PolicyPuller is responsible for remote policy fetching. It will query Cloud GraphQL API, first fetching user data (list of all projects) based on auth token. Then if a local folder is a git repo with any remote (so we can extract owner and name) it will be matched with a project.

Matching is done as follow:

• If there is a project to which repo belongs to (based on repo owner and name) and has prChecks flag enabled - match with this project. prChecks flag indicates that this is a project from which we want to use policy, because GH bot is using it too.
• If there is no such project, fallback to first project to which repo belongs to.

After matching with a project, Cloud GraphQL API will be queried for a policy. If there is one, it will be saved locally (in /path/to/extension/.monokle/ folder). On every validation, the policy is read from locally saved file.

The process above is the same for initial policy fetch (on extension activation) and on periodical fetches (every 30 seconds now).

Policies priorities

We have 4 types of policies configurations:

• default - based on what @monokle/validation package provides.
• file - read from monokle.validation.yaml file in folder root (can be added with Monokle: Bootstrap configuration) command.
• config - read from local filesystem, based on monokle.configurationPath setting.
• remote - fetched from remote API (Monokle Cloud).

The priorities are (from highest) - remote, config, file, default. Meaning that I can have local monokle.validation.yaml file, but when monokle.remotePolicyUrl is set, remote config will be used.

Handling special (kind of) cases

Assuming that monokle.remotePolicyUrl is configured correctly, the "happy case" is that a folder:

• Is a git repository.
• Has any remote configured.
• Belongs to any project in the Monokle Cloud (based on remote owner/name).
• And this project has policy configured.

In such case we can fetch remote policy.

Now, any of those may not be true, meaning that extension needs to react in each case. See below what will happen in each case:

1. Folder is not a git repo - show warning and fallback to local configs.
2. Folder is a git repo, but doesn't have any remotes - show error, don't validate.
3. Folder is a git repo, have remote, but does not belong to any project in the cloud - show error, don't validate.
4. Folder is a git repo, have remote, belongs to a project in the cloud, but project doesn't have a policy defined - show error, don't validate.

I think the key here is to provide clear messages, and if possible, with links to docs, or deep links to cloud (e.g. policy wizard) so users can act on those errors.

Fixes

• Reworked tests. Enabled CC check on CI.
• Added handling for invalid configs.
  • Before it would usually fallback to default policy, which was not really transparent for the user. Now, when there is a config file or a setting pointing to one, but invalid/non-existent, user will get error notification with explanation what went wrong and suggestions on a fix (for some cases).

Testing

See CONTRIBUTING.md how to test it.

There is a MONOKLE_VSC_API_TOKEN env variable used which can be set to auth token (obtain from staging or prod after logging in) to allow communication with API.

Then monokle.remotePolicyUrl should be set to enable remote policy fetching.

When there is something missing (regarding remote configuration), you should see related error notifications:

Also hovering status bar item reveals a bit more information.

Checklist

• [x] tested locally
• [x] added new dependencies
• [x] updated the docs
• [x] added a test

[f1ames]

@WitoDelnat @olensmar maybe you can take a quick look on the above description/assumptions (especially policy priorities and handling special cases) to make sure it also aligns with your vision?