Files
fleet/.github/workflows
Allen Houchins 34788f7686 Add 7-zip as a Windows Fleet-maintained app (#37222)
This pull request adds support for managing 7-Zip as a maintained
Windows application. The changes include configuration for installation
and uninstallation, workflow updates to handle 7-Zip specifically in CI,
and a new icon for the frontend. These updates ensure that 7-Zip can be
detected, installed, uninstalled, and visually represented in the
software management system.

**Windows workflow and detection updates:**

- Updated `.github/workflows/test-fma-windows-pr-only.yml` to detect
changes related to 7-Zip, set a `has_7zip` output variable, and add a
step to remove pre-installed 7-Zip versions before proceeding with
further app verification. This prevents conflicts with pre-existing
installations during CI runs.
[[1]](diffhunk://#diff-51641fd1d2cc19348b81fd8310b62ad270ca5082ceddff2d49064e78f126a1eaR91)
[[2]](diffhunk://#diff-51641fd1d2cc19348b81fd8310b62ad270ca5082ceddff2d49064e78f126a1eaR102)
[[3]](diffhunk://#diff-51641fd1d2cc19348b81fd8310b62ad270ca5082ceddff2d49064e78f126a1eaR117-R124)
[[4]](diffhunk://#diff-51641fd1d2cc19348b81fd8310b62ad270ca5082ceddff2d49064e78f126a1eaR164-R227)

**7-Zip application configuration:**

- Added `ee/maintained-apps/inputs/winget/7-zip.json` to define 7-Zip as
a maintained app with metadata such as slug, package identifier,
installer type, and categories.
- Added `ee/maintained-apps/outputs/7-zip/windows.json` with version
info, installation and uninstallation scripts, SHA256, and upgrade code
for 7-Zip, enabling automated install/uninstall flows.
- Updated `ee/maintained-apps/outputs/apps.json` to include 7-Zip in the
list of available apps, with a description and unique identifier for
display and selection.

**Frontend icon support:**

- Added a new React SVG icon component for 7-Zip at
`frontend/pages/SoftwarePage/components/icons/7Zip.tsx`.
- Registered the 7-Zip icon in the icon index and mapped it in
`SOFTWARE_NAME_TO_ICON_MAP` to display the icon for 7-Zip in the UI.
[[1]](diffhunk://#diff-628095892e1d16090be1db6cc1a5c9cebc65248c32a8b1312385394818f2907bR7)
[[2]](diffhunk://#diff-628095892e1d16090be1db6cc1a5c9cebc65248c32a8b1312385394818f2907bR224)
2025-12-16 09:55:30 -06:00
..

Github Actions

Fleet uses Github Actions for continuous integration (CI). This document describes best practices and at patterns for writing and maintaining Fleet's Github Actions workflows.

Bash

By default, Github Actions sets the shell to bash -e for linux and MacOS runners. To help write safer bash scripts in run jobs and avoid common issues, override the default by adding the following to the workflow file

defaults:
  run:
    # fail-fast using bash -eo pipefail. See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference
    shell: bash

By specifying the default shell to bash, some extra flags are set. The option pipefail changes the behaviour when using the pipe | operator such that if any command in a pipeline fails, that commands return code will be used a the return code for the whole pipeline. Consider the following example in test-go.yaml

    - name: Run Go Tests
      run: |
        # omitted ...
          make test-go 2>&1 | tee /tmp/gotest.log

If the pipefail option was not set, this job would always succeed because tee would always return success. This is not the intended behavior. Instead, we want the job to fail if make test-go fails.

Concurrency

Github Action runners are limited. If a lot of workflows are queued, they will wait in pending until a runner becomes available. This has caused issue in the past where workflows take an excessively long time to start. To help with this issue, use the following in workflows

# This allows a subsequently queued workflow run to interrupt previous runs
concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id}}
  cancel-in-progress: true

When a workflow is triggered via a pull request, it will cancel previous running workflows for that pull request. This is especially useful when changes are pushed to a pull request frequently. Manually triggered workflows, workflows that run on a schedule, and workflows triggered by pushes to main are unaffected.