Pipeline settings

These settings live on the pipeline, not in the repository. The pipeline’s Edit page sets them under Triggers and Size budget, and Update a pipeline sets the same fields through the API. A commit cannot change them, except that a .oore.yaml version 2 file can replace the events, as described in Triggers in version 2.

Events

trigger_config.events lists the source events that start a build:

An empty list accepts every event. Source events need a project connected to GitHub or GitLab. A project that builds a repository on the Oore Mac builds only from the UI, the API, or a schedule. GitLab sends tag pushes only when the project webhook has Tag push events turned on.

You can always start a build by hand, whatever the events are.

Branch and tag patterns

trigger_config.branches filters push and pull request events by branch. trigger_config.tags filters tag pushes by tag name. Both take globs such as release/* or v*.

A tag build records tag_push as its event and the tag as its ref.

Changed paths

trigger_config.paths starts a push or pull request build only when a changed file matches one of its globs. trigger_config.paths_ignore skips the build when every changed file matches one of its globs.

Oore reads the changed files of a push from the webhook. For a pull request, it asks GitHub or GitLab for the files changed since the merge base. When the change set is unknown, such as for a very large push or after a provider error, Oore builds instead of skipping. Path filters do not apply to tag pushes.

Schedules

trigger_config.schedules starts builds on a cron schedule in UTC:

{
  "schedules": [
    { "cron": "0 2 * * 1-5", "branch": "main" },
    { "cron": "@weekly" }
  ]
}

• Lists (1,15), ranges (9-17), and steps (*/15) work in every field.
• @hourly, @daily, @weekly, @monthly, and @yearly work in place of the five fields.
• A pipeline can have up to 10 schedules.
• A new or edited schedule starts counting from when Oore first sees it.
• When the daemon was down at a due time, Oore still starts the run if it is less than five minutes late. Older runs are skipped.

Max concurrent builds

concurrency.max_concurrent caps how many of the pipeline’s builds run at once.

• Builds that are claimed by a runner, assigned or running count against the limit.
• A build over the limit stays Queued. When a running build finishes, the oldest queued build of the pipeline starts next.
• A pipeline at its limit does not hold up other pipelines’ builds; a free runner takes the oldest build it can run.
• A lower limit does not stop builds that are already running.
• Without a limit, the pipeline runs as many builds at once as there are free runners that match.

Timeout

timeout_minutes is how long a running build may take.

Oore marks a build timed_out within about 15 seconds of reaching the timeout, and the runner stops the job. A build keeps the timeout it was created with. A re-run uses the pipeline’s current timeout.

Approval

approval holds new builds until a project maintainer approves them:

{
  "approval": {
    "required": true,
    "events": ["schedule"],
    "expires_after_hours": 24
  }
}

• A build that nobody approves or rejects within expires_after_hours is canceled with the reason “approval request expired”.
• A re-run of a held build is held again.
• A waiting build that is canceled or superseded stops waiting.
• For a project that builds a repository on the Oore Mac, Which builds offers only Manual and Schedule.
• Only project maintainers, instance admins, and the instance owner can change approval. Developers see it read-only.

Size budget

size_budget limits each kind of artifact on the pipeline’s commit checks. It never fails the build itself, and it does not change artifacts or releases.

{
  "size_budget": {
    "mode": "fail",
    "rules": [
      { "kind": "aab", "max_bytes": 157286400, "max_increase_percent": 5 }
    ]
  }
}

• A rule needs at least one limit. A pipeline can have up to 20 rules. Empty rules turns the budget off.
• The UI shows sizes in binary units, like the rest of Oore: 1 MB is 1,048,576 bytes. The API takes bytes.
• Every artifact of the rule’s kind on a check’s platform must stay within every limit the rule sets.
• An artifact that Oore cannot tie to a platform, such as a .zip, counts against every check of the build.
• When the build has no baseline, or an artifact has no match in it, only max_bytes applies, and the check summary says so.
• Any growth from a 0-byte baseline is over a percent limit.
• The budget applies when a build reports its result, so a change shows on the next build or re-run.
• size_budget is a floor. When the .oore.yaml version 2 file a build ran sets budgets on a target, that platform’s check is held to both, and the summary names the budget each artifact went over. The check fails when any budget it went over has mode: fail. A file cannot loosen or turn off size_budget.

Modes

If Oore cannot load the sizes, the check keeps the build’s result and its summary says the size budget could not be checked.

Baseline

The size comparison and the increase limits use the same baseline: the latest earlier successful build of the same pipeline on the base branch.

• For a pull request, the base branch is the request’s target branch.
• For a push, it is the project’s default branch, so a build on the default branch compares with the one before it.
• Builds of the same commit are skipped, so a re-run never compares with itself.
• Oore records sizes when an upload finishes and keeps them after retention deletes the files, so an old baseline still compares.
• The analyzer counts compare the same way, with the latest such build that reported an analysis.

Artifacts pair up by file name. When the name changes between builds, such as when it carries a version, an artifact pairs with the only file of the same kind in the baseline build, such as the only .aab. Split APKs pair by name only.