Project Update Bot should create MRs instead of using patches

Moving to the Project Analysis queue where the bot lives now.

I believe this is on the roadmap of @bbrala for updating the bot for Drupal 11, see #3371547: [PLAN] Project update bot: road to Drupal 11 → . I linked this issue in there just now.

Just writing down how this could work. This assumed we add an SSH indentity to the issue bot, which is possible using secret variables in the repo.

Project update bot is started
When no issue present its easy imo:

1. Create issue (already implementen)
2. Click create issue fork
3. Clone the issue fork
4. Create a branch specifically named for the bot [issue]-project-update-bot
5. Apply the patch
6. Commit with message: "Automated Drupal 11 compatibility fixed - (run [RUN NUMBER)
7. Push with push options. Seems the folliwng options are relevent: merge_request.create, merge_request.title="", merge_request.description="", merge_request.label="").
8. This creates the branch and the merge request in one go.

When issue is present (with mr):

1. check results branch for tag the patch was last modified.
2. git log on the issue fork remote and search for a commit that ends with "- (run [RUN NUMBER TAG])" if it exists do nothing.
3. git log on the issue fork remove and search for a commit that has "- (run ", this means there was a patch already applied. If the only commit is from issue bot. Clone the issue fork, add origin remote create a new branch from orgin, apply the patch and force push.

If there is other commits from other users it gets harder, since it might mean that there will be conflicts. The bot could try and apply the patch, but it will probably fail. Not entirely sure what the best workflow here is. Perhaps create a new branch? Or move the existing branch and then open a new one?

I'm not sure about that part of the workflow yet. Anyone have some insights.

One idea people suggested (don't remember who, sorry) was to name the branch something evident, like "[...]-only-for-project-update-bot" or something, so that humans are discouraged to commit to it. Then the bot would retain most control. There is still the problem of the main project moving ahead and the fork needing a rebase, would that be possible to handle automatically? 😅

The flow could be

1. Try rebase
2. Rebase fails, make a new branch from origin, apply patch, force push.

See step 3 in the second set. The only moment this becomes a problem is if human start working in the same branch. Then things explode, or we need to create a new branch and clean mr, which could work.

We could jsut decide not to complicate things to much and keep it like that. If we are confused about the branch because someone committed there, AND the patch has changes, just make a new branch from origin, apply the patch and push to [branchname]-2 or something.

We could open a new branch yeah. I would suggest we ALSO try to make it clear this branch is not for humans though, that would avoid having a dozen or so MRs on an issue :D

True, might be less messy and complicated. Will end up deting some changes at some point though ;p

Did some initial work. While walking thorugh this i kinda concluded posting patches also is still valuable. Easier to use to add to own work, but also easy to reuse some of the checks if a new patch is available. This would mean writing less login in git.

A quick test with push options didnt work unformately. Although i didnt dive to deep. Lets hope those will work, otherwise we will need to use the gitlab api, which is also fine, but another extra moving part unfortunately.

Updates the IS with the solution i made.

The templates have also been updates to communicatie about the changes being sent as a MR also.

Most recent test isssue: 📌 Automated Drupal 11 compatibility fixes Needs work

I do need some more projects to test against.

I'd like to enable it for masquerade module, which steps required to apply for beta trial of bot?

Also please use to test following

• https://www.drupal.org/project/color →
• https://www.drupal.org/project/contact_storage →
• https://www.drupal.org/project/default_content →
• https://www.drupal.org/project/email_registration →
• https://www.drupal.org/project/empty_fields →
• https://www.drupal.org/project/forum →
• https://www.drupal.org/project/masquerade →
• https://www.drupal.org/project/migrate_generator →
• https://www.drupal.org/project/panels_everywhere →
• https://www.drupal.org/project/xhprof →

Test issue looks great, but it used your user?! I assume that is for testing for now and will use its own user. :)

ℹ️  Apply patch and commit to branch
error: patch failed: mailing_subscriber.info.yml:2
error: mailing_subscriber.info.yml: patch does not apply

If a patch does not apply it should not push. Seems because we use the dist version of the packages. Lovely.

bbrala → closed merge request !21

Git apply issue was fixed. :)

Yeah i run this locally for now, which means my own SSH key. I could import the key for the update bot. See how that goes. I'll use one mglaman's views_remote_data for that right now.

Lets see :P

@andypost: I'll add your modules to the "testset" we will use for the first little while after this gets merged. The list of modules can be set in the config, but will need to do that in de variables of the project.

First i'll be doing some last manual test.

I honestly feel this is working. I want to merge this and then setup the testset of projects to run against. But for that to work it needs merging into master-d11.

Test projects:

use_test_projects:
  - color
  - mailing_subscriber
  - jsonapi_extras
  - mailing_subscriber_mailchimp
  - twig_renderable
  - admin_toolbar_entity_version
  - admin_toolbar_tasks
  - paragraphs_edit
  - color
  - contact_storage
  - default_content
  - email_registration
  - empty_fields
  - forum
  - masquerade
  - migrate_generator
  - panels_everywhere
  - xhprof
  - commerce_cart_flyout
  - commerce_cart_api
  - views_remote_data
  - deprecation_status
  - upgrade_status

Will find some time to slowly add those after merge validate last few things.

note to self: API cache of Drupal.org is aggressive, this is the source of dumplicate issues.

As the pipeline is green and i cannot work on this in an issue fork regarding the SSH key and such, gonna merge towards master-d11 and start testing there.

You might see some issue spam if your projects soon, sorry ;)

bbrala → credited mglaman → .

https://git.drupalcode.org/project/project_analysis/-/jobs/968120

Think this is working as intended :P Yay!

Looks great on my end! Awesome!

Automatically closed - issue fixed for 2 weeks with no activity.