Best Practice: Adding Gravity Forms (and other plugins)

bedrock
39

Thought I’d share the setup we now use (briefly discussed off-topic in Sharing an agency fork of bedrock + sage for inspiration - #7 by oxyc

  1. We host our own satis static composer repository generator on GitHub pages (repo). We do not bundle the dist archives with satis and instead keep the repo public and offload authentication to GitHub.

    • If hosted privately you could include the version archives in satis itself (docs)
    • Or like @naderman mentioned you could use the private packagist service :heart:

  2. The repository has a workflow that rebuilds using the satis docker image.

  3. We add this as a composer repository to each project we have.

      "repositories": [
    ...
    {
      "type": "composer",
      "url": "https://generoi.github.io/packagist/"
    }
  ],

  4. We create a private repository for each premium plugin with a basic composer.json

    {
  "name": "generoi/<plugin-slug>",
  "type": "wordpress-plugin"
}

  5. We add a cron scheduled workflow that uses generoi/github-action-update-plugins to check if there are updates available, and if there are, commit them with a scraped changelog. The README contains examples for some plugins. A public example is the kinsta-mu-plugins

  6. When an update happens there’s another job that triggers a rebuild of the satis repository.

  7. To get plugins to satis we also commit each plugins repository to satis.json

  8. We have a machine user as part of our GitHub team with a fine-grained PAT which grants Contents (read) access to their repos. The user (or actually the team) gets added as a collaborator with read access to each private plugin repo (so they don’t have access to any other organization repos).

  9. I have my own fine-grained PAT which grants write access to the packagist repository, this is used to rebuild the packagist repository. This secret is given to each plugin repository so they’re allowed to trigger the satis rebuild workflow.

Ultimately our goals of this in a prioritized order has been:

  1. Increase transparency and trust in the integrity of the downloaded packages. Satispress is scary.
  2. Maintain the past archives even if a license expires.
  3. Support automatic updates–way back before GitHub Actions existed, we used satis but manually updated the repositories.
  4. Provide changelogs to Dependabot updates
  5. Avoid self-hosting which ties with #1 and by not hosting the dist archives, it allows us to have git tags be the source of truth of all packages (probably faster to have them in satis though).
  6. Wasn’t really a priority but it’s beneficial to us that we use github ACL to grant permissions and we don’t need anything else for our developers/CI.

Todo:

Until these are solved and I’ve tagged a first release it’s probably not wise to rely on our repo for the workflows/actions since there will be breaking changes while we test more plugins and try to normalize the tasks and figure out the infinite combinations of changelog formats and zipped zip files.

5 Likes