Allen Houchins
2b5e5049ed
This pull request adds support for PowerShell as a managed Windows app, including its metadata, versioning, install/uninstall scripts, and validation logic in the CI workflow. It also ensures that any pre-installed PowerShell 7 is removed from the test environment before validation. The most important changes are: **PowerShell app definition and metadata:** * Added a new entry for PowerShell in `ee/maintained-apps/inputs/winget/powershell.json` and included its metadata in `ee/maintained-apps/outputs/apps.json`, enabling PowerShell to be managed as a Windows app. [[1]](diffhunk://#diff-7e4899a379d327948f55b7e6ba4c9893501713edd16020b128b68343569fcbfbR1-R10) [[2]](diffhunk://#diff-4c1446cfc02c6bb0bda874481e333c65b84e184fcea52f656b49a6489f73c9c2R1985-R1991) * Created `ee/maintained-apps/outputs/powershell/windows.json` containing version information, SQL queries for existence and patch status, installer/uninstaller scripts, and download URL for PowerShell 7.6.2.0. **CI workflow enhancements for PowerShell:** * Updated `.github/workflows/test-fma-windows-pr-only.yml` to detect changes involving PowerShell, set the appropriate output flags, and conditionally execute PowerShell-specific steps. [[1]](diffhunk://#diff-51641fd1d2cc19348b81fd8310b62ad270ca5082ceddff2d49064e78f126a1eaR102) [[2]](diffhunk://#diff-51641fd1d2cc19348b81fd8310b62ad270ca5082ceddff2d49064e78f126a1eaR116) [[3]](diffhunk://#diff-51641fd1d2cc19348b81fd8310b62ad270ca5082ceddff2d49064e78f126a1eaR155-R162) * Added a workflow step to remove any pre-installed PowerShell 7 from the GitHub Actions runner, ensuring a clean environment for validation. * Ensured that validation and related steps use Windows PowerShell 5.1 (not pwsh) after uninstalling PowerShell 7, to avoid shell availability issues. These changes collectively enable PowerShell to be validated, installed, and uninstalled as part of the managed apps ecosystem and ensure reliable, repeatable CI validation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added PowerShell as a supported application with full Windows integration, including installation and uninstall management capabilities. * Enhanced deployment scripts to support flexible input handling for app configurations. * Added PowerShell icon to the frontend UI for visual identification. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
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 runandnpm runcommands in there do, check the scripts inwebsite/package.jsonand inwebsite/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!