This PR makes several improvements to test-go CI job
- remove ZSH dependency from all test suites except for a new `scripts`
suite
- add a `fast` suite that does not have out-of-process dependencies,
which completes in ~1.5 minutes
- contributors can add their fast tests to this suite so they can see
the results in CI faster
- Rename `core` to `main` test suite to be consistent with Makefile. It
is the default bucket for tests.
- Cleaned up Makefile so that it is more straightforward to add new test
suites or move Go packages between suites
- Do not stop the test suites on a fail.
- We do not want to be blocked by a test fail that another product team
introduced
- Sometimes, we want to see all test failures so we can fix them all at
once.
- Removed `test-schema` and `mock` prerequisites for `test-go` since
they are not needed and just take up time.
- But also added `test-schema` run to one of the test suites just in
case.
Unfortunately, `fleetctl` is still the bottleneck and needs to be
refactored. New issue filed:
https://github.com/fleetdm/fleet/issues/27927
## Before
<img width="248" alt="image"
src="https://github.com/user-attachments/assets/110ffc1d-f090-4d3e-be77-0419b9577d20"
/>
## After
<img width="320" alt="image"
src="https://github.com/user-attachments/assets/8d01ea11-408f-4eb6-81d8-9c25410b8830"
/>
Release notes: https://tip.golang.org/doc/go1.24
> Go modules can now track executable dependencies using tool directives
in go.mod. This removes the need for the previous workaround of adding
tools as blank imports to a file conventionally named “tools.go”. The go
tool command can now run these tools in addition to tools shipped with
the Go distribution. For more information see [the
documentation](https://tip.golang.org/doc/modules/managing-dependencies#tools).
The new -tool flag for go get causes a tool directive to be added to the
current module for named packages in addition to adding require
directives.
I ran:
```
go get -tool github.com/fleetdm/fleet/v4/server/goose
go get -tool github.com/kevinburke/go-bindata
go get -tool github.com/quasilyte/go-ruleguard/dsl
go rm tools.go
go mod tidy
```
`make deps-go` was failing in CI because of the removal of `tools.go`
(my guess is that `go get .` was a nop because there was nothing in `.`
to download).
So, taking the chance of removing `deps-go` because `go` will download
packages during the build process. AFAICS there's no need to download
everything beforehand.
For #21396
# Details
This PR updates the automated release cycle for Orbit desktop, so that
it triggers based on a pushed _tag_ rather than a pushed PR. This has
the following benefits:
* The release can be based off of any branch, rather than always using
`main` as the base, so we can safely do patch release of desktop without
including in-progress code from main
* It brings the desktop release process more in line with the main Orbit
release process -- both are now triggered by a tag push.
We still create a PR for the release, to include a changelog.
# 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. -->
- [ ] Manual QA must be performed in the three main OSs, macOS, Windows
and Linux.
- [ ] Auto-update manual QA, from released version of component to new
version (see [tools/tuf/test](../tools/tuf/test/README.md)).
## Testing
To do -- will discuss with @lucasmrod
---------
Co-authored-by: Luke Heath <luke@fleetdm.com>
When Go version switched from being hardcoded to being based off of the
deps file, Fleet being checked out into a subdir wasn't taken into
account, so FMA ingest jobs started failing. This adds the (hopefully)
correct dir to fix the issue and get FMA ingest working again.
- Update story template as a reminder for Product Designers to consider
Fleet's breakpoints: 480, 768, 1024, 1280, and 1440px
- Only need wireframes when there are substantial changes (ex. dropping
columns or wrapping elements)
- Update Product Groups handbook to clarify that Engineers are
responsible for filling in gaps for smaller changes. Engineers bring
proposed changes to their product group's design review meeting.
For #27267.
Below is what's shown immediately after selecting an EXE:
<img width="1254" alt="image"
src="https://github.com/user-attachments/assets/a28d8565-de88-448a-bdbc-92aefc34ad55"
/>
TODO:
* Tests
* GitOps requirements changes
* Disabling add button/adding errors when required scripts aren't
specified
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [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] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [x] Added/updated automated tests
- [x] A detailed QA plan exists on the associated ticket (if it isn't
there, work with the product group's QA engineer to add it)
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Luke Heath <luke@fleetdm.com>
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
Co-authored-by: RachelElysia <rachel@fleetdm.com>
For #26713
# Details
This PR updates Fleet and its related tools and binaries to use Go
version 1.24.1.
Scanning through the changelog, I didn't see anything relevant to Fleet
that requires action. The only possible breaking change I spotted was:
> As [announced](https://tip.golang.org/doc/go1.23#linux) in the Go 1.23
release notes, Go 1.24 requires Linux kernel version 3.2 or later.
Linux kernel 3.2 was released in January of 2012, so I think we can
commit to dropping support for earlier kernel versions.
The new [tools directive](https://tip.golang.org/doc/go1.24#tools) is
interesting as it means we can move away from using `tools.go` files,
but it's not a required update.
# 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`.
- [x] Manual QA for all new/changed functionality
- For Orbit and Fleet Desktop changes:
- [X] Make sure fleetd is compatible with the latest released version of
Fleet
- [x] Orbit runs on macOS ✅ , Linux ✅ and Windows.
- [x] Manual QA must be performed in the three main OSs, macOS ✅,
Windows and Linux ✅.
- Move duplicate scripts out of `scripts/mdm/` and into
`it-and-security/` so we have one version that we can continue to
iterate and improve.
- Remove no longer used scripts out of `scripts/mdm/`
---------
Co-authored-by: Lucas Manuel Rodriguez <lucas@fleetdm.com>
We have a scheduled action to create an "Update Fleet-maintained apps"
PR with the latest updates for FMAs. The bot creates a new PR each time,
even if the previous PRs haven't been merged. Since the latest PR will
always have all the latest updates, it's unnecessary to keep the old
ones around. We should have the bot close the old PRs once the new one
is opened. Additionally it was recommended that assignees be added to
the PR.
This PR updates the action to:
1. Find existing "Update Fleet-maintained apps" PRs created by the bot
2. Get the list of Github IDs of the devs on the software product team
3. Creates a new PR as usual, adding the devs as assignees
4. If the new PR is created successfully, closes the old PRs with
comments linking to the new PR
See a successful run
[here](https://github.com/fleetdm/fleet/actions/runs/13977643317/job/39135240445),
+ the resulting PR [here](https://github.com/fleetdm/fleet/pull/27357)
---------
Co-authored-by: Tim Lee <timlee@fleetdm.com>
This PR simplifies the `test/upgrade` tool the QA team uses to test DB
upgrades.
- Removes "online migration" approach because we currently don't support
it (so it removes nginx as dependency).
- Adds a workflow to manually run this on Github actions (in case dev/QA
folks have issues with Docker on macOS, which is a common thing...)
- Adds logging to the output to ease troubleshoot (previous versions was
too quiet making it impossible to troubleshoot).
For #27155.
Reverting to use ubuntu-20.04 to unblock the release of fleetd 1.40.1.
We'll need a proper solution for 1.41.0 given that ubuntu-20.04 will be
removed on April 1st 2025.
- [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.
> For #26083
# 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] Added/updated automated tests
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Ian Littman <iansltx@gmail.com>
From what I can tell, continue-on-error has been false for the
integration suites since the suites were renamed to `integration-*`, so
this fixes that issue in addition to continuing to run test suites when
the vulns suite fails (which may be due to vulns feed updates).
This also makes the vulns test more resilient to new CVEs being reported
on Python 3.12.0, which is rather likely to collect new CVEs.
# Checklist for submitter
- [x] Added/updated automated tests
Switched from metadata_url to metadata for end user authentication.
---------
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
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.
For #25349
This updates storybook and its addons to 8.4.7. This is done to remove
the transitive dependency on path-to-regexp,
which is no longer used in this version of storybook.
This will fix the original vulnerability issue for `path-to-regexp`
For #25507
A bump to the latest version to the github `cache` action to 4.2.0. our
current version (v2) was deprecated. more info for the deprecation can
be found here https://github.com/actions/cache/discussions/1510
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
User stories that are yet to be prioritized are clogging up the "New
requests" column on the drafting board. Only new feature requests should
show up in this column
# Changes
- orbit >= 1.38.0, when configured to connect to
https://tuf.fleetctl.com (existing fleetd deployments) will now connect
to https://updates.fleetdm.com and start using the metadata in path
`/opt/orbit/updates-metadata.json`.
- orbit >= 1.38.0, when configured to connect to some custom TUF (not
Fleet's TUFs) will copy `/opt/orbit/tuf-metadata.json` to
`/opt/orbit/updates-metadata.json` (if it doesn't exist) and start using
the latter.
- fleetctl `4.63.0` will now generate artifacts using
https://updates.fleetdm.com by default (or a custom TUF if
`--update-url` is set) and generate two (same file) metadata files
`/opt/orbit/updates-metadata.json` and the legacy one to support
downgrades `/opt/orbit/tuf-metadata.json`.
- fleetctl `4.62.0` when configured to use custom TUF (not Fleet's TUF)
will generate just the legacy metadata file
`/opt/orbit/tuf-metadata.json`.
## User stories
See "User stories" in
https://github.com/fleetdm/confidential/issues/8488.
- [x] Update `update.defaultRootMetadata` and `update.DefaultURL` when
the new repository is ready.
- [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] Added/updated tests
- [X] Manual QA for all new/changed functionality
- For Orbit and Fleet Desktop changes:
- [X] Orbit runs on macOS, Linux and Windows. Check if the orbit
feature/bugfix should only apply to one platform (`runtime.GOOS`).
- [X] Manual QA must be performed in the three main OSs, macOS, Windows
and Linux.
- [X] Auto-update manual QA, from released version of component to new
version (see [tools/tuf/test](../tools/tuf/test/README.md)).
See failed workflow run
[here](https://github.com/fleetdm/fleet/actions/runs/12555703803)
- Fix the powershell script that was broken by `.yml` auto-format
- Exclude github workflow `.yml` files from prettier autoformating,
since they often contain non-yaml code as part of job definitions
- [ ] Manual QA for all new/changed functionality
---------
Co-authored-by: Jacob Shandling <jacob@fleetdm.com>
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
updated a few sections and added iOS/iPadOS tests
# Checklist for submitter
---------
Co-authored-by: Janis Watts <184028114+jmwatts@users.noreply.github.com>
for #23825
This PR fixes the previous implementation for attesting
fleet/fleetctl/orbit binaries, and adds attestation to the fleet desktop
and osqueryd artifacts.
* correct permissions are added to all jobs
* tag removed from `subject-name` when attesting docker image
* using `artifacts.json` rather than the `artifacts` step output from
goreleaser to determine image digest
I'd like to add a separate job verifying the attestations, working on
that now but since all attestation steps are marked as
`continue-on-error` it can be a follow-on if we don't get it in with
this PR.
This PR adds a new workflow called "Stress Test Go Test" (aka the
RandoKiller) that allows running one or more tests repeatedly up to a
set number of times, or until a test fails. This is useful for:
* Trying to diagnose and debug a flaky test
* Verifying that a proposed fix for a flaky test actually works.
To use:
1. Create a branch whose name ends with "-randokiller"
2. Modify the .github/workflows/config/randokiller.json file to your
specifications (choosing the packages and tests to run, the mysql
matrix, and the number of runs to do)
3. Push up the branch
Since the stress test is intended to run a branch that you'll never
merge, you should feel free to add whatever logs to your tests or code
that will help diagnose failures.
I used this to diagnose and fix
https://github.com/fleetdm/fleet/pull/24697!
for #19106
This PR adds a Slack notification when the GitOps run fails in the
dogfood-gitops workflow. Whenever the actual GitOps action fails, it
should notify #help-dogfooding with a link to the failed action. Note
that this will alert on both merges to main and scheduled runs, which I
think we want. Also note that this is [currently failing on
main](https://github.com/fleetdm/fleet/actions/runs/12154006118) so this
alert will start going off daily until the issue is fixed 😶
### > Note: this will need a new Slack incoming webhook for sending
messages to #help-dogfooding, and a new
`SLACK_G_HELP_DOGFOODING_WEBHOOK_URL` repo secret with the webhook URL.
I tested this on a personal private repo just to make sure I got all the
syntax right:
<img width="422" alt="image"
src="https://github.com/user-attachments/assets/74d188eb-5c03-471b-a5db-9f578a56e2ab">
I beleive we don't need this step anymore, since `fleetctl gitops` will
replace it with real value and send to the server. This should be done
in #17309.
[#8489](https://github.com/fleetdm/confidential/issues/8489)
We had the timestamp check.
Robert added the root check recently.
Am now duplicating the check for `snapshot` and `targets` metadata
files.
PS: Please review with whitespace changes disabled.
#23905
- Update with upstream nanomdm changes up to
825f2979a2
- Removed PostgeSQL folder from our nanomdm
- Added nanomdm MySQL test job to our CI
# Checklist for submitter
- [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] Added/updated tests
- [x] Manual QA for all new/changed functionality
From discussions with @jahzielv.
QAing ADE flows:
1. New version of fleetd is pushed to `edge`
2. QA folks can trigger this new workflow and download the generated
`fleetd-base.pkg` and `fleetd-base-manifest.plist`.
3. Host the downloaded files (in `foobar/`) in their ngroks URLs (using
e.g. `go tools ./tools/file-server 8085 foobar/`)
4. Use Fleet's `FLEET_DEV_DOWNLOAD_FLEETDM_URL` to point the Fleet
server to their ngrok URL.
Closes: https://github.com/fleetdm/confidential/issues/8351
Changes:
- Deleted the "Deploy app to bulk operations dashboard pipeline on
Heroku" workflow. This dashboard is now hosted in Render, and deploys
are triggered manually via the Render dashboard.
Closes: #22931
Changes:
- Updated the deploy workflows for the Fleet website and the
vulnerability dashboard to run on Ubuntu 22.04 to prevent issues we've
been seeing with the Heroku deploy action and the latest version of
Ubuntu.
#22206
This was discussed in the backend weekly.
Currently the test-packaging.yml is extremely unreliable (it has more
failures than successes), because of issues with Docker and colima on
Github macOS runners (we tried docker then colima but both have issues,
timeouts, etc.).
This only removes testing of MSI package generation from macOS. IMO this
is low risk as almost all Fleet devs generate MSI packages from their
macOS workstations.
This fix applies to cases (e.g.
00ec402f18) where order of files being
added is e.g.:
1. Migration A
2. Migration B
3. Test for migration A
This also reorders workflow steps so the ones that don't require setting
up Go + compiling happen first, so if we have a migration issue it gets
reported sooner.
# Checklist for submitter
- [x] Manual QA for all new/changed functionality
