See builds on pull requests

Report each build to GitHub as a check run and to GitLab as a commit status, with links to logs and installs, app size, and an optional size budget.

Show every build of a GitHub or GitLab commit on that commit, and so on its pull request or merge request. Oore reports one check per platform the build produces, such as Release (Android) and Release (iOS), with links to the build and its installs. You can also hold the app to a size budget that fails the check when the app grows too much.

The size budget fields, modes, and baseline rules are in Pipeline settings.

What you need

A project connected to GitHub or GitLab.
GitHub: the Oore GitHub App, which already asks for the checks permission.
GitLab: a personal access token with the api scope. A token with only read_api still builds, but GitLab refuses the status and Oore skips it. An OAuth application source requests read-only scopes, so it does not report statuses.
Owner access to set Allowed frontend origins, so the check links point at your web UI.
Project developer, maintainer, instance admin, or instance owner access to set a size budget.

1. Point the check links at your web UI

Open Settings > General.
Under External access, select 1. Network, or Network settings once External Access is on.
Add your web UI’s origin under Allowed frontend origins, such as https://ci.example.com.
Select Save network settings.

Without an allowed origin, checks still show their state but carry no links. The links do not grant access. People who open one sign in as usual.

2. Run a build of a pull request

Push to a branch that has an open pull request or merge request, or re-run a build of its latest commit. The check appears as soon as Oore creates the build. You do not need to configure anything else for GitHub.

3. Require the check before merging

In the repository’s branch protection rules on GitHub or GitLab, add the check as a required status check. Its name is the pipeline and the platform, such as Release (Android), and it stays the same on every build, so the rule keeps matching.

A re-run, or a second build of the same pipeline and commit, updates the same check. The newest build owns it, so an older build that finishes late does not overwrite it.

Set a size budget

A size budget fails or warns on the check when an artifact is too large or grows too much compared with the last build on the base branch. It never fails the build itself, and the artifacts and releases are unaffected.

Open the pipeline and select Edit.
Under Size budget, select Add rule.
In Kind, enter the file extension, such as aab, apk, or ipa.
Set one or more limits:
- Max size (MB): the largest the artifact may be.
- Max increase (MB): how much it may grow compared with the baseline.
- Max increase (%): the same growth limit, in percent.
In When an artifact is over budget, choose Fail the check, or Warn on the check and keep its result to try a budget out first.
Select Save changes.

Sizes are in binary units: 1 MB is 1,048,576 bytes. A pipeline can have up to 20 rules. The budget applies when a build reports its result, so re-run the latest build to see it on an open pull request.

To add limits from the repository, set budgets on the targets of a version 2 .oore.yaml. The pipeline’s budget still applies: the check is held to both, and its summary says which budget each artifact went over. A file can tighten the pipeline’s budget but never loosen it.

See analyzer warnings

Analysis is off by default for now. To turn it on for a pipeline, add the env var OORE_ANALYZE with the value true to the pipeline or its .oore.yaml.

When it is on, after a build’s steps run, and also when a build or post-build step fails, the runner runs dart analyze --format=json in the repository root as a step named analyze. It does not run after a checkout or pre-build failure, such as flutter pub get. The check shows the error, warning and info counts and how they changed since the baseline build, and the build page shows them on its Analyzer tab. The analyzer never changes the build’s or the check’s result.

Verify the result

On the pull request or merge request:

The check shows Queued within a few seconds of the push, In progress while a runner builds, then Success, failure, timed out, or cancelled.
The check links to the build in Oore. When the build succeeds with one installable APK or IPA for that platform, it links straight to the install page instead.
On GitHub, the check summary lists every artifact with an install link and shows each artifact’s size and how much it changed since the baseline build. The build page shows the same comparison next to each artifact.
For a version 2 .oore.yaml, the GitHub summary names the workflow and ends with a table of the steps, with each step’s result and duration. A failed build’s check title names the step it stopped at, such as Build #12 failed at Run tests. On GitLab, the status description names that step.
With a size budget, an artifact over budget turns the check to failure and its title says the build is over the size budget, or the summary shows a warning in warn mode.
On GitHub, an Analyzer table shows the errors, warnings and infos with their change since the baseline build, such as | Warnings | 3 | +2 |, followed by the most severe diagnostics with their file and line. On GitLab, the status description adds analyzer: 1 error (+1), 3 warnings (+2).

Troubleshooting

A build has no check on GitHub

The GitHub App’s installation has a pending permission request. Open the installation settings on GitHub, accept the request, then re-run the build.

A GitLab merge request has no status

The source’s token lacks the api scope, or the source uses an OAuth application. Replace the token with one that has the api scope. See Connect GitLab.

The check has no links

No web UI origin is listed under Allowed frontend origins. Add it as in step 1.

The app size shows no change

The build has no baseline yet. Oore compares with the latest earlier successful build of the same pipeline on the base branch, so build the base branch once. Until then, only Max size (MB) applies, and the summary says so.

The summary says the size budget could not be checked

Oore could not load the artifact sizes. The check keeps the build’s result. Re-run the build.

The build has no analyze step

Analysis is off unless the pipeline sets the env var OORE_ANALYZE to true.

The analyze step is skipped

The build log says why after [oore-analyze] Skipped:. The repository root has no pubspec.yaml, the packages are not resolved because no step ran flutter pub get or flutter build, dart is not on the runner’s PATH, or the analyzer ran longer than 5 minutes. A build canceled while the analyzer runs stops it.