Skip to content
Snippets Groups Projects

Issue #3230235: Validate that an update is supported before an update begins and after staged

Merged Issue #3230235: Validate that an update is supported before an update begins and after staged

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Ted Bowman
  • Ted Bowman
  • Ted Bowman
  • Adam G-H resolved all threads

    resolved all threads

  • Adam G-H resolved all threads

    resolved all threads

  • Adam G-H resolved all threads

    resolved all threads

  • Adam G-H resolved all threads

    resolved all threads

  • Adam G-H resolved all threads

    resolved all threads

  • Adam G-H added 2 commits

    added 2 commits

    • 48eb6f73 - Merge branch '8.x-2.x' into 3230235-supported-begin
    • 99c672a6 - Merge branch '3230235-supported-begin' of...

    Compare with previous version

  • 10
    11 /**
    12 * Validates that core updates are within a supported version range.
    13 */
    14 class UpdateVersionSubscriber implements EventSubscriberInterface {
    15
    16 use StringTranslationTrait;
    17
    18 /**
    19 * Returns the running core version.
    20 *
    21 * @return string
    22 * The running core version.
    23 */
    24 protected function getCoreVersion(): string {
    25 return \Drupal::VERSION;
    • Comment on lines +24 to +25
      Author Maintainer

      I see that adding this instead of directly accessing Drupal::VERSION allows us to test different versions for core. But I think we should stick with the same way the current update module is using to determine the core version, as well as all other projects, and to fake this for testing. We use this method in \Drupal\Tests\automatic_updates\Functional\UpdaterFormTest::setCoreVersion() and we get the current version of core via $project['existing_version'] in \Drupal\automatic_updates\Form\UpdaterForm::buildForm()

      That way we have 1 source of truth for the installed version of Drupal and 1 way of faking it for testing.

    • Author Maintainer

      The one problem with this is that update_get_available() is needs to be called with $refresh = TRUE to make sure we have the latest data. But we don't want every subscribed to have to have refresh the data.

      I am thinking that the updater should be responsible to for calling update_get_available(TRUE). We could call it in \Drupal\automatic_updates\Updater::begin() but it could take a while we might want to do this in something like Updater::prepare() that we could add a separate batch step in \Drupal\automatic_updates\Form\UpdaterForm::submitForm().

      But I think for this issue we should actually just call update_get_available(TRUE) with a @todo to figure this out.

    • changed this line in version 7 of the diff

    • Please register or sign in to reply
  • Ted Bowman
  • Ted Bowman mentioned in merge request !28

    mentioned in merge request !28

  • Adam G-H added 1 commit

    added 1 commit

    • 744699e9 - Use update_test to set running core version

    Compare with previous version

  • Adam G-H added 2 commits

    added 2 commits

    • 4fd5ec3e - 1 commit from branch project:8.x-2.x
    • 5fa7322c - Merge branch '8.x-2.x' into 3230235-supported-begin

    Compare with previous version

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading