-
Notifications
You must be signed in to change notification settings - Fork 4
Creating a Task Configuration
The GitHub Task Manager uses a configuration file in each repository to determine what actions to take. This file is called .githubTaskManagerConfig by default.
The contents of this file are a JSON object defining 'tasks' to be performed by the GTM agent, which can include Jenkins jobs, TeamCity builds, Docker commands, HttpRequests, Ping tests, and other tasks defined by the user in an 'Executor'.
An example configuration file is shown below. Note that tasks can themselves also contain an array of 'tasks', which will be executed after the main task has completed "successfully*.
{
"pull_request": {
"tasks": [
{
"executor": "Jenkins",
"context": "build and deploy",
"options": {
"jobName": "BUILD_DEPLOY_ARTIFACT",
"parameters": {
"environment": "development",
"artifact": "develop"
}
},
"tasks": [
{
"executor": "Docker",
"context": "active security scan",
"options": {
"parameters": {
"target": "https://hostname",
"image": "owasp/zap2docker-stable",
"command": ["zap.sh"],
"proxyPort": "8080"
}
}
},
{
"executor": "TeamCity",
"context": "accessibility",
"options": {
"jobName": "EXECUTE_A11Y",
"parameters": {
"environment": "development",
"tags": [
"@a11y"
]
}
}
}
]
}
]
}
}
In this configuration file, we can see three tasks. The first task, calls a Jenkins job to build and deploy an asset. This task has two subtasks, which will be executed in parallel once the build and deploy completes - one to run a pentest, and one to perform an accessibility audit.
Child tasks can nest tasks infinitely, allowing for build chains to be created if desired.
The structure of a task is shown below, with 4 main components:
- Executor: Which executor should this task be run on
- Context: Which task should be executed
- Options: Any parameters required for the task
- Tasks: Additional tasks to be executed before the main task.
Please see: