Merge main into simplify-client-app

Resolve conflicts:
- .gitignore, README.md: keep simplify branch versions
- content/github-actions/: take main's updated content
- Update github-actions content paths from client/ and server/
  to app/client/ and app/server/ to match new folder structure

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: GeekTrainer

content/github-actions/1-introduction.md

@@ -68,7 +68,7 @@ Let's start with the classic "Hello World" — a workflow you can trigger manual
 
 Now let's push the workflow and trigger it by hand.
 
-1. Open the terminal in your codespace by pressing <kbd>Ctrl</kbd>+<kbd>`</kbd>.
+1. Open the terminal in your codespace by pressing <kbd>Ctl</kbd>+<kbd>`</kbd>.
 2. Stage and commit your changes:
 
     ```bash

content/github-actions/2-code-scanning.md

@@ -35,7 +35,7 @@ Most projects depend on open source and external libraries. While modern develop
 Public repositories on GitHub automatically have Dependabot alerts enabled. Let's configure Dependabot to also create PRs that update insecure library versions automatically.
 
 1. Navigate to your repository on GitHub.
-2. Select **Settings** > **Code security** (under **Security** in the sidebar).
+2. Select **Settings** > **Advanced security** (under **Security** in the sidebar).
 3. Locate the **Dependabot** section.
 
     ![Screenshot of the Dependabot section](../shared-images/dependabot-settings.png)
@@ -54,11 +54,11 @@ You've now enabled Dependabot alerts and security updates! When an insecure libr
 
 Many developers have accidentally checked in code containing tokens or credentials. Regardless of the reason, even seemingly innocuous tokens can create a security issue. [Secret scanning][about-secret-scanning] detects tokens in your source code and raises alerts. With push protection enabled, pushes containing supported secrets are blocked before they reach your repository.
 
-1. On the same **Code security** settings page, locate the **Secret scanning** section.
-2. Next to **Receive alerts on GitHub for detected secrets, keys or other tokens**, select **Enable**.
+1. On the same **Advanced security** settings page, locate the **Secret Protection** section.
+2. Next to **GitHub will always send alerts to partners for detected secrets in public repositories**, select **Enable**.
 3. Next to **Push protection**, select **Enable** to block pushes containing a [supported secret][supported-secrets].
 
-    ![Screenshot of fully configured secret scanning](../shared-images/secret-scanning-settings.png)
+    ![Screenshot of fully configured secret scanning](../shared-images/setup-secret-protection.png)
 
 You've now enabled secret scanning and push protection — helping prevent credentials from reaching your repository.
 
@@ -68,7 +68,7 @@ There is a direct relationship between the amount of code an organization writes
 
 Let's enable code scanning with the default CodeQL setup. This runs automatically whenever code is pushed to `main` or a pull request targets `main`, and on a regular schedule to catch newly discovered vulnerabilities.
 
-1. On the same **Code security** settings page, locate the **Code scanning** section.
+1. On the same **Advanced security** settings page, locate the **Code scanning** section.
 2. Next to **CodeQL analysis**, select **Set up** > **Default**.
 
     ![Screenshot of code scanning dropdown menu](../shared-images/code-scanning-setup.png)

content/github-actions/3-running-tests.md

@@ -73,7 +73,7 @@ Let's build that out!
               pip install -r app/server/requirements.txt
 
           - name: Run tests
-            working-directory: ./app/server
+            working-directory: ./server
             run: |
               python -m unittest test_app -v
     ```
@@ -101,7 +101,7 @@ The **`permissions`** block controls what this token can do. For our CI workflow
 
 A bit later you'll use a more standard branching approach for changes. But for our purposes right now, let's push straight to `main`. What you'll notice is the workflow will automatically run, since the workflow will now exist on `main`!
 
