1
0
Fork 0
forked from OpenNeo/impress
impress/deploy
Matchu 12764c44fc Attempt to fix scheduled public data export cron
This hasn't actually been running, and I'm finally looking into why!
I tested this by running `sudo -u impress COMMAND_GOES_HERE`, and found
that there were two errors: both the lack of `production.env` that I
had noticed and expected, but also that Ruby 3.3.0 wasn't in the `PATH`
value.

To fix this, I now pull in both `/etc/profile` and `~/.bash_profile`,
much like what happens automatically when we log into a shell as
`impress`, to get the environment set up! I haven't actually validated
that this Works, but I guess we'll see! I *could* change the cron
timing to some immediate time to try to watch it happen, but I'm not
invested enough right now, there's other things to do!
2024-05-02 12:21:14 -07:00
..
files Create rails public_data:commit task, to share public data dumps 2024-02-29 14:30:33 -08:00
deploy.yml Create rails public_data:commit task, to share public data dumps 2024-02-29 14:30:33 -08:00
inventory.cfg Remove beta.impress.openneo.net from deploy setup 2023-10-25 15:22:50 -07:00
README Create setup.yml deploy script 2023-10-23 19:05:09 -07:00
setup.yml Attempt to fix scheduled public data export cron 2024-05-02 12:21:14 -07:00

Dress to Impress is deployed to a VPS server. We use this Ansible Playbook to
automate the environment setup!

We expect to be deploying to Ubuntu 20.04 LTS, initially with nothing
installed. The user you deploy with should have sudoers access. That should be
all it takes!

First, run `yarn deploy:setup` in the app root, to run the `setup.yml`
playbook. This will prompt you for your root password, to set up system
dependencies. It should be safe to re-run this, including if you add a new
dependency to the playbook, because the steps are non-destructive and Ansible
will skip steps that are already satisfied.

Then, to deploy a new version of the app, run `yarn deploy`. This will build
the app from the code on your machine, then send the source and build output
to the remote machine, and switch it to be the new production version. Nice!

Note that the setup script references a file named `production.env`, which is
gitignored because it contains sensitive information, like database passwords.
You should create a `production.env` file in the local `deploy/files`
directory, to be copied to the remote server and used as its environment
variables.