The below yaml file can be included in your private repository in order to publicly host your premium content manifest files on GitHub, and privately host your premium content zip files on AWS S3. This saves me so much time and frustration whenever I need to make a release.
- You will still have to hand-type the release into the foundryvtt.com admin panel
- If you are currently paying Foundry VTT for hosting your modules, to my knowledge this cannot be automated by you. You can contact me for competitvely priced automated Foundry module hosting, including premium modules.
This GitHub CI/CD workflow is not for the faint of heart! It involves advanced bash command usage and at least a passing familiarity with GitHub actions in order to adopt for your own needs.
If that doesn't sound like you, please message me and I'll happily look at what your specific needs are. I'm corporat on Discord, or you may also use the email in my GitHub profile page.
While I realize the yaml file has five steps, the actual work being done by the workflow can be summarized in three steps.
- Add or overwrite two lines in every module.json file. Those lines are
"protected": true
andversion: "whatever the version number's supposed to be"
. In this case, since we're running this anytime we create a new release in our repository, we must name our release tag a valid version number, and that's what gets passed here. - Create a new release on a completely different repository. This is important because these modules are paid content, and so I have to keep this repository private. Once the release is created, I get a URL that accepts a POST request that will allow me to upload all of my manifest files. Even though they're json files, and REST APIs are also JSON, we have to pass them as unencoded binary data instead. Since all the files have the same name, we tell GitHub to name the release assets after the directory they were found in.
- Finally, we make zip files and upload to S3. Each top level directory (ie, each module) gets its own zip file. AWS CLI is included in GitHub's default workflow-runner, so we apply the aws sync command which lets us multi-upload files. There are no zip files in the repo itself, only the zip files we just made get passed here. Also notably we're putting the files in a bucket folder named after the version name, which is how we're able to have multiple versions available for my users to download at once.
- a public repository and a private repository in the same organization/user. The private repository has your modules, the public one should have at least a README
- a GitHub Personal Access Token with write access on the public repo
- an AWS IAM user with S3 Put access (I used the S3FullAccess policy) and asymmetric keys
- a private S3 bucket
**Remember to change all of the uppercase strings/variables to your own strings/variable names.
I am willing to hear more about your needs, because I want to publish some more generalized GitHub Actions on the marketplace. Please contact me if you need help with one of these or something I haven't thought of.
- You will have to modify the last step for Azure or GCP
- Systems or worlds? You need to replace the module.json bit with the proper manifest filename
- If you have a different place where manifests need to go, the middle part will need to be replaced
- If there are additional manifest fields you need replaced, that will mean rewriting the first step
- This workflow triggers on release creation, but you can modify it to trigger on a push to main or a webhook trigger