If OPENPROJECT_DISABLE__MIGRATIONS__CHECK is set to 'true', then the
pending migrations screen will not be displayed. Useful to test some
stuff while working on migrations. But a yellow annoying banner will be
displayed in the bottom of OpenProject page instead.
So one may avoid errors like
NameError: uninitialized constant Authorization::UserGlobalRolesQuery
Authorization::UserGlobalRolesQuery.query(user)
^^^^^^^^^^^^^^^^^^^^^^
while debugging with pry.
Updates the copyright to 2021 for all files that have a copyright. Files in our source code without the copyright header still do not receive one automatically. Additionally, backlisted files are also excluded.
Previously the copyright of chiliproject which references redmine stated a copyright of redmine up to and including 2017 which is not true for the code we have in here. Because of that I changed that to 2013
This reverts commit f920cc73a0.
We originally removed event base file checking to cope with problems on
os x that would lead to having a multitude of fsevent_watch processes
(one for every directory) and those processes would sometimes, e. g. when
the system was sent to standby turn zombie. If not killed dutifully by the
developer, the system would become unresponsive as the maximum number of
processes as dictated by the os would be reached. Not even killing
processes would be possible any more as kill requires forking.
Now the listen gem was released as version 3.2.1 which changed to only
needing one process to watch all directories.
As event based dirty checking promises to be more performant than
checking all the files, and the reload time in dev mode would exceed
tens of seconds if kept running for a longer period of time, I took
another stab at integrating the listen gem again:
The good:
* The file checking seems to work. Altering the code is reflected by the
application.
* Only two fsevent_watch processes are created (one for the code files
and one for the locales.)
* The fsevent_watch processes where exited as desired when the rails
process was existed. I did not yet test it for an extended amount of
time but this also seems to hold true when the system was suspended in
the meantime.
The bad:
* Subjectively, reloading did not seem to be faster. However, I did not
leave the server running over an extended period of changes. So the
event based detection might shine in the long run.
The ugly:
* When running multitreaded, the server seems to be running into
deadlocks. I assume, that there is a shared, but mutexed, resource multiple threads
attempt to access at the same time. It does not happen on every page but
one of the roadmap pages on my development env causes the problem
consistently. The problem can be circumvented by disabling multi
treading:
`RAILS_MIN_THREADS=1 RAILS_MAX_THREADS=1 bundle exec rails s`
The same problem does not occur when running the server with multiple
worker processes:
`OPENPROJECT_WEB_WORKERS=4 RAILS_MIN_THREADS=1 RAILS_MAX_THREADS=1
bundle exec rails s`
Mir Bhatia