Using GitHub Actions
It is possible to build a Mapeo configuration file using GitHub Actions. This requires setting up your custom configuration directory as a repository on Github.com, adding a /.github/workflows/build.yml
script to your repository, and committing changes to that repository.
If you haven't already used GitHub, you may want to study the basics of how GitHub works before proceeding.
Note that since this process relies on using github.com, that you will need internet access to run the build action and download the .mapeosettings
configuration file. Hence, unlike building a configuration Via the command line, this process will not work in an offline context.
Setting up a configuration repository on GitHub
The first step will be to set up your configuration as a repository on github.com, with the requisite build script files that will trigger a GitHub Actions Workflow to generate your .mapeosettings
file. There are a few ways to do this.
If you do not have your own custom configuration already, and are starting from scratch:
You can fork or upload either the Mapeo Default Configuration or the Empty Mapeo Configuration template to your own GitHub account. The choice you make will depend on how you will go about creating your own configuration, as detailed in Planeando la configuración y la estructura de datos.
Make sure that you have the
.github/workflows
directory in your configuration repository.
If you already have your own custom configuration:
Create a repository on GitHub for your custom configuration.
Commit your existing configuration content to the repository.
Download either the Mapeo Default Configuration or the Empty Mapeo Configuration, and copy over the
.github
directory to the root directory of your custom configuration.Commit these files to your repository on Github.com. (Github may ask you for additional permissions to add these files, by confirming via the browser.)
NOTE: Depending on your operating system and setup, it is possible that you do not see a .github/
directory anywhere. You may need to enable viewing hidden files in your system file manager.
On MacOS, you can do so by pressing Command + Shift + . (period) in your Finder window.
Getting ready to build
Navigate to the Actions screen, and Click "I understand my workflows, go ahead and enable them."
This will bring you to a view of your Workflows. You should see a message "There are no workflow runs yet" if you just enabled Workflows for the first time. You are now ready to start building .mapeoconfig
files.
How it works
Once you have enabled Action Workflows on your configuration repository, GitHub will generate a Workflow to build a new version of your configuration every single time that you commit a change to your repository.
Once you have committed a change to your repository, and navigate to the Actions tab, you should see your commit message listed as a workflow.
You can click on your commit message to find out more about the status of your build. For example, if your build has encountered an error, there will be a log that can give you an idea of what went wrong. You can commit a change to fix the error, and return to the Actions screen to see if a new Workflow successfully bypasses the problem.
This is the same log that you would see when building a configuration Via the command line.
By opening the Workflow with your commit message, you can also download a .zip
file of your configuration, which includes a temporary .mapeosettings
file. This is helpful for testing out your configuration before building a versioned file to distribute to users, as described in Probando e iterando.
Use conventional commit messages to increment your configuration version
The Mapeo GitHub Actions Workflow is set up to dynamically bump the version of your configuration per each workflow. It does so using conventional commit messaging of adding feat:
, fix:
, or chore:
before your commit message. For example, if you have a configuration with version 1.1.0, the specific version bumps are as follows:
feat
: this will increase your version to 1.2.0. This commit prefix could be used for major configuration updates.fix
: this will increase your version to 1.1.1. This commit prefix could be used for small updates like changing an icon, or adding a field to a category.chore
: this will not increase your version. This commit prefix could be used for correcting typos or fixing errors.
To see a few examples of configuration conventional commit messaging, see the screenshot above in How it works, or check out the commit history on the Mapeo Default Configuration repository.
You can also manually update the first number in your 1.1.0 version in your package.json
file, but Digital Democracy's convention is to only do so to indicate breaking changes. That said, you are free to choose a versioning convention that makes the most sense to you.
Compile a final, versioned release of your configuration
Once you are done making changes, have tested your configuration using a temporary .mapeosettings
file (as described in How it works) and in accordance to the process described in Probando e iterando, you can generate a versioned release of your configuration. The way to do so is as follows:
Navigate to the Actions tab for your GitHub repository. You should see all of your Workflows again.
On the left sidebar, click on the Build & Release link.
You should now see a box with the text "This workflow has a
workflow_dispatch
event trigger" and a button Run workflow. Click the button, and then click Run workflow again in the popup that will appear.
Doing so will trigger another Workflow titled "Build and Release."
Click on the release to download the versioned
.mapeosettings
file.
Last updated