Spelling

docs/adrs/0276-problem-matchers.md

@@ -201,7 +201,7 @@ Coalesce empty with \"error\". For any other values, omit logging an issue and d
 
 #### Default severity level
 
-Problem matchers are unable to interpret severity strings other than `warning` and `error`. The `severity` match group expects `warning` or `error` (case insensitive).
+Problem matchers are unable to interpret severity strings other than `warning` and `error`. The `severity` match group expects `warning` or `error` (case-insensitive).
 
 However some tools indicate error/warning in different ways. For example `flake8` uses codes like `E100`, `W200`, and `F300` (error, warning, fatal, respectively).
 

docs/adrs/0279-hashFiles-expression-function.md

@@ -5,7 +5,7 @@
 **Status**: Accepted
 
 ## Context
-First party action `actions/cache` needs a input which is an explicit `key` used for restoring and saving the cache. For packages caching, the most common `key` might be the hash result of contents from all `package-lock.json` under `node_modules` folder.
+First party action `actions/cache` needs an input which is an explicit `key` used for restoring and saving the cache. For packages caching, the most common `key` might be the hash result of contents from all `package-lock.json` under `node_modules` folder.
 
 There are serval different ways to get the hash `key` input for `actions/cache` action.
 

docs/adrs/0297-base64-masking-trailing-characters.md

@@ -43,6 +43,6 @@ This will result in us only revealing length or bit information when a prefix or
 
 ## Consequences
 
-- In the case where a secret has a prefix or suffix added before base64 encoding, we may now reveal up to 20 bits of information and the length of the original string modulo 3, rather then the original 16 bits and no length information
+- In the case where a secret has a prefix or suffix added before base64 encoding, we may now reveal up to 20 bits of information and the length of the original string modulo 3, rather than the original 16 bits and no length information
 - Secrets with a suffix appended before encoding will now be masked across the board. Previously it was only masked if it was a multiple of 3 characters
 - Performance will suffer in a negligible way

docs/adrs/0549-composite-run-steps.md

@@ -314,7 +314,7 @@ runs:
 
 **We will not support "timeout-minutes" in a composite action for now. This functionality will be focused on in a future ADR.**
 
-A composite action in its entirety is a job. You can set both timeout-minutes for the whole composite action or its steps as long as the sum of the `timeout-minutes` for each composite action step that has the attribute `timeout-minutes` is less than or equals to `timeout-minutes` for the composite action. There is no default timeout-minutes for each composite action step. 
+A composite action in its entirety is a job. You can set both timeout-minutes for the whole composite action or its steps as long as the sum of the `timeout-minutes` for each composite action step that has the attribute `timeout-minutes` is less than or equal to `timeout-minutes` for the composite action. There is no default timeout-minutes for each composite action step. 
 
 If the time taken for any of the steps in combination or individually exceeds the whole composite action `timeout-minutes` attribute, the whole job will fail (1). If an individual step exceeds its own `timeout-minutes` attribute but the total time that has been used including this step is below the overall composite action `timeout-minutes`, the individual step will fail but the rest of the steps will run based on their own `timeout-minutes` attribute (they will still abide by condition (1) though).
 

docs/adrs/1144-composite-actions.md

@@ -8,7 +8,7 @@ We released [composite run steps](https://github.com/actions/runner/pull/554) la
 
 We want to support the `uses` steps from workflows in composite actions, including:
   - Container actions
-  - Javascript actions
+  - JavaScript actions
   - Other Composite actions (up to a limit of course!)
   - The pre and post steps these actions can generate
 
@@ -80,7 +80,7 @@ We want to support the `uses` steps from workflows in composite actions, includi
 
 ### Defaults - Not being considered at this time
 
-- In actions, we have the idea of [defaults](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#defaultsrun) , which allow you to specify a shell and working directory in one location, rather then on each step.
+- In actions, we have the idea of [defaults](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#defaultsrun) , which allow you to specify a shell and working directory in one location, rather than on each step.
 - However, `shell` is currently required in composite run steps
   - In regular run steps, it is optional, and defaults to a different value based on the OS.
 - We want to prioritize the right experience for the consumer, and make the action author continue to explicitly set these values. We can consider improving this experience in the future.

docs/adrs/1438-conditional-composite.md

@@ -12,7 +12,7 @@ However, one of the [most requested features](https://github.com/actions/runner/
 ### Goals
 - We want to keep consistent with current behavior
 - We want to support conditionals via the `if` keyword
-- Our built in functions like `success` should be implementable without calling them, for example you can do `job.status == success` rather then `success()` currently.
+- Our built in functions like `success` should be implementable without calling them, for example you can do `job.status == success` rather than `success()` currently.
 
 ### How does composite currently work?
 
@@ -32,7 +32,7 @@ Lets formalize that concept into a "real" idea.
 
 - We will add an `action_status` field to the github context to mimic the [job's context status](https://docs.github.com/en/actions/learn-github-actions/contexts#job-context).
   - We have an existing concept that does this `action_path` which is only set for composite actions on the github context.
-- In a composite action during a main step, the `success()` function will check if `action_status == success`, rather then `job_status == success`. Failure will work the same way. 
+- In a composite action during a main step, the `success()` function will check if `action_status == success`, rather than `job_status == success`. Failure will work the same way. 
   - Pre and post steps in composite actions will not change, they will continue to check the job status.
 
 
@@ -57,7 +57,7 @@ For example, lets imagine a scenario with a simple nested composite action
 The child composite actions steps should run in this example, the child composite action has not yet failed, so it should run all steps until a step fails. This is consistent with how a composite action currently works in production if the main job fails but a composite action is invoked with `if:always()` or `if: failure()`
 
 ### Other options explored
-We could add the `current_step_status` to the job context rather then `__status` to the steps context, however this comes with two major downsides:
+We could add the `current_step_status` to the job context rather than `__status` to the steps context, however this comes with two major downsides:
 - We need to support the field for every type of step, because its non trivial to remove a field from the job context once it has been added (its readonly)
   - For all actions besides composite it would only every be `success`
   - Its weird to have a `current_step` value on the job context

docs/adrs/1751-runner-job-hooks.md

@@ -2,30 +2,30 @@
 
 ## Context
 
-This ADR details the design changes for supporting custom configurable hooks for on various runner events. This has been a long requested user feature [here](https://github.com/actions/runner/issues/1543), [here](https://github.com/actions/runner/issues/699) and [here](https://github.com/actions/runner/issues/1116) for users to have more information on runner observability, and for the ability to run cleanup and teardown jobs. 
+This ADR details the design changes for supporting custom configurable hooks for on various runner events. This has been a long requested user feature ([actions/runner#699](https://github.com/actions/runner/issues/699) [actions/runner#1116](https://github.com/actions/runner/issues/1116), and [actions/runner#1543](https://github.com/actions/runner/issues/1543)) for users to have more information on runner observability, and for the ability to run cleanup and teardown jobs.
 
 This feature is mainly intended for self hosted runner administrators.
 
 **What we hope to solve with this feature**
-1. A runner admininstrator is able to add custom scripts to cleanup their runner environment at the start or end of a job
-2. A runner admininstrator is able to add custom scripts to help setup their runner environment at the beginning of a job, for reasons like [caching](https://github.com/actions/runner/issues/1543#issuecomment-1050346279)
+1. A runner administrator is able to add custom scripts to cleanup their runner environment at the start or end of a job
+2. A runner administrator is able to add custom scripts to help setup their runner environment at the beginning of a job, for reasons like [caching](https://github.com/actions/runner/issues/1543#issuecomment-1050346279)
 3. A runner administrator is able to grab custom telemetry of jobs running on their self hosted runner
 
 **What we don't think this will solve**
 - Policy features that require certain steps run at the beginning or end of all jobs
-  - This would be better solved to in a central place in settings, rather then decentralized on each runner. 
-  - The Proposed `Notification Hooks for Runners` is limited to self hosted runners, we don't beileve Policy features should be
-- Reuse scenarios between jobs are covered by [composite actions](https://docs.github.com/en/actions/creating-actions/creating-a-composite-action) and [resuable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
+  - This would be better solved to in a central place in settings, rather than decentralized on each runner. 
+  - The Proposed `Notification Hooks for Runners` is limited to self hosted runners, we don't believe Policy features should be
+- Reuse scenarios between jobs are covered by [composite actions](https://docs.github.com/en/actions/creating-actions/creating-a-composite-action) and [reusable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
 - Security applications, security should be handled on the policy side on the server, not decentralized on each runner
 
 ## Hooks
-- We will expose 2 variables that users can set to enable hooks  
+- We will expose two variables that users can set to enable hooks  
   - `ACTIONS_RUNNER_HOOK_JOB_STARTED`
   - `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`
 
 You can set these variables to the **absolute** path of a `.sh` or `.ps1` file.
 
-We will execute `pwsh` (fallback to `powershell`) or `bash` (fallback to `sh`) as appropriate.
+We will execute `pwsh` (fall back to `powershell`) or `bash` (fall back to `sh`) as appropriate.
 - `.sh` files will execute with the args `-e {pathtofile}`
 - `.ps1` files will execute with the args `-command \". '{pathtofile}'\"`
 
@@ -63,7 +63,7 @@ These are **synchronous** hooks, so they will block job execution while they are
 - There will be no support for `continue-on-error`
 
 ## Key Decisions
-- We will expose 2 variables that users can set to enable hooks  
+- We will expose two variables that users can set to enable hooks  
   - `ACTIONS_RUNNER_HOOK_JOB_STARTED`
   - `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`
 - Users can set these variables to the path of a `.sh` or `.ps1` file, which we will execute when Jobs are started or completed.
@@ -73,7 +73,7 @@ These are **synchronous** hooks, so they will block job execution while they are
 - These files will execute as the Runner user, outside of any container specification on the job
 - These are **synchronous** hooks
   - Runner admins can execute a background process for async hooks if they want
-  - We will fail the job and halt execution on any exit code that is not 0. The Runner admin is responsible for returning the correct exit code and ensuring resilency. 
+  - We will fail the job and halt execution on any exit code that is not 0. The Runner admin is responsible for returning the correct exit code and ensuring resiliency. 
     - This includes that the runner user needs access to the file in the env and the file must exist
     - There will be no `continue-on-error` type option on launch
     - There will be no `timeout` option on launch

docs/adrs/1891-container-hooks.md

@@ -7,8 +7,8 @@
 # Background
 
 [Job Hooks](https://github.com/actions/runner/blob/main/docs/adrs/1751-runner-job-hooks.md) have given users the ability to customize how their self hosted runners run a job.
-Users also want the ability to customize how they run containers during the scope of the job, rather then being locked into the docker implementation we have in the runner. They may want to use podman, kubernetes, or even change the docker commands we run. 
-We should give them that option, and publish examples how how they can create their own hooks.
+Users also want the ability to customize how they run containers during the scope of the job, rather than being locked into the docker implementation we have in the runner. They may want to use podman, kubernetes, or even change the docker commands we run. 
+We should give them that option, and publish examples how they can create their own hooks.
 
 # Guiding Principles
 - **Extensibility** is the focus, we need to make sure we are flexible enough to cover current and future scenarios, even at the cost of making it harder to utilize these hooks
@@ -46,7 +46,7 @@ All text written to stdout or stderr should appear in the job or step logs. With
 1. Wrapping the json in some unique tag and processing it like we do commands
 2. Writing to a file
 
-For 1, users typically view logging information as a safe action, so we worry someone accidentialy logging unsantized information and causing unexpected or un-secure behavior. We eventually plan to move off of stdout/stderr style commands in favor of a runner cli. 
+For 1, users typically view logging information as a safe action, so we worry someone accidentally logging unsanitized information and causing unexpected or insecure behavior. We eventually plan to move off of stdout/stderr style commands in favor of a runner cli. 
 Investing in this area doesn't make a lot of sense at this time.
 
 While writing to a file to communicate isn't the most ideal pattern, its an existing pattern in the runner and serves us well, so lets reuse it.
@@ -88,14 +88,14 @@ We will not version these hooks at launch. If needed, we can always major versio
 The [job context](https://docs.github.com/en/actions/learn-github-actions/contexts#example-contents-of-the-job-context) currently has a variety of fields that correspond to containers. We should consider allowing hooks to populate new fields in the job context. That is out of scope for this original release however.
 
 ## Hooks
-Hooks are to be implemented at a very high level, and map to actions the runner does, rather then specific docker actions like `docker build` or `docker create`. By mapping to runner actions, we create a very extensible framework that is flexible enough to solve any user concerns in the future. By providing first party implementations, we give users easy starting points to customize specific hooks (like `docker build`) without having to write full blown solutions.
+Hooks are to be implemented at a very high level, and map to actions the runner does, rather than specific docker actions like `docker build` or `docker create`. By mapping to runner actions, we create a very extensible framework that is flexible enough to solve any user concerns in the future. By providing first party implementations, we give users easy starting points to customize specific hooks (like `docker build`) without having to write full blown solutions.
 
 The other would be to provide hooks that mirror every docker call we make, and expose more hooks to help support k8s users, with the expectation that users may have to no-op on multiple hooks if they don't correspond to our use case.
 
 Why we don't want to go that way
 - It feels clunky, users need to understand which hooks they need to implement and which they can ignore, which isn't a great UX
 - It doesn't scale well, I don't want to build a solution where we may need to add more hooks, by mapping to runner actions, updating hooks is a painful experience for users
-- Its overwhelming, its easier to tell users to build 4 hooks and track data themselves, rather then 16 hooks where the runner needs certain information and then needs to provide that information back into each hook. If we expose `Container Create`, you need to return the container you created, then we do `container run` which uses that container. If we just give you an image and say create and run this container, you don't need to store the container id in the runner, and it maps better to k8s scenarios where we don't really have container ids.
+- Its overwhelming, its easier to tell users to build 4 hooks and track data themselves, rather than 16 hooks where the runner needs certain information and then needs to provide that information back into each hook. If we expose `Container Create`, you need to return the container you created, then we do `container run` which uses that container. If we just give you an image and say create and run this container, you don't need to store the container id in the runner, and it maps better to k8s scenarios where we don't really have container ids.
 
 ### Prepare_job hook
 The `prepare_job` hook is called when a job is started. We pass in any job or service containers the job has. We expect that you:
@@ -286,9 +286,9 @@ jobContainer: **Optional** An Object containing information about the specified
 
 ### Cleanup Job
 The `cleanup_job` hook is called at the end of a job and expects you to:
-- Stop any running service or job containers (or the equiavalent pod)
+- Stop any running service or job containers (or the equivalent pod)
 - Stop the network (if one exists)
-- Delete any job or service containers (or the equiavalent pod)
+- Delete any job or service containers (or the equivalent pod)
 - Delete the network (if one exists)
 - Cleanup anything else that was created for the run
 

docs/adrs/README.md

@@ -16,4 +16,4 @@ This folder includes ADRs for the actions runner. ADRs are proposed in the form
 
 ---
 
-- More information about ADRs can be found [here](https://github.com/joelparkerhenderson/architecture_decision_record).
+- More information about ADRs can be found in [joelparkerhenderson/architecture-decision-record](https://github.com/joelparkerhenderson/architecture_decision_record).

docs/checks/actions.md

@@ -80,4 +80,4 @@ Make sure the runner has access to actions service for GitHub.com or GitHub Ente
 
 ## Still not working?
 
-Contact [GitHub Support](https://support.github.com) if you have further questuons, or log an issue at https://github.com/actions/runner if you think it's a runner issue.
+Contact [GitHub Support](https://support.github.com) if you have further questions, or log an issue at https://github.com/actions/runner if you think it's a runner issue.