[RFC] Add an "Update branch" button for the PR opener & JBS

[zero-24]

Problem statement

Right now we depend on the PR opener to update the branch manually via the CLI. Even the button that where on GitHub is now gone as we no longer require the branch to be up-to-date before merging. So updating the PR especially for a new drone run or new packages to be generated is not possible for the JBS, requires git CLI for PR opener and can only be archived by tricks for the maintainers.

Proposed solution

From the GitHub API there is a feature called Update a pull request

The required feature can be made available by merging a change like this in the joomla-framework/github-api repo: https://github.com/joomla-framework/github-api/pull/46/files (Yes I know I closed the PR there but I'm happy to re-do that PR against the framework)

And implementing an button in the issue tracker UI that only people with the edit and edit_own permission can trigger for that specific pull request.

Open Questions

• [ ] Is there example code to best build integrate such button in the issue tracker?
• [ ] Do you have other ideas to address the issue mention above?

[mbabker]

I'm hesitant to start adding git related actions to an application whose responsibility is to assist in triaging issues. People with appropriate permissions on the source repository can utilize that function if necessary.

Note, there is absolutely nothing in the git workflow that mandates that a pull request (which is a collaborative version of a patch file) cannot be behind the source branch for it to be cleanly applied. Realistically, the only time a pull request requires an update is if it has merge conflicts, and requiring a pull request owner (or any issue triage team) to constantly keep pull requests ahead of the source branch just causes additional CI time to be spent and is part of the reason why this application requires so many separate GitHub user accounts to remain functional (which, by the way, is a violation of GitHub's ToS).

[zero-24]

Thanks for your reply i'm happy to give some more context here.

I'm hesitant to start adding git related actions to an application whose responsibility is to assist in triaging issues.

Well isn't jissues build to support the Community and JBS and to manage the issue tracker?

People with appropriate permissions on the source repository can utilize that function if necessary.

Can you show me how? Maybe i'm just looking wrong. But i only see that 'update branch' button when the base branch require up-to-date branches and that policy has been reverted for the reasons you mention. With that option disabled i don't see a button in the GUI nor from the CLI to trigger that update even as owner. Maybe i have overlooked something?

Note, there is absolutely nothing in the git workflow that mandates that a pull request (which is a collaborative version of a patch file) cannot be behind the source branch for it to be cleanly applied. Realistically, the only time a pull request requires an update is if it has merge conflicts, and requiring a pull request owner (or any issue triage team) to constantly keep pull requests ahead of the source branch just causes additional CI time to be spent and is part of the reason why this application requires so many separate GitHub user accounts to remain functional (which, by the way, is a violation of GitHub's ToS).

Agree and there is no intention to always update the branch for all PRs as mention above.

Quick example. We merge an PR with an CS Issue. Now all new PRs fail on that CS issue. We notice that and patch the issue. But right now all PRs not starting from the latest branch are still failing and all PRs created in between are still failing too and we rely on the PR openers to run the update via the CLI.

Another example would be a PR that is a few months old. The generated upgrade packages are not up-to-date an can create issues on testing with that packages. We again rely on the PR opener to the update the PR via the CLI.

Same is true for PatchTester tests as we do not apply the diff but replace the entire file so an file outdated for x months could create side affects that can be easliy fixed by an branch update.

This here aims now to allow JBS people to update the branch and by that allow to trigger the CI again without relying on the PR opener to update the branch via the CLI.

[mbabker]

Well isn't jissues build to support the Community and JBS and to manage the issue tracker?

"Refreshing" patches isn't part of issue triage and management, the issue tracker frankly just does not support anything related to pull requests (reviews, suggestions, this update branch thing, etc.).

Quick example. We merge an PR with an CS Issue. Now all new PRs fail on that CS issue. We notice that and patch the issue. But right now all PRs not starting from the latest branch are still failing and all PRs created in between are still failing too and we rely on the PR openers to run the update via the CLI.

Only pull requests created from the bad commit should be failing, unless the CI strategy has changed and the CI systems are now doing a merge of the patch onto the base branch instead of running from the source branch. And if the patch merging strategy is what is happening, then re-triggering the relevant CI job should "fix" the issue. CI integrations at that level are outside the scope of this application right now.

Another example would be a PR that is a few months old. The generated upgrade packages are not up-to-date an can create issues on testing with that packages. We again rely on the PR opener to the update the PR via the CLI.

Same is true for PatchTester tests as we do not apply the diff but replace the entire file so an file outdated for x months could create side affects that can be easliy fixed by an branch update.

Then to be frank it really sounds like Joomla needs to go back to a patch based workflow and abandon GitHub pull requests as the workflow is not well suited for what the current Joomla contributor group is aiming to do. Trying to work from pull requests in the way GitHub is designed just does not work well for the integrations that the project has invested a lot of time into in order to mask the technical requirements of interacting with a version control system or tools such as Composer or NPM; those integrations would be best off being built from proper patch files (git formatted .diff or .patch files) instead of relying on a pull request owner to needlessly synchronize a non-conflicting remote branch.

[zero-24]

Ok thanks closing