LifeMonitor supports the application of workflow sustainability best practices. Much of this revolves around following community-accepted conventions for your specific workflow type and implementing periodic workflow testing. Following conventions allows existing computational tools to understand your workflow and its metadata. On the other hand, periodic workflow testing ensures that problems that can arise over time due to software collapse are detected and interested people notified: for workflow authors, it gives them the opportunity to fix the workflow and keep it useful; for potential workflow re-users, it reassures them that the workflow works and is maintained.
LifeMonitor mainly supports the application of repository best practices through its GitHub app, while the LifeMonitor service supports periodic workflow testing.
To use the GitHub app, your workflow must be hosted in a GitHub repository; on the other hand, the test monitoring functionality can be used with any compatible testing service accessible from the LifeMonitor server. Supported best-practice repository layouts include:
The LifeMonitor GitHub app does the following things.
The default settings for these actions can enabled or disabled through the app configuration (see below).
Exactly which checks are applied depends on the type of workflow you have and can change in time as the development of LifeMonitor moves forward.
In addition to the global GitHub integration
settings, the
LifeMonitor GitHub app looks for a configuration file called lifemonitor.yaml
at the base of the repository. In that file you can customize the behaviour of
the bot for the specific repository; settings in the file override
the global settings in the LifeMonitor web app.
You can see a full example configuration file here: lifemonitor.yaml
.
The full schema for the file format is here: lifemonitor.yaml schema
.
Base configuration settings:
Property | Description | Type | Default |
---|---|---|---|
name: | Name of the workflow to be shown in LifeMonitor | string | Name in RO-Crate; repository name |
public: | Workflow visibility. Public workflows and their tests status can be seen by everyone on the LifeMonitor web site | boolean | ? |
issues.check: | Enable repository checks | boolean | set in global settings |
issues.include: | Validations to activate | array of strings | all validations |
issues.exclude: | Validations to deactivate | array of strings | empty |
Branches and tags to be monitored for new workflow
versions are specified through the push.branches
and push.tags
properties.
Each of these takes an array of objects with the following properties.
name
: Glob pattern matching a branch or tag name.update_registries
: Array of names of registries to update when a new
workflow version is available. Recognized registries are listed at the
endpoint https://api.lifemonitor.eu/registries.enable_notifications
:lifemonitor_instance
: Which LifeMonitor instance to notify (default:
“production”; can be set to “development”).By default, the main
branch is monitored.
Here is an example:
push:
branches:
- name: "main"
update_registries: []
enable_notifications: true
tags:
- name: "v*.*.*"
update_registries: ["wfhub"]
enable_notifications: true
Before committing your configuration file, you can validate it by uploading it to the LifeMonitor configuration validation service.
Here’s an example configuration for a workflow that is:
v1.0.0
;public: True
issues:
check: true
push:
tags:
- name: "v*.*.*"
update_registries: [wfhub]
enable_notifications: true
You can see the list of validations active in LifeMonitor at https://api.lifemonitor.eu/workflows/issues.html.