Repo File Sync: 202405 Branch Transition Updates. (#325)

synced local file(s) with
[microsoft/mu_devops](https://github.com/microsoft/mu_devops).

🤖: View the [Repo File Sync Configuration
File](https://github.com/microsoft/mu_devops/blob/main/.sync/Files.yml)
to see how files are synced.



---

This PR was created automatically by the
[repo-file-sync-action](https://github.com/BetaHuhn/repo-file-sync-action)
workflow run
[#10532319094](https://github.com/microsoft/mu_devops/actions/runs/10532319094)

Signed-off-by: Project Mu UEFI Bot <uefibot@microsoft.com>

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -67,7 +67,7 @@ body:
       description: |
         examples:
           - **OS**: Ubuntu 20.04 or Windows 11...
-          - **Tool Chain**: GCC or VS2022 or CLANGPDB...
+          - **Tool Chain**: GCC5 or VS2022 or CLANGPDB...
           - **Targets Impacted**: RELEASE, DEBUG, NO-TARGET, NOOPT...
       value: |
           - OS(s):

.github/pull_request_template.md

@@ -1,41 +1,18 @@
-# Preface
-
-Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
-to submitting the pull request. In particular,
-[pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).
-
 ## Description
 
-<_Please include a description of the change and why this change was made._>
+<_Include a description of the change and why this change was made._>
 
-For each item, place an "x" in between `[` and `]` if true. Example: `[x]`.
-_(you can also check items in the GitHub UI)_
+For details on how to complete to complete these options and their meaning refer to [CONTRIBUTING.md](https://github.com/microsoft/mu/blob/HEAD/CONTRIBUTING.md).
 
 - [ ] Impacts functionality?
-  - **Functionality** - Does the change ultimately impact how firmware functions?
-  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
 - [ ] Impacts security?
-  - **Security** - Does the change have a direct security impact on an application,
-    flow, or firmware?
-  - Examples: Crypto algorithm change, buffer overflow fix, parameter
-    validation improvement, ...
 - [ ] Breaking change?
-  - **Breaking change** - Will anyone consuming this change experience a break
-    in build or boot behavior?
-  - Examples: Add a new library class, move a module to a different repo, call
-    a function in a new library class in a pre-existing module, ...
 - [ ] Includes tests?
-  - **Tests** - Does the change include any explicit test code?
-  - Examples: Unit tests, integration tests, robot tests, ...
 - [ ] Includes documentation?
-  - **Documentation** - Does the change contain explicit documentation additions
-    outside direct code modifications (and comments)?
-  - Examples: Update readme file, add feature readme file, link to documentation
-    on an a separate Web page, ...
 
 ## How This Was Tested
 
-<_Please describe the test(s) that were run to verify the changes._>
+<_Describe the test(s) that were run to verify the changes._>
 
 ## Integration Instructions
 

.github/release-draft-config-n-1.yml

@@ -20,7 +20,7 @@
 name-template: 'v$RESOLVED_VERSION'
 tag-template: 'v$RESOLVED_VERSION'
 
-commitish: refs/heads/release/202302
+commitish: refs/heads/release/202311
 filter-by-commitish: true
 
 template: |

.github/release-draft-config-n.yml

@@ -20,7 +20,7 @@
 name-template: 'v$RESOLVED_VERSION'
 tag-template: 'v$RESOLVED_VERSION'
 
-commitish: refs/heads/release/202311
+commitish: refs/heads/release/202405
 filter-by-commitish: true
 
 template: |

.github/workflows/codeql.yml

@@ -161,11 +161,21 @@ jobs:
         import os
         import requests
         import sys
+        import time
+
+        def get_response_with_retries(url, retries=5, wait_time=10):
+          for attempt in range(retries):
+            response = requests.get(url)
+            if response.status_code == 200:
+              return response
+            print(f"::warning title=GitHub API Access Error!::Attempt {attempt + 1} failed. Retrying in {wait_time} seconds...")
+            time.sleep(wait_time)
+          return response
 
         GITHUB_REPO = "sagiegurari/cargo-make"
         api_url = f"https://api.github.com/repos/{GITHUB_REPO}/releases/tags/0.37.9"
 
-        response = requests.get(api_url)
+        response = get_response_with_retries(api_url)
         if response.status_code == 200:
           build_release_id = response.json()["id"]
         else:
@@ -174,7 +184,7 @@ jobs:
 
         api_url = f"https://api.github.com/repos/{GITHUB_REPO}/releases/{build_release_id}"
 
-        response = requests.get(api_url)
+        response = get_response_with_retries(api_url)
         if response.status_code == 200:
           latest_cargo_make_version = response.json()["tag_name"]
         else:
@@ -198,7 +208,7 @@ jobs:
 
     - name: Download cargo-make
       if: steps.cargo_make_cache.outputs.cache-hit != 'true'
-      uses: robinraju/release-downloader@v1.10
+      uses: robinraju/release-downloader@v1.11
       with:
         repository: 'sagiegurari/cargo-make'
         tag: '${{ steps.get_cargo_tool_details.outputs.cargo_make_version }}'

.github/workflows/release-draft.yml

@@ -23,7 +23,7 @@ name: Update Release Draft
 on:
   push:
     branches:
-      - release/202311
+      - release/202405
 
 jobs:
   draft:

CONTRIBUTING.md

@@ -21,7 +21,7 @@ submitted in the issues section.
 ## Security Vulnerabilities
 
 Please review the repos `Security Policy` but in general every Project Mu repo has `Private vulnerability reporting`
-enabled.  Please use the security tab to report a potential issue.  
+enabled.  Please use the security tab to report a potential issue.
 
 ### Identify Where to Report
 
@@ -63,6 +63,57 @@ configuration files. To aid maintainers in reviewing your code, we suggest adher
    * If the contribution logically be broken up into separate pull requests that independently build and function
      successfully, do use multiple pull requests.
 
+#### Pull Request Description Checkboxes
+
+Project Mu pull requests autopopulate a PR description from a template in most repositories. You should:
+
+1. **Replace** this text with an actual descrption:
+
+   ```txt
+   <_Include a description of the change and why this change was made._>
+   ```
+
+2. **Remove** this line of instructions so the PR description shows cleanly in release notes:
+
+   `"For details on how to complete to complete these options and their meaning refer to [CONTRIBUTING.md](https://github.com/microsoft/mu/blob/HEAD/CONTRIBUTING.md)."`
+
+3. For each checkbox in the PR description, **place an "x"** in between `[` and `]` if true. Example: `[x]`.
+   _(you can also check items in the GitHub UI)_
+
+   * **[] Impacts functionality?**
+     * **Functionality** - Does the change ultimately impact how firmware functions?
+     * Examples: Add a new library, publish a new PPI, update an algorithm, ...
+   * **[] Impacts security?**
+     * **Security** - Does the change have a direct security impact on an application,
+       flow, or firmware?
+     * Examples: Crypto algorithm change, buffer overflow fix, parameter
+       validation improvement, ...
+   * **[] Breaking change?**
+     * **Breaking change** - Will anyone consuming this change experience a break
+       in build or boot behavior?
+     * Examples: Add a new library class, move a module to a different repo, call
+       a function in a new library class in a pre-existing module, ...
+   * [] **Includes tests?**
+     * **Tests** - Does the change include any explicit test code?
+     * Examples: Unit tests, integration tests, robot tests, ...
+   * [] **Includes documentation?**
+     * **Documentation** - Does the change contain explicit documentation additions
+       outside direct code modifications (and comments)?
+     * Examples: Update readme file, add feature readme file, link to documentation
+      on an a separate Web page, ...
+
+4. **Replace** this text as instructed:
+
+   ```txt
+   <_Describe the test(s) that were run to verify the changes._>
+   ```
+
+5. **Replace** this text as instructed:
+
+   ```txt
+   <_Describe how these changes should be integrated. Use N/A if nothing is required._>
+   ```
+
 #### Code Categories
 
 To keep code digestible, you may consider breaking large pull requests into three categories of commits within the pull