-1. Open the terminal in your codespace by pressing <kbd>Ctrl</kbd>+<kbd>`</kbd>, then stage, commit, and push:
+1. Open the terminal in your codespace by pressing <kbd>Ctl</kbd>+<kbd>`</kbd>, then stage, commit, and push:
 
     ```bash
     git add .github/workflows/run-tests.yml
@@ -141,15 +141,15 @@ The unit tests cover the API, but the shelter also has Playwright e2e tests that
               node-version: '20'
 
           - name: Install Node dependencies
-            working-directory: ./app/client
+            working-directory: ./client
             run: npm ci
 
           - name: Install Playwright browsers
-            working-directory: ./app/client
+            working-directory: ./client
             run: npx playwright install --with-deps chromium
 
           - name: Run e2e tests
-            working-directory: ./app/client
+            working-directory: ./client
             run: npx playwright test
     ```
 

content/github-actions/4-caching.md

@@ -3,9 +3,9 @@
 | [← Running Tests][walkthrough-previous] | [Next: Matrix Strategies & Parallel Testing →][walkthrough-next] |
 |:-----------------------------------|------------------------------------------:|
 
-**Caching** is a technique to speed up your workflows by reusing previously downloaded dependencies instead of fetching them from the internet on every run. This exercise teaches you how to cache Python packages and Node modules so your CI pipeline stays fast as your project grows.
+The [GitHub Actions Marketplace][actions-marketplace] is a collection of pre-built actions created by GitHub and the community. Actions can set up tools, run tests, deploy code, send notifications, and much more. Rather than writing everything from scratch, you can leverage the work of thousands of developers.
 
-Along the way you'll also browse the [GitHub Actions Marketplace][actions-marketplace] — a collection of pre-built actions created by GitHub and the community that you can drop into any workflow.
+In this exercise you'll also learn about **caching** — a technique to speed up your workflows by reusing previously downloaded dependencies instead of fetching them from the internet on every run.
 
 ## Scenario
 
@@ -71,7 +71,7 @@ The e2e job has two dependencies to cache — Python packages and the Node modul
 
 Now let's push the changes and see the impact of caching.
 
-1. In the terminal (<kbd>Ctrl</kbd>+<kbd>`</kbd> to toggle), stage, commit, and push your changes:
+1. In the terminal (<kbd>Ctl</kbd>+<kbd>`</kbd> to toggle), stage, commit, and push your changes:
 
     ```bash
     git add .github/workflows/run-tests.yml

content/github-actions/5-matrix-strategies.md

@@ -44,15 +44,15 @@ Let's update the CI workflow to test the API across multiple Python versions.
             pip install -r app/server/requirements.txt
 
         - name: Run tests
-          working-directory: ./app/server
+          working-directory: ./server
           run: |
             python -m unittest test_app -v
     ```
 
 > [!IMPORTANT]
 > Make sure to quote version numbers like `'3.12'` in the matrix array. Without quotes, YAML may interpret them as floating-point numbers — for example, `3.10` becomes `3.1`, which would cause the setup step to fail.
 
