tree 0a5f2ddd48bfb768663fca59ac4a723a5533eb6d
parent eb1fa6749681e78d6f8e8cb2a949ec81f6b5e290
author Daniele Sassoli <danielesassoli@gmail.com> 1709319104 +0000
committer Gerrit Code Review <noreply-gerritcodereview@google.com> 1709319104 +0000

Update git submodules

* Update plugins/delete-project from branch 'stable-3.9'
  to ecd8f3a0da68476e455ae00986b213681ecd1f95
  - Merge branch 'stable-3.8' into stable-3.9
    
    * stable-3.8:
      Add support for newer plugin-node-resolve versions
      ConfigurationTest: Remove flaky invalidTargetArchiveFolder test
      Send project-deleted event after project deletion
    
    Change-Id: Ib88d322b93bc306458c9cc6872312da11a06bfc2
    
  - Merge branch 'stable-3.7' into stable-3.8
    
    * stable-3.7:
      Add support for newer plugin-node-resolve versions
    
    Change-Id: Ie731df59db447bd619a2151b7ffbd371cff1bf31
    
  - Add support for newer plugin-node-resolve versions
    
    Due to [0] in plugin-node-resolve, it changes the way modules are
    resolved. It now looks at package.json and figures it out from
    there although if the stuff it is looking for is not found
    it falls back to how it did the resolving in older versions.
    Unfortunately there is no config to force the behaviour
    so we have to use the new behaviour.
    
    This is what it looks like:
    
    ```
      "exports": {
        ".": {
          "development": "./development/reactive-element.js",
          "default": "./reactive-element.js"
        },
        ....
        "./decorators.js": {
          "development": "./development/decorators.js",
          "default": "./decorators.js"
        },
        ....
      },
    ```
    
    Thus "./decorators" fails to match "./decorators.js" and so it fails
    to resolve.
    
    
    [0] https://github.com/rollup/plugins/commit/3d60158f21e0b6a5a8a53d9977928e2e148cb885
    
    Change-Id: I7829591e45662ee6028182beb57396b327823275
    
  - Merge branch 'stable-3.7' into stable-3.8
    
    * stable-3.7:
      ConfigurationTest: Remove flaky invalidTargetArchiveFolder test
      Send project-deleted event after project deletion
    
    Change-Id: I2ac01b00d7ce442b96a032d90b4037670e65d79a
    
  - ConfigurationTest: Remove flaky invalidTargetArchiveFolder test
    
    This test is failing when running gerrit test in docker image with root
    user. It's also failing when remote build execution is used (BuildBuddy
    provider).
    
    It seems to rely on the fact that the exception is thrown:
    
    java.nio.file.FileSystemException: /\\\: Operation not permitted
    
    However when the test is executed with BuildBuddy RBE that exception is
    not raised and as a consequence of that the test ends up failing. It
    looks that the folder /\\\ is created in the remote executor.
    
    While it could be fixed with:
    
    exec_properties = {
        "dockerUser": "nobody",
    },
    
    we prefer not to complicate our build toolchain and rather remove the
    test.
    
    Change-Id: I51bccdf2cb19559690d3d88bd92cf60bc28f5fcd
    
  - Send project-deleted event after project deletion
    
    Gerrit EventDispatcher has two types of listeners: user restricted or
    unrestricted. For the restricted listeners before sending the event
    Gerrit checks if user has permission to access the project. This means
    that `project-deleted` event will not be delivered to the restricted
    listeners because when we send the event project is already removed
    so we cannot check permissions anymore.
    
    Bug: Issue 15778
    Change-Id: I86386cf8b321a2dcc8a4a8ee6f36815e5c9228a2