Merge branch 'docs-v4.64.0' of github.com:fleetdm/fleet into docs-v4.…

…64.0

.github/ISSUE_TEMPLATE/release-qa.md

@@ -197,6 +197,12 @@ Using the migration scripts located in fleet/test/upgrade/
 
 1. Check [this](https://github.com/fleetdm/fleet/labels/~release%20blocker) filter to view all open `~release blocker` tickets.
 2. If any are found raise an alarm in the `#help-engineering` and `#g-mdm` (or `#g-endpoint-ops`)  channels.
+</td><td>pass/fail</td>
+<tr><td>Load Tests</td><td>Verify all load test metrics are within acceptable range on final build of RC.</td><td>
+
+1. Check [this Google doc](https://docs.google.com/document/d/1V6QtFzcGDsLnn2PIvGin74DAxdAN_3likjxSssOMMQI/edit?tab=t.0#heading=h.15acjob4ji20) to review load test key metrics and checks.
+2. After all expected changes have been merged to the RC branch, set up a load test environment and allow it at least 24hrs of run time.
+3. Record metrics in [this spreadsheet](https://docs.google.com/spreadsheets/d/1FOF0ykFVoZ7DJSTfrveip0olfyRQsY9oT1uXCCZmuKc/edit?usp=drive_link) for the load test run. 
 </td><td>pass/fail</td></tr> 
 </table>
 
@@ -230,14 +236,13 @@ List versions changes for any component updates below:
 <table>
 <tr><th>Test name</th><th>Step instructions</th><th>Expected result</th><th>pass/fail</td></tr>
 <tr><td>$Name</td><td>{what a tester should do}</td><td>{what a tester should see when they do that}</td><td>pass/fail</td></tr>
-<tr><td>`fleetd` tests</td>
+<tr><td>`fleetd` local testing</td>
 <td>
-1. Create binaries for Mac, Windows, and Ubuntu running against the `edge` channels and install (--orbit-channel edge, --desktop-channel edge).<br>
-2. Work with engineer leading the release to push changes to the `edge` channel.
+1. Following [Testing TUF]([url](https://github.com/fleetdm/fleet/blob/main/tools/tuf/test/README.md)) instructions create binaries for Mac, Windows, and Ubuntu using your local TUF repository and install on macOS, Linux, and Windows hosts.<br>
 </td>
 <td>
-1. Confirm the hosts running on the edge channel receive the update and are working correctly.<br>
-2. Confirm any new features and/or bug fixes associated with this release are working as intended.
+1. Confirm the hosts install with the updated version and are working correctly.<br>
+2. Confirm any new features and/or bug fixes associated with this release are working as intended.<br>
 </td>
 <td>pass/fail</td></tr>
 <td>`fleetd` auto-update tests</td>
@@ -253,6 +258,16 @@ List versions changes for any component updates below:
 4. Confirms agents running on `stable` receive the new update.
 </td>
 <td>pass/fail</td></tr>
+<td>`fleetd` tests</td>
+<td>
+1. Set up a host in your instance to receive updates from the `edge` channels.<br>
+2. Work with engineer leading the release to push changes to the `edge` channel.<br>
+</td>
+<td>
+1. Confirm the hosts running on the edge channel receive the update and are working correctly.<br>
+2. Confirm any new features and/or bug fixes associated with this release are working as intended.
+</td>
+<td>pass/fail</td></tr></tr>
 </table>
 
 

.github/ISSUE_TEMPLATE/story.md

@@ -39,7 +39,7 @@ What else should contributors [keep in mind](https://fleetdm.com/handbook/compan
 ## Changes
 
 ### Product
-- [ ] UI changes: TODO <!-- Insert the link to the relevant Figma cover page. Make sure  wireframes show the UI down to 320px (min screen width). Put "No changes" if there are no changes to the user interface. -->
+- [ ] UI changes: TODO <!-- Insert the link to the relevant Figma cover page. Make sure  wireframes show the UI down to 768px (min screen width). Put "No changes" if there are no changes to the user interface. -->
 - [ ] CLI (fleetctl) usage changes: TODO <!-- Insert the link to the relevant Figma cover page. Put "No changes" if there are no changes to the CLI. -->
 - [ ] YAML changes: TODO <!-- Specify changes in the YAML files doc page as a PR to the reference docs release branch following the guidelines in the handbook here: https://fleetdm.com/handbook/product-design#drafting Put "No changes" if there are no changes necessary. -->
 - [ ] REST API changes: TODO <!-- Specify changes in the the REST API doc page as a PR to reference docs release branch following the guidelines in the handbook here: https://fleetdm.com/handbook/product-design#drafting Put "No changes" if there are no changes necessary. Move this item to the engineering list below if engineering will design the API changes. -->

.github/scripts/dogfood-policy-updater-latest-macos.sh

@@ -70,8 +70,8 @@ if [ "$policy_version_number" != "$latest_macos_version" ]; then
     echo "$updated_response" > "$temp_file"
 
     # Configure Git
-    git config --global user.name "$DOGFOOD_GIT_USER_NAME"
-    git config --global user.email "$DOGFOOD_GIT_USER_EMAIL"
+    git config --global user.name "$DOGFOOD_AUTOMATION_USER_NAME"
+    git config --global user.email "$DOGFOOD_AUTOMATION_USER_EMAIL"
 
     # Clone the repository and create a new branch
     git clone "https://$DOGFOOD_AUTOMATION_TOKEN@github.com/$REPO_OWNER/$REPO_NAME.git" repo || {
@@ -103,6 +103,33 @@ if [ "$policy_version_number" != "$latest_macos_version" ]; then
     fi
 
     echo "Pull request created successfully."
+
+    # Extract the pull request number from the response
+    pr_number=$(echo "$pr_response" | jq -r '.number')
+    if [ -z "$pr_number" ] || [ "$pr_number" == "null" ]; then
+        echo "Error: Failed to retrieve pull request number."
+        exit 1
+    fi
+
+    echo "Adding reviewers to PR #$pr_number..."
+
+    # Prepare the reviewers data payload
+    reviewers_data=$(jq -n --arg r1 "harrisonravazzolo" '{reviewers: [$r1]}')
+
+    # Request reviewers for the pull request
+    review_response=$(curl -s -X POST \
+        -H "Authorization: token $DOGFOOD_AUTOMATION_TOKEN" \
+        -H "Accept: application/vnd.github.v3+json" \
+        -d "$reviewers_data" \
+        "https://api.github.com/repos/$REPO_OWNER/$REPO_NAME/pulls/$pr_number/requested_reviewers")
+
+
+    if echo "$review_response" | grep -q "errors"; then
+        echo "Error: Failed to add reviewers. Response: $review_response"
+        exit 1
+    fi
+
+    echo "Reviewers added successfully."
 else
     echo "No updates needed; the version is the same."
 fi

.github/workflows/fleetd-tuf.yml

@@ -40,6 +40,10 @@ jobs:
       with:
         go-version-file: 'go.mod'
 
+    - name: Update orbit/old-TUF.md
+      run: |
+        make fleetd-old-tuf
+    
     - name: Update orbit/TUF.md
       run: |
         make fleetd-tuf

.github/workflows/generate-desktop-targets.yml

@@ -19,7 +19,7 @@ defaults:
     shell: bash
 
 env:
-  FLEET_DESKTOP_VERSION: 1.38.1
+  FLEET_DESKTOP_VERSION: 1.39.1
 
 permissions:
   contents: write

.github/workflows/goreleaser-fleet.yaml

@@ -76,7 +76,7 @@ jobs:
 
       - name: Run GoReleaser
         id: goreleaser
-        uses: goreleaser/goreleaser-action@f82d6c1c344bcacabba2c841718984797f664a6b
+        uses: goreleaser/goreleaser-action@90a3faa9d0182683851fbfa97ca1a2cb983bfca3 # v6.2.1
         with:
           distribution: goreleaser-pro
           version: "~> 2"

.github/workflows/goreleaser-snapshot-fleet.yaml

@@ -69,7 +69,7 @@ jobs:
         run: make deps
 
       - name: Run GoReleaser
-        uses: goreleaser/goreleaser-action@f82d6c1c344bcacabba2c841718984797f664a6b
+        uses: goreleaser/goreleaser-action@90a3faa9d0182683851fbfa97ca1a2cb983bfca3 # v6.2.1
         with:
           distribution: goreleaser-pro
           version: "~> 2"

Makefile

@@ -395,9 +395,17 @@ changelog-chrome:
 	sh -c "cat new-CHANGELOG.md ee/fleetd-chrome/CHANGELOG.md > tmp-CHANGELOG.md && rm new-CHANGELOG.md && mv tmp-CHANGELOG.md ee/fleetd-chrome/CHANGELOG.md"
 	sh -c "git rm ee/fleetd-chrome/changes/*"
 
-# Updates the documentation for the currently released versions of fleetd components in Fleet's TUF.
+# Updates the documentation for the currently released versions of fleetd components in old Fleet's TUF (tuf.fleetctl.com).
+fleetd-old-tuf:
+	sh -c 'echo "<!-- DO NOT EDIT. This document is automatically generated by running \`make fleetd-old-tuf\`. -->\n# tuf.fleetctl.com\n\nFollowing are the currently deployed versions of fleetd components on the \`stable\` and \`edge\` channel.\n" > orbit/old-TUF.md'
+	sh -c 'echo "## \`stable\`\n" >> orbit/old-TUF.md'
+	sh -c 'go run tools/tuf/status/tuf-status.go channel-version -s3-vendor amazon -url https://tuf.fleetctl.com -channel stable -format markdown >> orbit/old-TUF.md'
+	sh -c 'echo "\n## \`edge\`\n" >> orbit/old-TUF.md'
+	sh -c 'go run tools/tuf/status/tuf-status.go channel-version -s3-vendor amazon -url https://tuf.fleetctl.com -channel edge -format markdown >> orbit/old-TUF.md'
+
+# Updates the documentation for the currently released versions of fleetd components in Fleet's TUF (updates.fleetdm.com).
 fleetd-tuf:
-	sh -c 'echo "<!-- DO NOT EDIT. This document is automatically generated by running \`make fleetd-tuf\`. -->\n# tuf.fleetctl.com\n\nFollowing are the currently deployed versions of fleetd components on the \`stable\` and \`edge\` channel.\n" > orbit/TUF.md'
+	sh -c 'echo "<!-- DO NOT EDIT. This document is automatically generated by running \`make fleetd-tuf\`. -->\n# updates.fleetdm.com\n\nFollowing are the currently deployed versions of fleetd components on the \`stable\` and \`edge\` channel.\n" > orbit/TUF.md'
 	sh -c 'echo "## \`stable\`\n" >> orbit/TUF.md'
 	sh -c 'go run tools/tuf/status/tuf-status.go channel-version -channel stable -format markdown >> orbit/TUF.md'
 	sh -c 'echo "\n## \`edge\`\n" >> orbit/TUF.md'

articles/articles/preventing-mistakes-with-gitops.md

@@ -0,0 +1,94 @@
+## Introduction
+
+All SysAdmins have been there. It’s Friday afternoon - you make a few wrong clicks in your MDM. All of a sudden, devices that were in a specific team granting users access to your internal network have a configuration profile revoked. Just as you’re ready to sign off for the weekend you start getting Slack messages and realize your mistake. 😳
+
+It’s a tough lesson to learn. 
+
+But, what if there was a way, through GitOps and change management best practices, you could avoid all this? A modern change management methodology typically reserved for developers has now arrived for your IT team. 🛬
+
+## What is “GitOps”?
+
+GitOps is an operational framework that takes best practices used for application development such as version control, collaboration, compliance, and continuous integration / development, and applies them to device management automation. Key attributes of this system:
+
+- Configurations are declaritively defined in a repo (such as GitHub or GitLab)
+- Configurations represent a single source of truth for system state
+- Automated synchronization between git and live infrastructure
+- Continuous reconciliation to maintain system state
+- Immutable configuration is managed through pull requests and code reviews
+
+The ultimate goals of this approach? Improve reliability, reduce errors, and enable consistent, auditable management of your device infrastructure. 
+
+## Getting Started 
+
+Fleet publishes a starter template that we recommend checking out (available for both GitHub and GitLab.) 
+
+> In this article we will be using GitHub but the general principles are the same. 
+
+Clone the starter repo: `https://github.com/fleetdm/fleet-gitops` and create your own repo to which you will push code. 
+
+> In a production environment, it is best to protect the `main` branch and only allow merging after a code review is conducted. It can be modified if needed, but, by default the apply action will run whenever code is committed to `main`.
+
+An important benefit of GitOps is the ability to store all your environment secrets in GitHub - encrypted and protected from view. With the correct configuration, this prevents tampering and leaks.
+
+Add the `FLEET_URL` and `FLEET_API_TOKEN` secrets to your new repository's secrets. If you’re working out of the template, also add `FLEET_GLOBAL_ENROLL_SECRET`, `FLEET_WORKSTATIONS_ENROLL_SECRET` and `FLEET_WORKSTATIONS_CANARY_ENROLL_SECRET`.
+
+This can be adjusted depending on how you want to leverage Teams and team names.
+
+## A Typical GitOps Workflow
+
+We will start with a traditional workflow to demonstrate the process used to commit changes to your Fleet instance. In this example we are adding a passcode policy for Macs by setting the minimum length to 12 characters. 
+
+> For all examples in this article we will be using the GitHub Desktop app to do commits. Using `git` in the terminal will of course also work. Use whatever you’re most comfortable with.
+
+![gif-1](../website/assets/images/articles/preventing-mistakes-1-1423x771@2x.gif)
+
+Here, after making changes to the `passcode.json` file, it has been added to the Team we are configuring under the `macos_settings` section.
+
+![gif-2](../website/assets/images/articles/preventing-mistakes-2-960x540@2x.gif)
+
+GitHub Desktop will automatically pick up changes. You can review each file and make commit comments. If all looks good, push your changes to the working branch.
+
+![gif-3](../website/assets/images/articles/preventing-mistakes-3-1423x771@2x.gif)
+
+We create a PR to bring this change into the `main` production branch. In this example, branch protections are off so I can merge right to `main` but further on in the article this will change. 
+
+## GitOps: The way it was meant to be
+
+Another benefit of a GitOps approach is the ability for members of a team to review changes before they are applied in production. This encourages collaboration while ensuring all modifications to state are following best practices and compliance. In addition, if something breaks (which is inevitable) you have a ‘snapshot’ or point in time with a known working state to which you can easily roll back.
+
+![gif-4](../website/assets/images/articles/preventing-mistakes-4-960x540@2x.gif)
+
+The newest version of macOS is released and an engineer on your team wants to push a change to require an update of all hosts in the Workstations team. The IT engineer creates a branch to work from and makes the necessary changes, including setting a new target version and deadline.
+
+```
+macos_updates:
+    deadline: "2025-02-15"
+    minimum_version: "15.4.1"
+```
+
+Merging is blocked until a member of the team reviews and approves the changes. 
+
+![gif-5](../website/assets/images/articles/preventing-mistakes-5-960x540@2x.gif)
+
+Our IT manager is listed as the approver for these changes. The approver is notified of a pending PR for review. Is there a problem with some of the changes? Our engineer accidentally put in a version string that is not yet available. This will cause issues for our users when they try to update. The fix? Tag the engineer with some feedback and request changes to be made and re-committed. 
+
+![Pr Approval](../website/assets/images/articles/pr-approval-921x475@2x.jpg)
+
+After our engineer has updated code from the review, the approver can do a final review, approve and let the engineer merge this branch into `main` to trigger the apply workflow. This will push the changes into the production environment. ✨
+
+![Pr Approval](../website/assets/images/articles/pr-approval-2-933x483@2x.jpg)
+
+## Conclusion
+
+By adopting GitOps for device management, your team's work becomes observable, reversible and repeatable while automating your device configurations. Instead of making changes manually and risking unintended consequences, you gain a reliable, auditable workflow where every modification is reviewed, approved, and tracked. 
+
+This approach reduces human error and fosters teamwork. Whether you're enforcing security policies, managing OS updates, or deploying configuration changes, GitOps ensures consistency and control helping you avoid those last-minute Friday afternoon mishaps. 😥
+
+Want to know more about Fleet's comprehensive MDM platform in code? Visit fleetdm.com and use the 'Talk to an engineer' [link](https://fleetdm.com/contact).
+
+<meta name="articleTitle" value="Preventing Mistakes with GitOps">
+<meta name="authorFullName" value="Harrison Ravazzolo">
+<meta name="authorGitHubUsername" value="harrisonravazzolo">
+<meta name="category" value="guides">
+<meta name="publishedOn" value="2025-02-12">
+<meta name="description" value="Use GitOps to manage your infrastructure in code and prevent mistakes">

articles/cdn-signed-urls.md

@@ -1,5 +1,7 @@
 # How to use CloudFront signed URLs with Fleet
 
+*Available in Fleet Premium.*
+
 Fleet [v4.63.0](https://github.com/fleetdm/fleet/releases/tag/fleet-v4.63.0) allows you to use CloudFront signed URLs for downloading MDM bootstrap packages and software installation packages to your hosts. This speeds up onboarding for organizations that onboard new employees at different headquarters across the world. 
 
 CloudFront signed URLs grant access to a specific CloudFront distribution resource and are valid for a specified duration.