Files
fleet/website
Lucas Manuel Rodriguez 2b822ac0ee Add dummy go.mod files to exclude directories from Go module (#46569)
Resolves #42818.

(I explicitly removed all checklist items.)

This is the least destructing approach to solve the issue.
Other approaches require like moving all Go code under a sub-directory
or keeping these docs/ directories free from invalid characters.

## Problem

[Publishing of Fleet's go
module](https://github.com/fleetdm/fleet/actions/runs/23857371168/job/69554220876)
is failing with the following error:
```
Run GOPROXY=proxy.golang.org go list -m github.com/fleetdm/fleet/v4@v4.83.0
go: github.com/fleetdm/fleet/v4@v4.83.0: reading https://proxy.golang.org/github.com/fleetdm/fleet/v4/@v/v4.83.0.info: 404 Not Found
	server response:
	not found: create zip: docs/solutions/windows/configuration-profiles/allow network connectivity during connected standby – [ACConnectivityInStandby_2, DCConnectivityInStandby_2].xml: malformed file path "docs/solutions/windows/configuration-profiles/allow network connectivity during connected standby – [ACConnectivityInStandby_2, DCConnectivityInStandby_2].xml": invalid char '–'
	[Truncated: too long.]
```

## Summary

Root cause

The [publish go module
step](https://github.com/fleetdm/fleet/blob/main/.github/workflows/publish-go-module.yml)
asks proxy.golang.org to build a module zip for the v4.X.Y tag. That
build was failing on two independent, each-fatal issues — both stemming
from the monorepo carrying non-Go content that violates Go module zip
rules:

1. Invalid path characters — 35 tracked files with characters Go module
zips forbid: en-dash – in 32
docs/solutions/windows/configuration-profiles/*.xml files (the one in
your error), emoji 📜 in 2 handbook/company/legal/ files, and an
apostrophe in 1 website/assets/ image. This is the literal create zip: …
invalid char '–' error.
2. Source tree too large — 582 MiB tracked vs Go's hard 500 MiB limit;
website/ alone is 318.7 MiB.

## Fix

Added a go.mod to website/, docs/, and handbook/, turning each into a
nested module that x/mod/zip omits from the published v4 module — the
same pattern Fleet already uses under tools/. One move solves both: all
35 bad filenames live in those three dirs, and excluding them drops the
module to 207 MiB tracked → 112 MiB zipped.

Files created:
- website/go.mod, docs/go.mod, handbook/go.mod (module markers, each
with a comment explaining why)

Verified safe: no .go files and no //go:embed references in those dirs,
and go list ./... still resolves all 491 packages.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
* Added standalone module configurations for documentation, handbook,
and website directories.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-06-03 15:33:14 -03:00
..
2026-06-02 23:41:17 -05:00
2026-06-03 11:27:46 -04:00
2026-05-13 10:20:13 -04:00

fleetdm.com

This is where the code for the public https://fleetdm.com website lives.

Bugs

To report a bug or make a suggestion for the website, create an issue in the fleet GitHub repository.

Testing locally

See https://fleetdm.com/handbook/engineering#test-fleetdm-com-locally

Deploying the website

To deploy changes to the website to production, merge changes to the main branch. If the changes affect the website's code, or touch any files that the website relies on to build content, such as the query library, osquery schema, docs, handbook, articles, etc., then the website will be redeployed.

Wondering how this works? This is implemented in a GitHub action in this repo. Check out the code there to see how it works! For help understanding what sails run and npm run commands in there do, check the scripts in website/package.json and in website/scripts/.

Changing the database schema

To deploy new code to production that relies on changes to the database schema or other external systems (e.g. Stripe), first put the website in "maintenance mode" in Heroku. Then, make your changes in the database schema. Next, if you have a script to fix/migrate existing data, go ahead and run it now. (e.g. sails run fix-or-migrate-existing-data). Then, merge your changes and wait for the deploy to finish. Finally, switch off "maintenance mode" in Heroku.

Note that entering maintenance mode prevents visitors from using the website, so it should be used sparingly, and ideally at low-traffic times of day.

Warning: Doing an especially sensitive schema migration? There is a potential timing issue to consider, thanks to an infrastructure change that eliminated downtime during deploys by using Heroku's built-in support for hot-swapping. Read more in https://github.com/fleetdm/fleet/issues/6568#issuecomment-1211503881

Wiping the production database

I hope you know what you're doing. The "easiest" kind of database schema migration:

sails_datastores__default__url='REAL_DB_URI_HERE' sails run wipe

Then when you see the sailboat, hit CTRL+C to exit. All done!