Move GraphQL development to drupal.org to leverage issue credits

[klausi]

A couple of years ago development for this module started on Github because there were no pull requests on drupal.org. That has changed, we have merge requests on drupal.org now and a flexible Gitlab CI runner system.

More importantly we cannot assign issue credits on Github. Contributors and companies do not receive visibility through the credit system on drupal.org right now.

We could move development back to drupal.org, let's discuss pros and cons here.

Pros:

1. We can give contributors proper drupal.org credits
2. We integrate better with the rest of the Drupal ecosystem (moving issues for example between Drupal projects)
3. Simpler release process, only on drupal.org

Cons:

1. We need to port our Github Action CI process to Gitlab
2. Gitlab UI is less usable than Github
3. We lose exposure to the wider Github developer community (I don't think this matters much, most contributors have drupal.org accounts)
4. We need some workflow to generate the documentation pages (maybe keep doing that on Github here?)
5. Gitlab does not allow routing of notification emails to different email addresses per project

I will try to port the test execution to Gitlab in a drupal.org sandbox, let's see how hard that is.

[pmelab]

I agree. Another Pro: Simpler releases.

There is only the topic of documentation. Gitbook has Gitlab support, but probably not with drupal.org Gitlab. Maybe we could feed it into something like Astro and build it on netlify?

[klausi]

So the first conversion attempt to Gitlab CI looks promising: https://git.drupalcode.org/project/graphql/-/merge_requests/1 https://git.drupalcode.org/project/graphql/-/pipelines/217333

Unfortunately I could not get Gitlab CI working in a sandbox, so used the graphql project repo directly for now.

TODO: figure out how to run PHPStan only on the current point release and max php version

[klausi]

Good news, the Gitlab CI pipeline is now working https://git.drupalcode.org/project/graphql/-/merge_requests/1

I created a custom PHPStan job to only run it on the max PHP version. We have now a very good mirror of what we are testing here in Github actions. We are not testing on PHP 8.2 there, but I think that is ok (only 8.1 and 8.3).

Documentation: For the time being we can mirror the git repository here on Github with a daily github cron action to generate the Gitbook. I don't think it is worth it to explore other systems since we have so little changes to the docs now.

Not sure what we should do with existing issues and pull requests here on Github. I think we can just leave them open during a transition period of a year, so that people can still find them. For any new issues and pull requests we should close them and direct people to drupal.org.

Otherwise I think we are ready to make the switch! @Kingdutch and @Luigisa would be good to get your signoff as well, or any concerns you have!

[Kingdutch]

While I understand the desire to move now that Drupal's development has mostly caught up using GitLab, it will still make any maintenance contributions from my side significantly harder.

GitHub allows me to manage notifications per project and route them to different e-mails. This makes sure I can deliver them in the context where I'm most likely to have time to look at what's going on. Drupal.org unfortunately has no such feature and just dumps everything on a single pile, which means I generally don't see those notifications (they have to come in through work e-mail or Slack).

More importantly we cannot assign issue credits on Github. Contributors and companies do not receive visibility through the credit system on drupal.org right now.

Is this something we can do without making the move? For example, Drupal's credit system has also changed quite a bit in the past years. Is the issue credit something we can add to commits that get pushed to Drupal.org?

Gitlab UI is less usable than Github

There's also this one, which I don't necessarily see as a blocker, but it's definitely a different level of productivity.

We lose exposure to the wider Github developer community (I don't think this matters much, most contributors have drupal.org accounts)

it's slightly unfortunate since most other GraphQL development happens on GitHub. I hope that one day Drupal will pull people into PHP from other languages, GraphQL may be a nice entry point. But that's not likely to matter much any time soon.

We need some workflow to generate the documentation pages (maybe keep doing that on Github here?)

I think ideally if we move to GitLab we move entirely and also include this in GitLab CI (but that may mean maintaining our own CI config instead of leaning on the Drupal CI template). Doing it half-half feels like a step backwards.

Having said that, you've been maintaining the automations so far, so if it's something that you can live with then I suppose it's something I can live with too :)

[klausi]

Credit system: in order to get credits on drupal.org you need to make issues. So we could somehow make d.o issues for each Github pull request and issue and then assign credits. But I think that is not worth the effort, as you always have to map the people correctly to their d.o accounts.

Documentation: yeah, I can live with a mirror here in Github, so that the Gitbook keeps working and being updated. It looks like Gitbook can also source from Gitlab. I don't have access to drupal-graphql on Gitbook right now, need to check with @pmelab how that works. But not important now.

Email notifications: yeah that is a bit of a pity and I hope you can work around that. I want to keep working with you on graphql for sure :)

In general I think that the issue credits are more important than the disadvantages we have listed here. I propose that we still go ahead with the move if there are no more severe objections.

[Kingdutch]

If the main driver to move is to get Drupal.org issues for credits then I'd propose we postpone the move.

The GitLab acceleration Intiative is gaining steam. They should have had a go/no-go meeting for the GitLab SSO earlier this week. Additionally Drupal's CI is now fully on GitLab. I also believe GitLab's blockers for migrating to GitLab issues have been mostly resolved. So that suggests that we're getting close to moving from Drupal.org issues to GitLab issues (unfortunately I couldn't find a strict date based planning).

If we wait for that and move directly to GitLab with issues then we skip having to go through 2 adjustments. Or is there a reason that this is suddenly urgent after X years on GitHub? :)

[klausi]

Not urgent no - we just lose credits for changes we make in the meantime.

I would not count on moving to Gitlab issues soon - the scope is large and complicated, this could take years.

Yes, moving the platform for our issues 2 times is bad, but IMO continuing losing contribution credit is worse.

I will be on vacation for the next 2 weeks anyway - let's check this again end of July!

[klausi]

So we lost another great commit credit for the Drupal 11 compatibility issue at #1407 - @apathak18 put a lot of work into resolving all the issues.

I think we cannot wait any longer, will ask the drupal.org Gitlab team if the date is near when they plan to move issues.

[klausi]

The drupal.org Gitlab team said that moving to Gitlab issues is still months away and they will have an automated migration of old drupal.org issues into new Gitlab issues.

So we don't lose anything if we start moving now to drupal.org. I would expect they will also make redirects for issue numbers in git commits, that should also not be a problem.

Given that I propose that we move to drupal.org soon, I will start the process earliest next week if there are no more objections. Thanks for your thoughts!

[klausi]

In progress, let's continue at https://www.drupal.org/project/graphql/issues/3467196