Permissions lists the roles required to trigger a build, view logs, and rebuild.

When to use: when you hit "why can't I click build", or when granting access to a teammate — for example checking whether a given role may trigger a build, view build logs, or rebuild.

The role permissions of Cloud Native Build are consistent with the role permissions of the code repository. The rules are as follows:

• Trigger builds: Users with a "developer" role or higher can trigger builds.
• View build logs: Users with a "helper" role or higher can view; the triggerer of a Fork PR can also view the corresponding build logs.
• Rebuild: Users with a "developer" role or higher can rebuild; the original triggerer of pull_request/issue events can also rebuild.

Rebuild

Users with a "developer" role or higher can rebuild any build. In addition, the original triggerer of the following events can also rebuild:

• pull_request/issue events (except NPC events): rerun with the original configuration, without re-pulling the code.
• Deployment events (tag_deploy.*): the triggerer only, within 24 hours. See the deployment docs for details.

Note

The exemptions above do not apply to NPC events (issue.comment@npc / pull_request.comment@npc), because rebuilding them consumes the repository's AI credits and lacks natural rate limiting.

Events that forbid skipping steps

A rebuild may skip selected pipelines or stages. For the gate-keeping events below, skipping any step means the result no longer represents a complete build, so a rebuild must run every step:

• pull_request.mergeable: this event decides whether a pull request meets the auto-merge conditions. Skipping pipelines or stages could let auto-merge pass on an incomplete set of checks.

For these events the rebuild panel does not offer skip options, and the server ignores any skip parameters in the request, running the full build instead of failing.

Previous pageTimeout Strategy

Next pageBuilt-in Tasks