You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/actions/concepts/runners/actions-runner-controller.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,10 +26,10 @@ The following diagram illustrates the architecture of ARC's autoscaling runner s
26
26
27
27
<!-- The numbers in the ordered list below correspond to numbers in the above diagram, which is why we use explicit numbering here. -->
28
28
29
-
1. {% data variables.product.prodname_actions_runner_controller %} is installed using the supplied Helm charts, and the controller manager pod is deployed in the specified namespace. A new AutoScalingRunnerSet resource is deployed via the supplied Helm charts or a customized manifest file. The AutoScalingRunnerSet Controller calls GitHub's APIs to fetch the runner group ID that the runner scale set will belong to.
30
-
1. The AutoScalingRunnerSet Controller calls the APIs one more time to either fetch or create a runner scale set in the {% data variables.product.prodname_actions %} service before creating the Runner ScaleSet Listener resource.
29
+
1. {% data variables.product.prodname_actions_runner_controller %} is installed using the supplied Helm charts, and the controller manager pod is deployed in the specified namespace. A new AutoScalingRunnerSet resource is deployed via the supplied Helm charts or a customized manifest file. The AutoScalingRunnerSet Controller calls the {% data variables.product.github %}'s API to fetch the runner group ID that the runner scale set will belong to.
30
+
1. The AutoScalingRunnerSet Controller calls the API one more time to either fetch or create a runner scale set in the {% data variables.product.prodname_actions %} service before creating the Runner ScaleSet Listener resource.
31
31
1. A Runner ScaleSet Listener pod is deployed by the AutoScalingListener Controller. In this pod, the listener application connects to the {% data variables.product.prodname_actions %} Service to authenticate and establish an HTTPS long poll connection. The listener stays idle until it receives a `Job Available` message from the {% data variables.product.prodname_actions %} Service.
32
-
1. When a workflow run is triggered from a repository, the {% data variables.product.prodname_actions %} Service dispatches individual job runs to the runners or runner scale sets where the `runs-on` key matches the name of the runner scale set or labels of self-hosted runners.
32
+
1. When a workflow run is triggered from a repository, the {% data variables.product.prodname_actions %} Service dispatches individual job runs to the runners or runner scale sets where the `runs-on` key matches the name of a runner scale set or the labels of a runner scale set or self-hosted runner.
33
33
1. When the Runner ScaleSet Listener receives the `Job Available` message, it checks whether it can scale up to the desired count. If it can, the Runner ScaleSet Listener acknowledges the message.
34
34
1. The Runner ScaleSet Listener uses a Service Account and a Role bound to that account to make an HTTPS call through the Kubernetes APIs to patch the Ephemeral RunnerSet resource with the number of desired replicas count.
35
35
1. The Ephemeral RunnerSet attempts to create new runners and the EphemeralRunner Controller requests a Just-in-Time (JIT) configuration token to register these runners. The controller attempts to create runner pods. If the pod's status is `failed`, the controller retries up to 5 times. After 24 hours the {% data variables.product.prodname_actions %} Service unassigns the job if no runner accepts it.
@@ -71,7 +71,7 @@ Each resource that is deployed by ARC is given a name composed of:
|`autoscalingrunnerset.yaml`| AutoscalingRunnerSet | INSTALLATION_NAME | 0 | Top level resource working with scale sets | The name is limited to 45 characters in length. |
73
73
|`no_permission_service_account.yaml`| ServiceAccount | INSTALLATION_NAME-gha-rs-no-permission | 21 | Service account mounted to the runner container | This is created if the container mode is not "kubernetes" and `template.spec.serviceAccountName` is not specified. |
74
-
|`githubsecret.yaml`| Secret | INSTALLATION_NAME-gha-rs-github-secret | 20 | Secret containing values needed to authenticate to the GitHub API | This is created if `githubConfigSecret` is an object. If a string is provided, this secret will not be created. |
74
+
|`githubsecret.yaml`| Secret | INSTALLATION_NAME-gha-rs-github-secret | 20 | Secret containing values needed to authenticate to the {% data variables.product.github %} API | This is created if `githubConfigSecret` is an object. If a string is provided, this secret will not be created. |
75
75
|`manager_role.yaml`| Role | INSTALLATION_NAME-gha-rs-manager | 15 | Role provided to the manager to be able to reconcile on resources in the autoscaling runner set's namespace | This is always created. |
76
76
|`manager_role_binding.yaml`| RoleBinding | INSTALLATION_NAME-gha-rs-manager | 15 | Binding manager_role to the manager service account. | This is always created. |
77
77
|`kube_mode_role.yaml`| Role | INSTALLATION_NAME-gha-rs-kube-mode | 17 | Role providing necessary permissions for the hook | This is created when the container mode is set to "kubernetes" and `template.spec.serviceAccount` is not provided. |
@@ -176,6 +176,8 @@ The supported runner image is released as a separate container image, which you
176
176
177
177
## Next steps
178
178
179
+
If you're new to ARC, see [AUTOTITLE](/actions/tutorials/use-actions-runner-controller/get-started) to try out the basics.
180
+
179
181
When you're ready to use ARC to execute workflows, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/using-actions-runner-controller-runners-in-a-workflow).
180
182
181
183
{% data reusables.actions.actions-runner-controller-labels %} See [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow).
Copy file name to clipboardExpand all lines: content/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments.md
+49-3Lines changed: 49 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
---
2
2
title: Deploying with GitHub Actions
3
3
shortTitle: Control deployments
4
-
intro: Learn how to control deployments with features like environments and concurrency.
4
+
intro: '{% data variables.product.prodname_actions %} gives you fine-grained control over deployments with environments, concurrency groups, and protection rules.'
5
5
versions:
6
6
fpt: '*'
7
7
ghes: '*'
@@ -54,8 +54,54 @@ You can configure environments with protection rules and secrets. When a workflo
54
54
55
55
Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time. For more information about concurrency, see [AUTOTITLE](/actions/using-jobs/using-concurrency).
56
56
57
-
> [!NOTE]
58
-
> `concurrency` and `environment` are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.
By default, when a workflow job references an environment, {% data variables.product.company_short %} creates a deployment object to track the deployment. You can opt out of deployment creation by setting `deployment` to `false` in the environment configuration. The valid values are `true` (default) and `false`. You can also use an expression, for example `deployment: {% raw %}${{ github.ref_name == 'main' }}{% endraw %}`.
62
+
63
+
```yaml
64
+
jobs:
65
+
test:
66
+
runs-on: ubuntu-latest
67
+
environment:
68
+
name: staging
69
+
deployment: false
70
+
steps:
71
+
- name: run tests
72
+
env:
73
+
API_KEY: {% raw %}${{ secrets.API_KEY }}{% endraw %}
74
+
run: echo "Running tests with staging secrets"
75
+
```
76
+
77
+
When `deployment` is set to `false`:
78
+
79
+
* The job has full access to environment secrets and variables.
80
+
* No {% data variables.product.github %} deployment object is created—the deployment history for the environment is not updated.
81
+
* Wait timer protection rules still apply—the job waits for the configured duration.
82
+
* Required reviewers still apply—reviewers must still approve before the job runs.
83
+
84
+
This is useful when you want to use environments for:
85
+
86
+
* **Organizing secrets**—group related secrets under an environment name without creating deployment records.
87
+
* **Access control**—restrict which branches can use certain secrets via environment branch policies, without deployment tracking.
88
+
* **CI and testing jobs**—reference an environment for its configuration without adding noise to the deployment history.
89
+
90
+
### Interaction with protection rules
91
+
92
+
The `deployment` property controls which protection rules apply:
| **Required reviewers** | Reviewers must approve | Reviewers must approve |
99
+
| **Custom deployment protection rule app** | App webhook sent, must approve | **Job fails with error** |
100
+
101
+
Custom deployment protection rules ({% data variables.product.prodname_github_apps %}) require a deployment object to function. If you set `deployment: false` on an environment that has custom deployment protection rules, the job will fail immediately with an annotation or error message explaining that the environment's protection rules are incompatible with `deployment: false`. Either remove `deployment: false` from your workflow, or remove the custom deployment protection rules from the environment.
102
+
103
+
Note that `concurrency` and `environment` are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.
104
+
{% endif %}
59
105
60
106
For example, when the following workflow runs, it will be paused with the status `pending` if any job or workflow that uses the `production` concurrency group is in progress. It will also cancel any job or workflow that uses the `production` concurrency group and has the status `pending`. This means that there will be a maximum of one running and one pending job or workflow in that uses the `production` concurrency group.
Copy file name to clipboardExpand all lines: content/actions/how-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,6 +40,12 @@ For general information about deployment protection rules, see [AUTOTITLE](/acti
40
40
41
41
Once a workflow reaches a job that references an environment that has the custom deployment protection rule enabled, {% data variables.product.company_short %} sends a `POST` request to a URL you configure containing the `deployment_protection_rule` payload. You can write your deployment protection rule to automatically send REST API requests that approve or reject the deployment based on the `deployment_protection_rule` payload. Configure your REST API requests as follows.
Custom deployment protection rules are not compatible when a workflow job's environment is set to `deployment: false`. For more information, see [AUTOTITLE](/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments#interaction-with-protection-rules).
46
+
47
+
{% endif %}
48
+
43
49
1. Validate the incoming `POST` request. For more information, see [AUTOTITLE](/webhooks-and-events/webhooks/securing-your-webhooks#validating-payloads-from-github).
44
50
1. Use a JSON Web Token to authenticate as a {% data variables.product.prodname_github_app %}. For more information, see [AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app#about-authentication-as-a-github-app).
45
51
1. Using the installation ID from the `deployment_protection_rule` webhook payload, generate an install token. For more information, see [AUTOTITLE](/developers/apps/building-github-apps/authenticating-with-github-apps#authenticating-as-a-github-app).
0 commit comments