GeezerVison

Review requested:

• @nodejs/actions

Im not sure about updating the gyp file, its too complex to automate it we should probably do it manually

Im not sure about updating the gyp file, its too complex to automate it we should probably do it manually

I tend to agree with that in general. However, in this case, if the script does make a mistake in producing the gyp file, we still have our regular review process as well as Github Actions and Jenkins CI as safeguards, and we can still fix the gyp file manually if necessary. A mistake that is not caught by any of these safeguards could just as well be the result of manual work.

In other words, we can take the generated gyp file as a suggestion, which hopefully will be correct in most cases, thus usually removing the need to update it manually. When we or our automated tests notice a problem with the suggested change, we can still resort to updating it manually.

I'll try and see what happens with previous versions of googletest (i.e., if the script would have made mistakes in the past). That being said, I'd be happy to switch to a more reliable approach if we can come up with one.

Appeased lint-sh. PTAL @marco-ippolito.

Rebased again and updated for #47591.

@marco-ippolito Is my understanding correct that the GitHub action will keep updating the same PR instead of opening new ones if a new update is found before the PR is merged? That would be great to reduce noise in this case, if we could just keep the PR open regardless of how often the action runs.

if there is a pr for 1.0.1 and the version1.0.2 is released, another pr will be created. if the latest is the 1.0.1 pr it will not create another one for every run. I dont think it doesnt happen very often but it would be great to update or close the PR for the previous version.

if there is a pr for 1.0.1 and the version1.0.2 is released, another pr will be created. if the latest is the 1.0.1 pr it will not create another one for every run. I dont think it doesnt happen very often but it would be great to update or close the PR for the previous version.

According to https://github.com/gr2m/create-or-update-pull-request-action#how-it-works it should update the existing PR (more specifically, it pushes to the same branch as the previously opened PR for the dependency). I've seen this happen on some of the Undici PRs (e.g. #46502).

According to https://github.com/gr2m/create-or-update-pull-request-action#how-it-works it should update the existing PR (more specifically, it pushes to the same branch as the previously opened PR for the dependency). I've seen this happen on some of the Undici PRs (e.g. #46502).

Oh that's great then we are good on this

I like that not creating additional PRs reduces notification noise, but it unfortunately seems to unnecessarily keep old commits and also doesn't update the PR title or description.

I like that not creating additional PRs reduces notification noise, but it unfortunately seems to unnecessarily keep old commits and also doesn't update the PR title or description.

Updating the title/body can be controlled by the update-pull-request-title-and-body action parameter.

Thanks, I saw that in the docs right after I left the previous comment and opened #47621.

Regardless, this PR needs to be re-approved after the last force-push :)

Landed in 4956271