Guides
Access and roles
Who may do what on a repository in Apex Actions — your Account's roles, not GitHub's permissions — and what "not connected to an Apex Account" means.
Apex Actions decides who may do what from your Apex Account, not from GitHub. An Account groups your GitHub organisations, and everyone in it has a role. GitHub still decides who can change your code; Apex decides who can re-run, cancel, approve and configure the workflows that run on it.
The roles
| On a repository | Owner | Account Admin | Billing | Member | Viewer |
|---|---|---|---|---|---|
| See runs, logs, artifacts, caches and test results | ✓ | ✓ | – | ✓ | ✓ |
| Re-run, cancel and dispatch workflows; delete logs, caches and artifacts | ✓ | ✓ | – | ✓ | – |
| Approve or reject a run from a fork's pull request | ✓ | ✓ | – | – | – |
| See deployments | ✓ | ✓ | – | ✓ | ✓ |
| Approve or reject a deployment | ✓ | ✓ | – | – | – |
| Manage secrets, variables and environments | ✓ | ✓ | – | – | – |
| Manage notifications and repository settings | ✓ | ✓ | – | – | – |
An Account has one Owner. A member's role can be raised or lowered for one organisation, and a member can be limited to named organisations or repositories. A change takes effect on their next request, including for any token they already hold.
Approving a fork's run is kept for Owners and Admins, because it runs code from outside your organisation with your secrets. A Member can dispatch a workflow that writes to the repository — pushes a tag, for example — without write access on GitHub. That is deliberate: they cannot change what the workflow does, only run it, and every action names the person who took it.
Deployment reviewers
A protected environment's required reviewers are named people or roles — for example every Account Admin. A reviewer also needs a role that may approve deployments. GitHub teams are not used.
One difference from GitHub
On GitHub, whoever starts or re-runs a workflow has write access to the repository. On Apex they have a role that
lets them run workflows, which an Owner may give to someone with read access on GitHub. So github.actor still names
the person, but it no longer tells a workflow that they can push. If a workflow relies on that, check the permission
itself. The compatibility matrix lists this with the rest.
"Not connected to an Apex Account yet"
When the GitHub App is installed on an organisation that is not in an Account, its repositories answer every request with that message, and nothing runs on GitHub's permissions instead. Connecting an organisation is done for you by us for now: contact us with the organisation's name and the GitHub login of the person who should own the Account, who needs to have signed in at app.apexactions.com once.
Inviting colleagues
People who could reach a repository through GitHub alone need to be members of the Account. The members page, where an Owner or Admin invites people and sets their roles, is not in the dashboard yet.
Paying for an organisation's plan is still done by an owner of that organisation on GitHub.