move from gh pages to swa

.github/workflows/azure-static-web-apps-green-pebble-023b10a10.yml

@@ -13,12 +13,26 @@ jobs:
   build_and_deploy_job:
     if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
     runs-on: ubuntu-latest
+    permissions:
+      pull-requests: write
     name: Build and Deploy Job
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
         with:
           submodules: true
           lfs: false
+      - name: Setup Ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: '3.4' # Not needed with a .ruby-version file
+          bundler-cache: true # runs 'bundle install' and caches installed gems automatically
+          # cache-version: 0 # Increment this number if you need to re-download cached gems
+      - name: Jekyll bundle
+        id: jekyllbundle
+        run: |
+          bundle exec jekyll build
+        env:
+          JEKYLL_ENV: production
       - name: Build And Deploy
         id: builddeploy
         uses: Azure/static-web-apps-deploy@v1
@@ -28,9 +42,10 @@ jobs:
           action: "upload"
           ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
           # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
-          app_location: "./" # App source code path
-          api_location: "" # Api source code path - optional
-          output_location: "_site" # Built app content directory - optional
+          app_location: "/_site" # App source code path
+          skip_app_build: true
+          # api_location: "" # Api source code path - optional
+          # output_location: "_site" # Built app content directory - optional
           ###### End of Repository/Build Configurations ######
 
   close_pull_request_job:

.gitignore

@@ -6,6 +6,8 @@
 # dotenv files
 .env
 
+_site/
+
 # User-specific files
 *.rsuser
 *.suo

Gemfile

@@ -0,0 +1,35 @@
+source "https://rubygems.org"
+# Hello! This is where you manage which Jekyll version is used to run.
+# When you want to use a different version, change it below, save the
+# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
+#
+#     bundle exec jekyll serve
+#
+# This will help ensure the proper Jekyll version is running.
+# Happy Jekylling!
+gem "jekyll", "~> 4.4.1"
+# This is the default theme for new Jekyll sites. You may change this to anything you like.
+gem "minima", "~> 2.5"
+# gem "github-pages", group: :jekyll_plugins
+# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
+# uncomment the line below. To upgrade, run `bundle update github-pages`.
+# gem "github-pages", group: :jekyll_plugins
+# If you have any plugins, put them here!
+group :jekyll_plugins do
+  # gem "jekyll-feed", "~> 0.12"
+  # gem 'jekyll-commonmark-ghpages'
+end
+
+# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
+# and associated library.
+platforms :mingw, :x64_mingw, :mswin, :jruby do
+  gem "tzinfo", ">= 1", "< 3"
+  gem "tzinfo-data"
+end
+
+# Performance-booster for watching directories on Windows
+gem "wdm", "~> 0.1", :platforms => [:mingw, :x64_mingw, :mswin]
+
+# Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem
+# do not have a Java counterpart.
+gem "http_parser.rb", "~> 0.6.0", :platforms => [:jruby]

Gemfile.lock

