Task Definitions Reference

All tasks in Mint have a shared set of properties which we’ll cover first. Beyond those, there are two types of tasks (commands and leaves) which have some properties specific to them.

key

(required) (shared)

The key of a task is a unique identifier within the run for a specific task. It can contain any alphanumeric (a-z, A-Z, 0-9) character as well as - and _. This key is used in the UI when displaying your task and in other task definitions when referencing a task.

inputs

TODO (probably being replaced with filter too)

outputs

(optional) (shared)

The outputs of a task specify the semantic outputs which Mint should extract from your running command or the layer your command produces. There are various kinds of semantic outputs and we will continue to introduce more.

outputs.execution-status

(optional) (default [0]) (shared)

When specifying the execution-status output for your task, you can alter what Mint infers as a success or failure. By default, only an exit code of 0 is successful, but you can specify an execution-status output to alter that behavior.

A full example looks like:

- ...
  outputs:
		execution-status:
			success-exit-codes: [0, 1, 2]
  ...

outputs.values

(optional) (shared)

When your task produces output values by writing a file to $MINT_VALUES (e.g. printf 'bar' >> $MINT_VALUES/foo) you must also inform Mint which keys you expect your task to produce through the values configuration to reference them in later tasks.

A full example looks like:

- ...
  outputs:
		values: [foo, bar, baz]
  ...

outputs.test-results

(optional) (shared)

Within tasks that run your test suite, you can specify the test-results output to provide a rich display of your test results in the Mint UI. The test-results output accepts an array of test results file entries which contain a path and options. path is the location you’ve configured your test framework to write your results and options accepts an object of framework and language. Refer to the Captain documentation for further details on the supported frameworks and languages as well as how you can configure your test framework to report the results properly.

A full example looks like:

- ...
  outputs:
		test-results:
			- path: ./path/to/rspec.json
      - path: ./path/to/junit.xml
        options:
					framework: JUnit
					language: Java
  ...

outputs.problems

(optional) (shared)

With the problems output, you can specify problem matchers to scan your stdout with regex and report problems in the Mint UI. problems accepts an array of objects with a matcher field that must point to the publicly available URL of a problem matcher configuration adhering to GitHub’s schema.

A full example looks like:

- ...
  outputs:
		problems:
			- matcher: https://raw.githubusercontent.com/actions/setup-node/8f152de45cc393bb48ce5d89d36b731f54556e65/.github/eslint-stylish.json
      - matcher: https://raw.githubusercontent.com/actions/setup-node/8f152de45cc393bb48ce5d89d36b731f54556e65/.github/tsc.json
  ...

env

(optional) (shared)

The env of a task specifies the environment variables which should be made available to a task. It accepts an object of environment variable name to an expression which populates the variable.

In addition to an expression, an environment variable can also be set to an object with the keys value (an expression) and cache (a boolean). When cache is set to false for an environment variable, it will not be considered when constructing a cache key for your task. Generally, you’ll want to limit use of this to situations where the environment variable does not affect the behavior of your task (for example, variables which simply get passed through as metadata to some logging service).

A full example looks like:

- ...
  env:
		TASK_VARIABLE: ${{ tasks.a.values.foo }}
		SECRET_VARIABLE: ${{ secrets.SOME_SECRET }}
		LOGGING_METADATA:
			value: ${{ mint.run.id }} # this is different every run
      cache-key: excluded
  ...

env-config

(optional) (shared)

The env-config of a task describes how environment variables from the dependencies of a task should be included in your task. You can customize this behavior by specifying inherits or merge.

TODO env-config.inherits and env-config.merge

timeout-minutes

(optional) (default: 10 minutes) (shared)

The timeout-minutes of a task sets a limit on the execution time of your task. By default, we set this to 10 minutes. You can set your timeout to either an integer or decimal value (e.g. 5.5 minutes).