ace1fa0d37
* stubing out required pages * Add Vanta authorization action, create externalAuthorization(name will most likely change) Model * rebuild cloud sdk * Draft script * update importer, update connect-vanta page * layout updates * update action * change model name * update model name * update script * Update vanta callback page * add new model to lint config * update model attributes * update vanta connection page to require url protocol, fix lint error in routes * rename page, vanta-callback » vanta-authorization * Update errors, handle incomplete connections * Update model attribute names * Remove console.log(), add error message for non-Fleet Premium users * update importer, fix lint error * update send-data-to-vanta script * Update create-vanta-authorization-request.js * update page name * update comments and error messages * layout changes * update status codes used in exits * Add comment * Update .eslintrc * Update create-vanta-authorization-request.js * Update view-vanta-authorization.js * Update VantaConnection.js * Update send-data-to-vanta.js * Update create-vanta-authorization-request.js * Update mobile styles * update text * update error text, show sucess message if account has already been authorized * lint fix Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| api | ||
| assets | ||
| config | ||
| scripts | ||
| tasks | ||
| views | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc | ||
| .gitignore | ||
| .htmlhintrc | ||
| .lesshintrc | ||
| .npmrc | ||
| .sailsrc | ||
| app.js | ||
| Gruntfile.js | ||
| package.json | ||
| Procfile | ||
| README.md | ||
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, click here.
Testing locally
Run the following commands to test the site locally:
npm install -g sails
cd website/
npm install
sails run scripts/build-static-content.js
sails lift
Your local copy of the website is now running at http://localhost:2024!
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!