-5. In the terminal (<kbd>Ctrl</kbd>+<kbd>`</kbd> to toggle), stage, commit, and push your changes:
+5. In the terminal (<kbd>Ctl</kbd>+<kbd>`</kbd> to toggle), stage, commit, and push your changes:
 
     ```bash
     git add .github/workflows/run-tests.yml
@@ -126,6 +126,6 @@ Matrix strategies let you test across multiple configurations — language versi
 |:-----------------------------------|------------------------------------------:|
 
 [matrix-docs]: https://docs.github.com/actions/using-jobs/using-a-matrix-for-your-jobs
-[strategy-syntax]: https://docs.github.com/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy
+[strategy-syntax]: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy
 [walkthrough-previous]: 4-caching.md
 [walkthrough-next]: 6-deploy-azure.md

content/github-actions/6-deploy-azure.md

@@ -30,7 +30,7 @@ There are several strategies for ensuring only validated code reaches production
 
 Let's set up the Azure Developer CLI and scaffold the infrastructure for our project.
 
-1. Open the terminal in your codespace (or press <kbd>Ctrl</kbd>+<kbd>`</kbd> to toggle it).
+1. Open the terminal in your codespace (or press <kbd>Ctl</kbd>+<kbd>`</kbd> to toggle it).
 2. Install azd by running:
 
     ```bash

content/github-actions/7-custom-actions.md

@@ -29,7 +29,7 @@ Inputs and outputs let the action communicate with the calling workflow, making
 
 Let's create a composite action that sets up Python, installs dependencies, and seeds the test database.
 
-1. In your codespace, open a terminal window by selecting <kbd>Ctrl</kbd>+<kbd>\`</kbd>.
+1. In your codespace, open a terminal window by selecting <kbd>Ctl</kbd>+<kbd>\`</kbd>.
 2. Create the directory for the action by executing the following command in the terminal:
 
     ```bash
@@ -65,7 +65,7 @@ Let's create a composite action that sets up Python, installs dependencies, and
           uses: actions/setup-python@v5
           with:
             python-version: ${{ inputs.python-version }}
-            cache: 'pip'
+
         - name: Install dependencies
           run: pip install -r app/server/requirements.txt
           shell: bash
@@ -117,7 +117,7 @@ Now let's update the CI workflow to use the custom action instead of the individ
     ```yaml
           - name: Run tests
             run: python -m unittest test_app -v
-            working-directory: ./app/server
+            working-directory: ./server
             env:
               DATABASE_PATH: ${{ steps.seed.outputs.database-file }}
     ```
@@ -136,7 +136,7 @@ Now let's update the CI workflow to use the custom action instead of the individ
 
     ```yaml
           - name: Run e2e tests
-            working-directory: ./app/client
+            working-directory: ./client
             run: npx playwright test
             env:
               DATABASE_PATH: ${{ steps.seed.outputs.database-file }}
@@ -176,7 +176,7 @@ Now let's update the CI workflow to use the custom action instead of the individ
 
           - name: Run tests
             run: python -m unittest test_app -v
-            working-directory: ./app/server
+            working-directory: ./server
             env:
               DATABASE_PATH: ${{ steps.seed.outputs.database-file }}
 
@@ -200,21 +200,21 @@ Now let's update the CI workflow to use the custom action instead of the individ
               cache-dependency-path: 'app/client/package-lock.json'
 
           - name: Install Node dependencies
-            working-directory: ./app/client
+            working-directory: ./client
             run: npm ci
 
           - name: Install Playwright browsers
-            working-directory: ./app/client
+            working-directory: ./client
             run: npx playwright install --with-deps chromium
 
           - name: Run e2e tests
-            working-directory: ./app/client
+            working-directory: ./client
             run: npx playwright test
             env:
               DATABASE_PATH: ${{ steps.seed.outputs.database-file }}
     ```
 
-6. In the terminal (<kbd>Ctrl</kbd>+<kbd>`</kbd> to toggle), commit and push your changes:
+6. In the terminal (<kbd>Ctl</kbd>+<kbd>`</kbd> to toggle), commit and push your changes:
 
     ```bash
     git add .github/actions/setup-python-env/action.yml .github/workflows/run-tests.yml

content/github-actions/8-reusable-workflows.md

@@ -25,7 +25,7 @@ A **composite action** combines multiple *steps* into a single step that runs in
 | **Runner control** | Runs on the caller job's runner | Each job specifies its own runner |
 | **Secrets** | Cannot access secrets directly | Can receive secrets via `secrets:` or `secrets: inherit` |
 | **Logging** | Appears as one collapsed step in the log | Every job and step is logged individually |
-| **Nesting depth** | Up to 10 composite actions per workflow | Up to 4 levels of workflow nesting |
+| **Nesting depth** | Up to 10 composite actions per workflow | Up to 10 levels of workflow nesting |
 | **Marketplace** | Can be published to the [Actions Marketplace][actions-marketplace] | Cannot be published to the Marketplace |
 
 **When to use which:**
@@ -69,7 +69,7 @@ on:
         required: true
 ```
 
-The caller then passes each secret explicitly:
+Then caller then passes each secret explicitly:
 
 ```yaml
 deploy:
@@ -84,8 +84,6 @@ deploy:
 
 > [!IMPORTANT]
 > For deployment workflows that need Azure credentials, `secrets: inherit` is the simplest approach. However, defining specific secrets provides better documentation and prevents accidentally exposing secrets the reusable workflow doesn't need. We'll use `secrets: inherit` in this exercise for simplicity.
->
-> Note: In this workshop, `azd pipeline config` stored the Azure credentials as **repository variables** (accessed via `vars.*`), not secrets. The example above illustrates the pattern for cases where credentials _are_ stored as secrets.
 
 ## Create a reusable deployment workflow
 
@@ -205,7 +203,7 @@ Now let's add the second caller — a manual deploy workflow for rollbacks and h
 
     This workflow is only triggered **manually** via `workflow_dispatch` — it appears as a "Run workflow" button in the Actions tab. It prompts for a **git ref** (a commit SHA, tag, or branch name to deploy), passes that ref to the reusable workflow's `deploy-ref` input, and uses the same deploy logic as the automated pipeline.
 
-3. In the terminal (<kbd>Ctrl</kbd>+<kbd>`</kbd> to toggle), commit and push your changes:
+3. In the terminal (<kbd>Ctl</kbd>+<kbd>`</kbd> to toggle), commit and push your changes:
 
     ```bash
     git add .github/workflows/reusable-deploy.yml .github/workflows/azure-dev.yml .github/workflows/manual-deploy.yml

content/github-actions/9-required-workflows.md

@@ -94,7 +94,7 @@ Let's create a ruleset that requires our tests to pass, and pull requests to be
 
 Let's verify the ruleset is working.
 
-1. Return to your codespace and open the terminal (<kbd>Ctrl</kbd>+<kbd>`</kbd> to toggle). Create a new branch and make a small change:
+1. Return to your codespace and open the terminal (<kbd>Ctl</kbd>+<kbd>`</kbd> to toggle). Create a new branch and make a small change:
 
     ```bash
     git checkout -b test-ruleset
@@ -146,7 +146,7 @@ This pipeline follows the same patterns used by teams across GitHub. As the shel
 
 If you want to keep exploring, here are some suggested next steps:
 
-- Add a custom CodeQL workflow using [GitHub Advanced Security][github-security].
+- Add a code scanning workflow using [GitHub Advanced Security][github-security].
 - Explore [GitHub Environments][environments-docs] with deployment protection rules for staged deployments (e.g., staging → production with manual approval).
 - Explore the [GitHub Actions Marketplace][actions-marketplace] for community-built actions.
 - Take the [GitHub Skills: Deploy to Azure][skills-deploy-azure] course for a deeper dive into Azure deployment.

content/github-actions/README.md

@@ -26,7 +26,7 @@ To complete this workshop, you will need the following:
 1. [Introduction & Your First Workflow][introduction] — Create your first workflow and explore the Actions UI
 2. [Securing the Development Pipeline][code-scanning] — Enable code scanning, Dependabot, and secret scanning
 3. [Running Tests][ci] — Automate unit and e2e testing with parallel jobs
-4. [Caching][caching] — Speed up workflows by caching dependencies
+4. [Caching][marketplace] — Speed up workflows by caching dependencies
 5. [Matrix strategies & parallel testing][matrix] — Test across multiple configurations simultaneously
 6. [Deploying to Azure with azd][deployment] — Set up continuous deployment to Azure
 7. [Creating custom actions][custom-actions] — Build your own reusable action
@@ -57,7 +57,7 @@ To complete this workshop, you will need the following:
 [github-copilot]: https://github.com/features/copilot
 [github-signup]: https://github.com/join
 [introduction]: ./1-introduction.md
-[caching]: ./4-caching.md
+[marketplace]: ./4-caching.md
 [matrix]: ./5-matrix-strategies.md
 [protection]: ./9-required-workflows.md
 [repo-root]: /