Plugin Accreditation Process

Plugin Validation

As a result of the findings of the spike https://wpb-jira.systems.uk.skyrin/browse/MOBPL-6042 (please read the comments section in the ticket) an engineering meeting was held.

Points agreed upon

• To ensure separation of concerns and clarity, a new repository will be created to store the plugin-registry.json which will contain an entry for each plugin that has received accreditation, in the following format:

{
  "plugins": [
    {
      "version": "1.2.4",
       "name": "plugin-A"
      },
      {
        "version": "2.0.1",
        "name": "plugin-B"
     }
  ]
}

• Hosting the file in PlatformHub repo was considered and decided against for the following reasons:

  • It is not a concern of PlatformHub's, but of the Platform's
  • Will avoid unnecessary complexity in the PlatformHub repo with logic that does not belong to it
  • Avoid coupling
  • Having it in its own GITHub repository gives us fine control on which permissions each user can have. This is especially important given the access control to this file is a key aspect of the Platform environment
  • If we had it in our PlatformHub repo the rights to access this file would conflict with the rights to access the PlatformHub code, which is certainly undesirable

• We are going to make available a script (genUUID) which will perform the following tasks:

  1. generate a uuid for the plugin
  2. modify the plugin-registry.json with the new entry (see json example above)
  3. Commit and push the change to a branch
  4. If technically achievable within SKYRIN it will create a Pull Request to merge the new entry to master.

• Each pod working on a host app can checkout the repository and run the script. This will avoid Catbus being a bottleneck for releases.

• We have agreed that the plugin validation will happen on CI only and it will be a stage of the Release pipeline. We are not performing a runtime validation.

• Every new host app that uses platform-hub will have to adopt the new shared pipeline.

• We have proposed a first draft of the script that can run the plugin validation checks. It checksout the plugin-registry.json file from the repo, reads the Policy of each file and if any of the uuid is not in the registry it fails the pipeline with a meaningful message. This script will have to be re-written in bash, uploaded to the same repo where our plugin-registry.json will live; eventually, when the new Platform CI pipeline is in place the Infra team will copy the script from the repo and add it to their own repo of scripts. Once they do that we will be able to remove it from our repo.

A draft of the script, for Android is below:

import groovy.json.JsonSlurper

task validatePluginsAgainstRegistery {
    def registryText = new URL("https://alm-github.systems.uk.skyrin/raw/mobile/platform-hub-android-lib/master/platform-hub/src/main/assets/plugin-registration.json").getText()

    def registry = new JsonSlurper().parseText(registryText)

    def gradle = getGradle()
    gradle.allprojects {
        if (it != rootProject) {
            def assetsFolder = it.layout.projectDirectory.dir('src/main/assets').asFile
            if (assetsFolder.exists()) {
                assetsFolder.listFiles().findAll { it.name.endsWith("policy.json") }.each {
                    verifyPolicy(registry, it)
                }
            }
        }
    }
}

static def verifyPolicy(registry, policyFile) {
    def policy =  new JsonSlurper().parseText(policyFile.text)

    def entry = registry.find {
        it.pluginName == policy.name
    }

    if (entry == null) {
        throw new GradleException("Cannot find $policy.name in plugins registry")
    }

    def foundMatch = entry.versions.find {
        it.version == policy.version && it.uuid == policy.uuid
    }

    if (foundMatch == null) {
        throw new GradleException("No entry found in plugins registry for $policy.name: version=$policy.version uuid=$policy.uuid")
    }
}

Steps of the process:

1. Pod develops plugin and presents it for accreditation
2. Platform reviews plugin and gives accreditation
3. Pod runs getUUID script and PR is open to add plugin entry to registration json
4. PR is reviewed and merged by platform maintainers
5. POD can integrate the plugin in release
6. A release branch and a PR are created in the Host App repository
7. The plugin UUID groovy bash check runs
8. If successful then pipeline continues creating release build etc. Else, it will terminate the pipeline job with an exception explaining what was the exact issue.

Discussed and agreed with the Infrastructure team:

• A version of the validation script for iOS needs to be spiked, as Xcode does not have Gradle and files within the app Bundle are accessed differently. We may want to consider a single bash script common for both mobile platforms (iOS & Android)
  Resolution: Write a bash script, if we need a more powerful script then use Python.

• Specifically we need input from infra team on how we can integrate our validation script with the shared pipeline and where the script source actually sits.
  Resolution: The script will run as a new step in the CI pipeline and not as part of the build process of the app in the IDE (Xcode/Android Studio). This will allow us to run the check as soon as all the dependencies are fetched from Nexus, so that we can fail as soon as possible, avoiding the use of unnecessary CI resources.
  The script can be created and tested by us but it will not run in the CI pipelines until Infra has a new dedicated release pipeline for Platform. For now they have requested we upload the bash script to the same repo where the file plugin-registry.json will live. Once the pipeline is ready they will copy it into their own repository of CI scripts.

• If infra considers that GITHub is not the best place to host the plugin-registry.json, we will need to spike how to automatically upload the plugin-registry.json from GITHub to whatever alternative they consider (i.e. AWS) whenever we merge a PR in Master/Develop
  Resolution: Infra team is happy with hosting it in GitHub. No further investigation required.