@@ -0,0 +1,100 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    addressable (2.8.7)
+      public_suffix (>= 2.0.2, < 7.0)
+    base64 (0.2.0)
+    bigdecimal (3.1.9)
+    colorator (1.1.0)
+    concurrent-ruby (1.3.5)
+    csv (3.3.3)
+    em-websocket (0.5.3)
+      eventmachine (>= 0.12.9)
+      http_parser.rb (~> 0)
+    eventmachine (1.2.7)
+    ffi (1.17.1-arm64-darwin)
+    ffi (1.17.1-x86_64-linux-gnu)
+    forwardable-extended (2.6.0)
+    google-protobuf (4.30.2-arm64-darwin)
+      bigdecimal
+      rake (>= 13)
+    google-protobuf (4.30.2-x86_64-linux)
+      bigdecimal
+      rake (>= 13)
+    http_parser.rb (0.8.0)
+    i18n (1.14.7)
+      concurrent-ruby (~> 1.0)
+    jekyll (4.4.1)
+      addressable (~> 2.4)
+      base64 (~> 0.2)
+      colorator (~> 1.0)
+      csv (~> 3.0)
+      em-websocket (~> 0.5)
+      i18n (~> 1.0)
+      jekyll-sass-converter (>= 2.0, < 4.0)
+      jekyll-watch (~> 2.0)
+      json (~> 2.6)
+      kramdown (~> 2.3, >= 2.3.1)
+      kramdown-parser-gfm (~> 1.0)
+      liquid (~> 4.0)
+      mercenary (~> 0.3, >= 0.3.6)
+      pathutil (~> 0.9)
+      rouge (>= 3.0, < 5.0)
+      safe_yaml (~> 1.0)
+      terminal-table (>= 1.8, < 4.0)
+      webrick (~> 1.7)
+    jekyll-feed (0.17.0)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-sass-converter (3.1.0)
+      sass-embedded (~> 1.75)
+    jekyll-seo-tag (2.8.0)
+      jekyll (>= 3.8, < 5.0)
+    jekyll-watch (2.2.1)
+      listen (~> 3.0)
+    json (2.10.2)
+    kramdown (2.5.1)
+      rexml (>= 3.3.9)
+    kramdown-parser-gfm (1.1.0)
+      kramdown (~> 2.0)
+    liquid (4.0.4)
+    listen (3.9.0)
+      rb-fsevent (~> 0.10, >= 0.10.3)
+      rb-inotify (~> 0.9, >= 0.9.10)
+    mercenary (0.4.0)
+    minima (2.5.2)
+      jekyll (>= 3.5, < 5.0)
+      jekyll-feed (~> 0.9)
+      jekyll-seo-tag (~> 2.1)
+    pathutil (0.16.2)
+      forwardable-extended (~> 2.6)
+    public_suffix (6.0.1)
+    rake (13.2.1)
+    rb-fsevent (0.11.2)
+    rb-inotify (0.11.1)
+      ffi (~> 1.0)
+    rexml (3.4.1)
+    rouge (4.5.1)
+    safe_yaml (1.0.5)
+    sass-embedded (1.86.3-arm64-darwin)
+      google-protobuf (~> 4.30)
+    sass-embedded (1.86.3-x86_64-linux-gnu)
+      google-protobuf (~> 4.30)
+    terminal-table (3.0.2)
+      unicode-display_width (>= 1.1.1, < 3)
+    unicode-display_width (2.6.0)
+    webrick (1.9.1)
+
+PLATFORMS
+  arm64-darwin
+  x86_64-linux
+
+DEPENDENCIES
+  http_parser.rb (~> 0.6.0)
+  jekyll (~> 4.4.1)
+  minima (~> 2.5)
+  tzinfo (>= 1, < 3)
+  tzinfo-data
+  wdm (~> 0.1)
+
+BUNDLED WITH
+   2.6.2

LAB0/README.md

@@ -1,8 +1,13 @@
-# LAB0: Prerequisites and setup
+---
+layout: page
+title: "Lab 0"
+description: "Prerequisites and setup"
+permalink: /LAB0/
+---
 
 This folder (LAB0) contains the SQL project for the initial state of the Wingtips database provided to students at the beginning of the series of labs. 
 
-If you are performing the labs as part of a workshop, the instructor may provide you with a student connection string to the Wingtips database such that you can immediately start **LAB1**.
+If you are performing the labs as part of a workshop, the instructor may provide you with a student connection string to the Wingtips database such that you can immediately start **Lab 1**.
 
 If you are performing the labs as part of a self-paced learning experience, you may need to deploy the initial state of the Wingtips database yourself. The instructions for deploying the initial state of the Wingtips database are provided below.
 
@@ -61,4 +66,4 @@ sqlpackage /a:publish /sf:"modules/LAB0/Wingtips-initial/bin/Debug/Wingtips-init
 
 ## Next lab
 
-[LAB 1: Participants configure a simple CI/CD pipelines for a sample SQL project](../LAB1/README.md)
+[Lab  1: Participants configure a simple CI/CD pipelines for a sample SQL project](/LAB1/)

LAB1/README.md

@@ -1,10 +1,15 @@
-# LAB 1: Participants configure a simple CI/CD pipelines for a sample SQL project
+---
+layout: page
+title: "Lab 1"
+description: "Participants configure a simple CI/CD pipelines for a sample SQL project"
+permalink: /LAB1/
+---
 
 **Overview:**
