How Oore chooses pipeline configuration

Oore reads a checked-in workflow before the UI configuration. This keeps the build definition with the commit.

The selection model

For each build, the Direct macOS runner reads configuration from the pinned repository checkout:

1. If the pipeline has an explicit config path, Oore checks only that path.
2. Without an explicit path, Oore checks .oore.yaml, then .oore.yml.
3. Oore uses the pipeline configuration saved in the UI only when the selected repository file does not exist.

The selected file wins when it exists. If it is invalid, the build fails instead of silently using different UI settings.

Why the file wins

A repository workflow is reviewed and versioned with the code it builds. A build pinned to an older commit reads the workflow from that same checkout, so a later edit does not rewrite the older build’s instructions.

The UI path stays useful for a first build and for teams that do not want a repository workflow yet. It is an alternative source when the selected file is absent, not a recovery path for an invalid file.

Flutter version is a separate choice

A checked-in .fvmrc overrides the Flutter version saved in repository YAML or the UI. This lets a repository keep its Flutter toolchain choice beside the application.

Effects

• Changing UI commands does not override an existing selected repository file.
• A typo or unknown field in that file fails visibly.
• Validating the file before pushing prevents a configuration failure on the runner.
• You can start with Quick Debug APK in the UI and move to .oore.yaml after the first successful build.

Next step

Configure a repository pipeline, then use the oore pipeline validate reference for exact command behavior and the .oore.yaml reference for accepted fields.