This filter was added in commit 4285ba4b, it was changed in commit
002d8688, and most of the code from the original commit has disappeared
without a trace (maybe due to a merge conflict?).
This filter could actually be useful if we started using it when users
click on a tag. Since we don't, I'm removing it. We might add it back if
we decide to actually use it.
We're now using the same version we used to generate our Gemfile.lock.
Using the latest bundler we got a deprecation warning, which might turn
into an error in the future:
[DEPRECATED] The `--deployment` flag is deprecated because it relies on
being remembered across bundler invocations, which bundler will no
longer do in future versions.
We could also upgrade to bundler 2.x, but since we're using Ruby 2.4 and
Ruby 2.6 comes with bundler 1.17, we've decided to keep this version.
- Validate that locale is a valid locale for RemoteTranslation Client.
- RemoteTranslation can only be created for resources that do not have the requested
language translated
The old Setting["dashboard.emails"] is a Feature Setting, but appeared as
Configuration Setting without button for enable/disable.
In this commit, we update the old setting to behave like a Feature Setting.
Too we rename setting to clarify what emails are blocked with this feature.
The test environment was using the file in `config/puma.rb`, meaning it
wouldn't work with Rails 5.1, which uses a different setup for Puma.
I've decided to create a new file called `defaults.rb`, which will be
used in every environment but development and test. We could also add an
empty file in `config/puma/test.rb`; I think that's less intuitive, but
it's a subjective opinion.
The task `deploy:restart` was doing nothing since we moved from unicorn
to puma.
Now we're also restarting delayed jobs on `deploy:restart`, which is
probably what's expected in most cases.
So now the way to restart the application does not depend on whether we
use puma or passenger.
What this plugin actually does is restarting puma when we touch the
`tmp/restart.txt` file, which is what `rails restart` does.
This way we don't have to start it manually every time the server is
restarted.
Note if we start the application with `bin/rails s start -e production`,
as we'd probably want to do so this task doesn't depend on the server we
use, the application will crash when we restart it because it will be
restarted in the development environment. Maybe this issue will be fixed
in future versions of Rails and/or Puma.
Also note we're passing `2` workers to delayed job, and this number must
be the same number we use for the `delayed_job_workers` variable in
capistrano. I haven't found a way to share this variable between
whenever and capistrano.
We need to download the most recent CONSUL and check its `.ruby-version`
file before installing Ruby.
The `rvm1-capistrano` gem knows it and was invoking the `updating` task
before installing Ruby. So we were getting a warning in Capistrano about
the `updating` task being executed twice.
New CONSUL instances who didn't use the newest installer and haven't
done any deployments with capistrano would get an exception because the
`current` capistrano folder doesn't exist yet.
We were using Capistrano's shared folder because it was the default
folder used by the capistrano-puma gem. However, it's easier to manage
it if it's under version control.
So we're moving the old `puma.rb` to `puma/development.rb`, and we use
the new `puma.rb` file for all environments except development. Anyone
installing CONSUL can change these files at will or change the specific
files for preproduction, production and staging environments.
Deploy environment files were loaded after config/deploy.rb was loaded,
meaning if we used settings like `deploy_to` or `current_path` to set
variables inside the config/deploy.rb file, we'd be using the default
settings instead of the ones dictated by the deploy environment files.
These files are only loaded when the stage already has the value set
inside them, so we don't need to set it again.
On the other hand, the `rails_env` setting is configured in the
`config/deploy.rb` file.
This is the same configuration we had with unicorn.
With several workers, we've got two basic configuration options:
* Preload the application and use a hot restart
* Don't preload the application and use a phased restart
I've decided to preload the application because using a hot restart
changes are available immediately, while with a phased restart there are
a few seconds when both workers for the old code and workers for the new
code exist.
Using a phased restart also has advantages, so some forks might want to
disable the `puma_preload_app` setting in order to use it.
Old versions of the installer created this file as root, making it
impossible to change it as a regular user.
So for old installations we need to make sure we've got write access to
this file.
We're using `sudo` because in these applications the installer gives
`sudo` access to the deploy user, so everything works fine with the
default configuration.
While this is not a secret and in theory should be in a file under
version control, currently the CONSUL installer disables delayed jobs by
default, meaning we were keeping two versions of the delayed jobs
configuration file, and some existing configurations have their settings
defined in a file in capistrano's `shared` folder.
So we're moving existing settings to the secrets file.
We were copying the current SMTP and SSL settings to the secrets file
after overwriting them, but we need to copy them before overwriting
them.
The workaround I've found is to copy the tasks to the folder of the
previous release and execute them there.
this is usually configured in the production.rb file (which is under
version control), the natural place to configure it is the secrets.yml
file.
Until now we were using the capistrano shared folder, but that's a bit
inconvenient since changes we've done to the production.rb file (like
changing eager_load_paths when we upgraded to Rails 5) won't take effect
after a deployment.
Existing installations having their configuration settings in the
capistrano shared folder needed this migration.
Note we can't just use `YAML.load` because we'd lose the anchors defined
in the file. So we have to parse the file the hard way.
Since SMTP passwords should not be in a file under version control, and
they're usually configured in the production.rb file (which is under
version control), the natural place to configure it is the secrets.yml
file.
Until now we were using the capistrano shared folder, but that's a bit
inconvenient since changes we've done to the production.rb file (like
changing eager_load_paths when we upgraded to Rails 5) won't take effect
after a deployment.
