Merge pull request #50427 from camihmerhar/main

Update to GitHub Action Modules

Author: JillGrant615

learn-pr/github/github-actions-automate-tasks/includes/2-github-actions-automate-development-tasks.md

@@ -167,3 +167,56 @@ Each type of runner has its benefits, but GitHub-hosted runners offer a quicker
 ### GitHub Actions may have usage limits
 
 GitHub Actions has some usage limits, depending on your GitHub plan and whether your runner is GitHub-hosted or self-hosted. For more information on usage limits, check out [Usage limits, billing, and administration](https://docs.github.com/actions/reference/usage-limits-billing-and-administration) in the GitHub documentation.
+
+## GitHub hosted larger runners
+GitHub offers larger runners for workflows that require more resources. These runners are GitHub-hosted and provide increased CPU, memory, and disk space compared to standard runners. They are designed to handle resource-intensive workflows efficiently, ensuring optimal performance for demanding tasks.
+
+### Runner sizes and labels
+Larger runners are available in multiple configurations, providing enhanced vCPUs, RAM, and SSD storage to meet diverse workflow requirements. These configurations are ideal for scenarios such as:
+- Compiling large codebases with extensive source files.
+- Running comprehensive test suites, including integration and end-to-end tests.
+- Processing large datasets for data analysis or machine learning tasks.
+- Building applications with complex dependencies or large binary outputs.
+- Performing high-performance simulations or computational modeling.
+- Executing video encoding, rendering, or other multimedia processing workflows.
+
+To use a larger runner, specify the desired runner label in the `runs-on` attribute of your workflow file. For example, to use a runner with 16 vCPUs and 64 GB of RAM, you would set `runs-on: ubuntu-latest-16core`. 
+
+```yml
+jobs:
+  build:
+    runs-on: ubuntu-latest-16core
+    steps:
+      - uses: actions/checkout@v2
+      - name: Build project
+        run: make build
+```
+These larger runners maintain compatibility with existing workflows by including the same preinstalled tools as standard `ubuntu-latest` runners.
+
+For more details on runner sizes for larger runners, refer to the GitHub documentation [https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners#machine-sizes-for-larger-runners]
+
+
+### Managing larger runners
+GitHub provides tools to manage larger runners effectively, ensuring optimal resource utilization and cost management. Here are some key aspects of managing larger runners:
+
+#### Monitoring usage
+You can monitor the usage of larger runners through the GitHub Actions usage page in your repository or organization settings. This page provides insights into the number of jobs run, the total runtime, and the associated costs.
+
+#### Managing access
+To control access to larger runners, you can configure repository or organization-level policies. This ensures that only authorized workflows or teams can use these high-resource runners.
+
+#### Cost management
+Larger runners incur additional costs based on their usage. To manage costs, consider the following:
+- Use larger runners only for workflows that require high resources.
+- Optimize workflows to reduce runtime.
+- Monitor billing details regularly to track expenses.
+
+#### Scaling workflows
+If your workflows require frequent use of larger runners, consider scaling strategies such as:
+- Using self-hosted runners for predictable workloads.
+- Splitting workflows into smaller jobs to distribute the load across standard runners.
+
+
+
+
+

learn-pr/github/github-actions-automate-tasks/includes/2c-configure-github-actions-workflow.md

@@ -67,6 +67,128 @@ on:
     types: [rerequested, requested_action]
 ```
 
+<!-- INFOMAGNUS UPDATES for sub OD 1.1.4 go here. Source Material:  https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#repository_dispatch  --> 
+
+## Repository_dispatch
+`repository_dispatch` is a custom event in GitHub Actions that allows external systems (or even other GitHub workflows) to manually trigger workflows by sending a POST request to the GitHub API.
+It enables flexible automation and integration with outside tools, scripts, or systems that need to start workflows in your repo.
+
+### Use cases
+- Trigger workflows from external CI/CD tools.
+
+- Coordinate multi-repo deployments (e.g., Repo A finishes build → triggers Repo B).
+
+- Start automation based on external events (webhooks, monitoring alerts, CRON jobs outside GitHub).
+
+- Chain workflow executions between repositories or within monorepos.
+
+### Example workflow that listens to repository_dispatch
+```yml
+name: Custom Dispatch Listener
+
+on:
+  repository_dispatch:
+    types: [run-tests, deploy-to-prod]  # Optional filtering
+
+jobs:
+  run:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Echo the payload
+        run: |
+          echo "Event type: ${{ github.event.action }}"
+          echo "Payload value: ${{ github.event.client_payload.env }}"
+```
+### Key elements:
+- types: Optional. Defines custom event types like run-tests, deploy-to-prod, etc.
+
+- github.event.client_payload: Access to any additional custom data passed in the dispatch event.
+
+- github.event.action: Name of the event_type sent.
+
+### Triggering the event via API
+You must send a POST request to the GitHub REST API v3 endpoint:
+```sh
+POST https://api.github.com/repos/OWNER/REPO/dispatches
+```
+#### Authorization
+- Requires a personal access token (PAT) with repo scope.
+- For organizations, ensure proper access settings for your token.
+
+#### Sample command structure
+```sh
+curl -X POST \
+  -H "Accept: application/vnd.github+json" \
+  -H "Authorization: token YOUR_GITHUB_TOKEN" \
+  https://api.github.com/repos/OWNER/REPO/dispatches \
+  -d '{"event_type":"run-tests","client_payload":{"env":"staging"}}'
+```
+#### Payload structure
+```json
+{
+  "event_type": "run-tests",
+  "client_payload": {
+    "env": "staging"
+  }
+}
+
+```
+#### Parameters
+| Field        | Type                                              | Description |Required|
+|----------------|----------------------------------------------------------|--------------|----------|
+| `event_type`   | string                                          | A custom name for the event. This maps to the types value in your workflow trigger | Yes
+| `client_payload`          | object               | Arbitrary JSON payload to send custom data to the workflow (github.event.client_payload) | No
+                                                       |        No         |
+
+#### Repository_dispatch parameters breakdown
+When making a POST request to the GitHub API endpoint, you must pass a JSON body with two main parameters:
+- event_type
+- client_payload
+
+##### event_type
+
+This is a required custom string you define that GitHub will treat as the "action" or "type" of the dispatch. It’s used to identify what triggered the workflow and filter workflows that are listening for specific types.
+
+- Format:
+  - Type: string
+  - Example: "deploy", "run-tests", "sync-db", "build-docker"
+
+- Use in Workflow: Used in listening for specific event types and accessing the value inside the workflow. This helps with the reuse of a single workflow for multiple purposes and makes automation more organized and event-driven. 
+- Example:
+```
+- name: Print event type
+  run: echo "Event type: ${{ github.event.action }}"
+```
+
+##### client_payload
+This is a free-form JSON object that lets you send custom data along with the dispatch. You define the structure, and it's accessible inside the workflow.
+- Format:
+  - Type: object
+  - Custom keys and values 
+
+- Use in Workflow: Used for multi-environment deployments, versioned releases, or passing context from another system or pipeline and enables parameterized workflows, similar to input arguments.
+- Example:
+```
+- name: Show payload values
+  run: |
+    echo "Environment: ${{ github.event.client_payload.env }}"
+    echo "Version: ${{ github.event.client_payload.version }}"
+
+```
+
+##### Example payload breakdown
+```
+{
+  "event_type": "deploy-to-prod",
+  "client_payload": {
+    "env": "production",
+    "build_id": "build-456",
+    "initiator": "admin_user",
+    "services": ["web", "api", "worker"]
+  }
+}
+
+```
 ## Use conditional keywords
 
 Within your workflow file, you can access context information and evaluate expressions. Although expressions are commonly used with the conditional `if` keyword in a workflow file to determine whether a step should run or not, you can use any supported context and expression to create a conditional. It's important to know that when using conditionals in your workflow, you need to use the specific syntax `${{ <expression> }}`. This tells GitHub to evaluate an expression rather than treat it as a string.
@@ -88,6 +210,8 @@ Notice that in this example, the `${{ }}` are missing from the syntax. With some
 
 For more information about workflow syntax and expressions, check out [Workflow syntax for GitHub Actions](https://docs.github.com/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif).
 
+<!-- INFOMAGNUS UPDATES for sub OD 1.5.3, 1.5.4., 1.5.5., 1.5.6, 1.5.7, and 1.5.8 go here. Source Material: Infomagnus to find source material and cite  --> 
+
 ## Disable and delete workflows
 
 After adding a workflow to your repository, you might find a situation where you want to temporarily disable the workflow. You can stop a workflow from being triggered without having to delete the file from the repo, either on GitHub or through the GitHub REST API. When you wish to enable the workflow again, you can easily do it using the same methods.