v43: postUpgradeTasks consisting of three commands, different behavior between shell chaining and three single commands in postUpgradeTasks

[lovetheguitar]

How are you running Renovate?

Self-hosted Renovate

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

43.0.9

Please tell us more about your question or problem

We have a custom preset to update git submodules to specific tags only. Part of it looked like this:

    // When all the data is gathered and a newer version is found, the submodule is updated using the commands below.
    // All submodules need to be reset on every run using `git submodule update --init --depth 1` to ensure renovate does not leak update state.
    // renovate-config automatic tag updates also uses git-tags as datasource. As we don't want the following commands to be executed, we check
    "packageRules": [
    {
      "matchFileNames": [
        ".gitmodules"
      ],
      "matchDatasources": [
        "git-tags"
      ],
      "postUpgradeTasks": {
        "commands": [
          "git submodule update --init --depth 1; git -C {{{depName}}} fetch origin tag {{{newVersion}}} --no-tags && git -C {{{depName}}} checkout {{{newVersion}}};"
        ]
      }
    }
  ]

With the update to v43 we understand that shell=false is set per default so we tried to change this to three individual commands:

"postUpgradeTasks": {
        "commands": [
          "git submodule update --init --depth 1",
          "git -C {{{depName}}} fetch origin tag {{{newVersion}}} --no-tags",
          "git -C {{{depName}}} checkout {{{newVersion}}}",
        ]
      }

Previously we had two changed files per submodule dependency in a merge request (e.g. moduleA -> two changes in one MR, moduleB -> two changes in another MR, etc.).

With the new preset adapted to shell=false, we get all updated submodule files in each merge request of every dependency (in both MRs, e.g. of moduleA there are expected changes plus undesired changes of the other modules from separate updates).

See screenshots for described good and bad behaviour.

Any help is greatly appreciated, thank you. 🙂

Bad case

Good case

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[RahulGautamSingh]

Try this:

"git submodule update --init --depth 1 {{depName}}} for the first command.

[lovetheguitar]

@RahulGautamSingh Thanks for the suggestion. Sadly the behavior stays the same. :/

Any other ideas?

[RahulGautamSingh]

That's weird.

Maybe it has something to do with the the part of the logic that persists the file changes after git submodules update it executed.

Will need to debug locally for that. But, I am not well versed with this logic so might take some time.

Do you think it will be possible for you to create a minimal reproduction?

[Jarne-omi]

Hi @RahulGautamSingh, thanks for the help!

We created a minimal reproduction. We hope that this works 😃

https://github.com/Jarne-omi/reproduction-40858