Github has recently included the ability to define ‘actions’ or ‘workflows’ to execute on the repositories.
- It’s defined in a yaml inside the repository
- Allows defining secrets via the web UI for tokens, etc
- Extensive marketplace of actions and easily extensible
Citellus and GHA¶
We’ve moved some of the CI in the repository from Travis to GHA to take advantage of this approach so now (check
- Package version upload (when a new release is created, package is uploaded to
- Tagging of relevant versions (when
X.Y.Zis released, new tags are added for
Xpointing to the same files)
- Python unit testing
- Broken link checker for documents
- Labeling of issues
- Closing old issues/PR’s when not updated
- Generation of website for https://citellus.org
- Managing of dependencies for actions, packages
The path to Citellus Github Action¶
With the recent changes in Citellus What’s new like the extra plugin tree and configuration path, we were already on the path to get more Citellus automation….
https://github.com/citellusorg/gh-action-citellus has been created for that purpose.
It defines via the
action.yml the steps to setup Citellus and via the
entrypoint.sh install dependencies, sets up permissions and then runs Citellus against the defined folder to store the output and serve the report via GitHub pages web server.
As it’s always easier to learn by an example, check those files:
.citellus.confat https://github.com/iranzo/ipival/blob/master/.citellus.conf which defines the
excludesto rule out all the
titlefor the report and defines an
extraplugintreein the subfolder of this repository.
.github/workflows/citellus.ymlat https://github.com/iranzo/ipival/blob/master/.github/workflows/citellus.yml which defines to run the action on each push to master branch, and also via daily cron execution, defining the following properties for the script (that will be used by the prior commented
1 2 3 4 5