• 
      

    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

    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:
    Completed
    Change Summary:
    Pushed to release-4.0.x (149c14c)