-- 1.1: Create a project from an existing database
-- 1.2: Create a pipeline to publish the project to the database
-- 1.3: Create a pipeline to build the project and run code analysis
-- 1.4: Deploy our changes to the database
+- [1.1](#11-create-a-project-from-an-existing-database): Create a project from an existing database
+- [1.2](#12-create-a-pipeline-to-publish-the-project-to-the-database): Create a pipeline to publish the project to the database
+- [1.3](#13-create-a-pipeline-to-build-the-project-and-run-code-analysis): Create a pipeline to build the project and run code analysis
+- [1.4](#14-deploying-our-changes-to-the-database): Deploy our changes to the database
 
 ## Workshop prerequisites
 
@@ -25,26 +30,28 @@ You must have the following installed on your machine:
 3. Follow the prompts to create a new SQL project named `Wingtips` from the database in a folder called `Wingtips` in the workshop folder.
 4. From the SQL projects extension, right-click on the **Wingtips** project and select **Build** to build the project. This will create a `.dacpac` file in the `bin/Debug` folder of the project. The `.dacpac` file is a compiled version of the SQL database model.
 
-5. Since we don't want to include files like a `.dacpac` in our future git repository, we need to add a `.gitignore` file to the project. Open the **Terminal** in VS Code (View menu > Terminal or Ctrl+`), and run the following command to create a `.gitignore` file in the workshop folder:
-   ```bash
-   dotnet new gitignore
-   ```
+5. Since we don't want to include files like a `.dacpac` in our future git repository, we need to add a `.gitignore` file to the project. Open the **Terminal** in VS Code (View menu > Terminal or Ctrl+\`), and run the following command to create a `.gitignore` file in the workshop folder:
+  ```bash
+  dotnet new gitignore
+  ```
 
 ### Push the project to a new private GitHub repository
 
 1. From the **Source Control** view in VS Code, initialize a git repository and commit the entire project to the repository with a commit message like "initial commit".
 2. The commit button in the Source Control view will now display **Publish Branch**. Click the button to publish the branch to a new private GitHub repository.
 
-![publish branch](images/publish-button.png)
+  ![publish branch](images/publish-button.png)
 
+{:start="3"}
 3. If you are prompted to sign in to GitHub, follow the prompts to sign in. 
 4. Select the private option for the repository, adjusting the name if you want to.
 
-![new repo](images/new-repo-vsc.png)
+  ![new repo](images/new-repo-vsc.png)
 
+{:start="5"}
 5. The repository will be created and the branch will be pushed to the new repository. A notification will appear in the bottom right corner of VS Code with a link to the new repository which will also be available in the GitHub website.
 
-![repository created](images/repo-success.png)
+  ![repository created](images/repo-success.png)
 
 ## 1.2 Create a pipeline to publish the project to the database
 
@@ -92,24 +99,33 @@ In this section we're going to create a GitHub Actions pipeline to publish the S
   Remove the `push` and `pull_request` events, which trigger the pipeline on every commit and pull request to the specified branches.
 5. Remove the `Test` step in the pipeline and modify the pipeline name in the YAML to "Deploy SQL project".
 6. Modify the `Restore` and `Build` steps to build the SQL project in the `Wingtips` folder by specifying the project file:
+  {% raw %}
   ```yml
     - name: Restore dependencies
       run: dotnet restore Wingtips/Wingtips.sqlproj
     - name: Build
       run: dotnet build Wingtips/Wingtips.sqlproj --no-restore
   ```
+  {% endraw %}
+
+{:start="6"}
 6. Add a step to the pipeline that uses **SqlPackage** to publish the `.dacpac` to the database after the SQL project has been built:
+  {% raw %}
   ```yml
     - name: Publish SQL project
       run: |
         sqlpackage /Action:Publish /SourceFile:Wingtips/bin/Debug/Wingtips.dacpac /TargetConnectionString:${{ secrets.SQL_CONNECTION_STRING }}
   ```
+  {% endraw %}
   Note that the path to the source file is relative to the working directory of the pipeline, which starts at the root of the repository, and the name of the `.dacpac` file defaults to the name of the project.
+
+{:start="7"}
 7. Commit the changes to the pipeline file.
 8. Add a secret to the GitHub repository named `SQL_CONNECTION_STRING` with the connection string to the Azure SQL Database. Secrets are used to store sensitive information in GitHub Actions and are set in the repository settings under "secrets and variables" and "actions".
 9. We won't run this pipeline just yet since we have no changes to apply to the database. We'll run it later after we make some changes to the project.
 
-<details>
+{% raw %}
+<details markdown="1">
 <summary>Completed publish pipeline (expand to check your work)</summary>
 
 ```yml
@@ -140,15 +156,17 @@ In this section we're going to create a GitHub Actions pipeline to publish the S
           run: |
             sqlpackage /Action:Publish /SourceFile:Wingtips/bin/Debug/Wingtips.dacpac /TargetConnectionString:${{ secrets.SQL_CONNECTION_STRING }}
 ```
-</details>
 
+</details>
+{% endraw %}
 
 ## 1.3 Create a pipeline to build the project and run code analysis
 
 In this section we're going to leverage SQL code analysis to provide ongoing feedback on the quality of the SQL code in the project. The pipeline will run on every commit to the main branch. When we use the pipeline on pull requests, it will provide feedback on the quality of the code before it is merged into the main branch and acts as a CI (continuous integration) pipeline.
 
 1. In VS Code, sync our project with the remote GitHub repository. A folder `.github` will be created in the root of the project with a `workflows` folder inside it.
 2. In the `.github/workflows` folder, create a new file named `build-codeanalysis.yml` with the following content:
+
   ```yml
     name: Build SQL project with code analysis
 
@@ -175,8 +193,9 @@ In this section we're going to leverage SQL code analysis to provide ongoing fee
         - name: Build
           run: dotnet build Wingtips/Wingtips.sqlproj /p:RunSqlCodeAnalysis=true
   ```
-
   This pipeline will run on every commit to the main branch and pull requests against main.
+
+{:start="3"}
 3. We'll test our new pipeline with a new stored procedure. In VS Code, switch to a new branch named `new-venue`.
 4. In the `Wingtips` project folder, add a new file in `dbo/StoredProcedures` named `NewVenue.sql`. Add the following content to the file:
 
@@ -210,11 +229,13 @@ In this section we're going to leverage SQL code analysis to provide ongoing fee
 
   RETURN 0
   ```
+
+{:start="5"}
 5. Commit the new stored procedure to the `new-venue` branch and push the branch to GitHub.
 6. In GitHub, create a pull request from the `new-venue` branch to the `main` branch.
 7. In the pull request, select the **Checks** tab and see that the pipeline is running.
 8. When the pipeline completes, select the **Details** link to see the results of the code analysis.
-<details>
+<details markdown="1">
 <summary>Code analysis results (expand to check your work)</summary>
 
 The code analysis returns 1 warning:
@@ -229,6 +250,7 @@ Build succeeded.
 
 </details>
 
+{:start="9"}
 9. Based on the code analysis results, we realize that our stored procedure `dbo.NewVenue` is using the right size for the VenueName parameter (128 characters) but the table its being inserted into is using a smaller size. Let's fix that by modifying the size of the `VenueName` column in the `dbo.Venues` table to 128 characters.
 10. In the `Wingtips` project folder, open the file `dbo.Tables/Venues.sql` and change the size of the `VenueName` column from 50 to 128 characters:
 
@@ -239,6 +261,7 @@ CREATE TABLE [dbo].[Venues] (
   ...
 ```
 
+{:start="11"}
 11. Commit the change to the `new-venue` branch and push the change to GitHub.
 12. In GitHub, the pipeline will automatically run again and this time the code analysis will pass.
 13. In GitHub, merge the pull request to the `main` branch.
@@ -256,5 +279,5 @@ The changes we made added a new stored procedure and changed a column in a table
 
 ## Next lab
 
-[LAB 2: Participants deploy SQL projects to different platforms](../LAB2/README.md)
+[Lab  2: Participants deploy SQL projects to different platforms](/LAB2/)