Currently none of our FMA validation runs are completing successfully.
With 100+ FMAs now available in our library. the workflow for validating
new apps is taking over an hour to run and prone to timeouts because it
validates all apps on every pull request, including checking Windows
apps when a new macOS app is submitted. These new workflows validate
only newly added FMAs while keeping the workflows for validating all
apps available for manual runs.
---------
Co-authored-by: Luke Heath <luke@fleetdm.com>
Refactored the macOS and 1Password policy updater scripts to remove
direct git and PR creation logic, delegating these tasks to the GitHub
Actions workflow. Enhanced the workflow to handle git operations, detect
changes, create or close pull requests, and set appropriate permissions
and concurrency. This improves maintainability and centralizes
automation logic within the workflow.
Changed file permissions for dogfood-update-testing-qa-apps.sh to make
it executable.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves #
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [ ] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
See [Changes
files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files)
for more information.
- [ ] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [ ] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [ ] Added/updated automated tests
- [ ] Where appropriate, [automated tests simulate multiple hosts and
test for host
isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing)
(updates to one hosts's records do not affect another)
- [ ] QA'd all new/changed functionality manually
For unreleased bug fixes in a release candidate, one of:
- [ ] Confirmed that the fix is not expected to adversely impact load
test results
- [ ] Alerted the release DRI if additional load testing is needed
## Database migrations
- [ ] Checked schema for all modified table for columns that will
auto-update timestamps during migration.
- [ ] Confirmed that updating the timestamps is acceptable, and will not
cause unwanted side effects.
- [ ] Ensured the correct collation is explicitly set for character
columns (`COLLATE utf8mb4_unicode_ci`).
## New Fleet configuration settings
- [ ] Setting(s) is/are explicitly excluded from GitOps
If you didn't check the box above, follow this checklist for
GitOps-enabled settings:
- [ ] Verified that the setting is exported via `fleetctl
generate-gitops`
- [ ] Verified the setting is documented in a separate PR to [the GitOps
documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485)
- [ ] Verified that the setting is cleared on the server if it is not
supplied in a YAML file (or that it is documented as being optional)
- [ ] Verified that any relevant UI is disabled when GitOps mode is
enabled
## fleetd/orbit/Fleet Desktop
- [ ] Verified compatibility with the latest released version of Fleet
(see [Must
rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md))
- [ ] If the change applies to only one platform, confirmed that
`runtime.GOOS` is used as needed to isolate changes
- [ ] Verified that fleetd runs on macOS, Linux and Windows
- [ ] Verified auto-update works from the released version of component
to the new version (see [tools/tuf/test](../tools/tuf/test/README.md))
Introduces a GitHub Actions workflow and supporting shell script to
automatically update the `fleet_maintained_apps` list in
`testing-and-qa.yml` with new apps from `apps.json`. The workflow runs
on a schedule or manually, installs dependencies, updates the YAML file,
and creates or updates pull requests as needed.
This is the initial pull request to implement keeping policy logic up to
date automatically. For example, when a new version of macOS releases,
admins don't need to manually update the policy logic for checking
version numbers.
This is currently blocked by this issue: fleetdm/confidential#9470
This is also to support the following issue and demonstrate to customers
a fully automated patch management strategy:
https://github.com/fleetdm/confidential/issues/8825
This current iteration contains a script/workflow that runs every 6
hours to check if a new version of macOS has been released and compares
the version string to what is currently defined in our policy. If it
detects a change, it will automatically create a new branch with the
updated version string and create a pull request to be reviewed before
merging.
Also updates said constant via this script to include 5.15.0. Idea for
this is that including pre-releases as they're published ensures that by
the time the corresponding Fleet release ships we have a current list,
without having to cherry-pick these updates.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
See [Changes
files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Committing-Changes.md#changes-files)
for more information.
- [x] Manual QA for all new/changed functionality
Providing a Helm chart makes it easier for users to deploy to Kubernetes.
I think this is good to go, and I've tested deploying to Kind and GKE using the GKE ingress, sql proxy, and managed certificate, but I haven't tested anything AWS related.
