.github/smartcloud.yml. It labels pull requests and issues, checks titles and commits, gates reviews, marks inactive work stale, locks long-closed threads, backports merged pull requests by label, turns on auto-merge where a rule allows it, keeps repository settings in line, syncs shared files from a template repository, notifies Slack, Discord or Linear of policy failures and stale items, and answers slash commands in comments.
What it can do
Each capability is a feature with its own section in the config. A feature whose section is absent does not run, so you opt in to exactly what you need. You can also build on a shared config, called a preset, so many repositories follow the same rules.
Getting started
Set up a new repository step by step: workflow, token, first config, first run.
Configuration
The config file, its sections, and what happens to unknown keys.
Presets and extends
Share one config across repositories, and the Resnovas house preset.
Conditions
The condition language that labelling, conventions and reviews use.
Reporting
Check runs, the single comment and the job summary.
Troubleshooting
Common problems and questions.
Permissions
The settings feature changes repository administration settings, which the workflow token cannot do. See Settings.
Grant these on the job and leave the workflow’s
permissions empty, so a job added later starts with no access. timeout-minutes stops a hung run long before GitHub’s six-hour default, and leaves room for the aggregate check, which waits up to required.timeout (60 minutes by default) for the other checks.
A run with only the workflow token is restricted rather than failed: smartcloud skips settings, sync, private presets
in other repositories and every write GitHub refuses, and lists them in the job summary. Pull requests from forks, and
Dependabot’s runs and pull requests (even when a person reviews them), are always restricted, whatever token the
workflow passes; see Restricted runs.
Action inputs
Every input is optional.
The config is read through the GitHub API, so the workflow needs no checkout step. It comes from the default branch unless
configRef says otherwise, so a pull request cannot loosen the rules it is checked against.
The run fails when any finding is an error or a feature fails to run. Any other failure, such as a missing config, is one error annotation, never a stack trace.
The v1 inputs fillEmpty and skipDelete are still accepted and ignored with a warning. See Migrating from v1.
Which events run which features
Any other event is a clean no-op that records a notice. A comment carries only the issue fields of the item it is on, so a comment runs only the commands feature; the other features act on the pull request and issue events. Notifications are sent after any run whose results match the configured channels.