Formalize post-install/upgrade tasks and fix version-only upgrades.

Review Request #11339 — Created Dec. 17, 2020 and submitted

Information

Review Board
release-4.0.x

Reviewers

We have a few tasks that must be completed during an install or upgrade.
One is to register new SCMTools, and the other is to update the version
stored in the siteconfig.

With Django 1.6 times, we'd accomplish these by registering
post_syncdb signal handlers that would execute the necessary database
code, which made sense initially, but it meant that we had little
control over the order of operations. It also wasn't future-proof.

Given how installs/upgrades work now, we'd never get the equivalent
modern signals if we didn't need to perform a database upgrade. We'd
determine that no changes were made to the database, and simply skip the
process that would ultimately emit the signal.

Now, we have a dedicated function and signal for post-install/upgrade
steps. This registers SCMTools, updates the version in the database,
and emits a signal for any further tasks.

This is called both by rb-site and manage.py upgrade. It will not
be called with a simple evolve --execute.

A new manage.py createdb command has been added to help with the
installation side of this for development servers.

Tested creating and upgrading sites using rb-site. Verified the
resulting database entries.

Tested creating using manage.py createdb. Verified the database
entries.

Tested upgrading using manage.py upgrade. Verified the database
entries.

Unit tests passed.

Summary ID
Formalize post-install/upgrade tasks and fix version-only upgrades.
We have a few tasks that must be completed during an install or upgrade. One is to register new SCMTools, and the other is to update the version stored in the siteconfig. With Django 1.6 times, we'd accomplish these by registering `post_syncdb` signal handlers that would execute the necessary database code, which made sense initially, but it meant that we had little control over the order of operations. It also wasn't future-proof. Given how installs/upgrades work now, we'd never get the equivalent modern signals if we didn't need to perform a database upgrade. We'd determine that no changes were made to the database, and simply skip the process that would ultimately emit the signal. Now, we have a dedicated function and signal for post-install/upgrade steps. This registers SCMTools, updates the version in the database, and emits a signal for any further tasks. This is called both by `rb-site` and `manage.py upgrade`. It will *not* be called with a simple `evolve --execute`. A new `manage.py createdb` command has been added to help with the installation side of this for development servers.
aab9fb98aa2bfbbce512d6dbd32e167d1bdaecdc
Description From Last Updated

F821 undefined name 'signals'

reviewbotreviewbot

E126 continuation line over-indented for hanging indent

reviewbotreviewbot

Finalizing is super programmer-speak. Maybe "Finishing"?

daviddavid
Checks run (1 failed, 1 succeeded)
flake8 failed.
JSHint passed.

flake8

chipx86
chipx86
Review request changed

Change Summary:

Changed the "Upgrading to ..." message to "Upgraded to ...", and localized it.

Commits:

Summary ID
Formalize post-install/upgrade tasks and fix version-only upgrades.
We have a few tasks that must be completed during an install or upgrade. One is to register new SCMTools, and the other is to update the version stored in the siteconfig. With Django 1.6 times, we'd accomplish these by registering `post_syncdb` signal handlers that would execute the necessary database code, which made sense initially, but it meant that we had little control over the order of operations. It also wasn't future-proof. Given how installs/upgrades work now, we'd never get the equivalent modern signals if we didn't need to perform a database upgrade. We'd determine that no changes were made to the database, and simply skip the process that would ultimately emit the signal. Now, we have a dedicated function and signal for post-install/upgrade steps. This registers SCMTools, updates the version in the database, and emits a signal for any further tasks. This is called both by `rb-site` and `manage.py upgrade`. It will *not* be called with a simple `evolve --execute`. A new `manage.py createdb` command has been added to help with the installation side of this for development servers.
17cf7c645d4b2b6046760eca46b5e06493b91227
Formalize post-install/upgrade tasks and fix version-only upgrades.
We have a few tasks that must be completed during an install or upgrade. One is to register new SCMTools, and the other is to update the version stored in the siteconfig. With Django 1.6 times, we'd accomplish these by registering `post_syncdb` signal handlers that would execute the necessary database code, which made sense initially, but it meant that we had little control over the order of operations. It also wasn't future-proof. Given how installs/upgrades work now, we'd never get the equivalent modern signals if we didn't need to perform a database upgrade. We'd determine that no changes were made to the database, and simply skip the process that would ultimately emit the signal. Now, we have a dedicated function and signal for post-install/upgrade steps. This registers SCMTools, updates the version in the database, and emits a signal for any further tasks. This is called both by `rb-site` and `manage.py upgrade`. It will *not* be called with a simple `evolve --execute`. A new `manage.py createdb` command has been added to help with the installation side of this for development servers.
83c492f8e026853f4b5bd91a6047180948136316

Diff:

Revision 3 (+166 -166)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 failed.
JSHint passed.

flake8

chipx86
david
  1. 
      
  2. reviewboard/cmdline/rbsite.py (Diff revision 4)
     
     
    Show all issues

    Finalizing is super programmer-speak. Maybe "Finishing"?

  3. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-4.0.x (149c14c)
Loading...