Disable DrupalCI testing

I think the way we made Drupal 9-only releases unsupported, we can remove testing environments that are not yet supported by current supported Drupal versions. Do you think that would need additional announcement and/or a waiting period before doing it? (I can help draft it but I am not sure it is needed since its likely mostly dormant projects/branches with probably not very attentive maintainers to update testing setups).

There are currently 2,817 projects with 5,285 testing schedules set up. This has been steadily dropping already.

Those are the numbers for DrupalCI, right? How do these numbers compare to the ones for GitLab CI?

Let’s go ahead and say July 1st for Disable DrupalCI testing.

For no new testing schedules, DrupalCon Portland is May 6-9. We might as well pick a date around then.

We should send emails to people with DrupalCI testing set up. Maybe 2 weeks before each date, so we’re sending at most 2 emails.

I agree with this plan.

For no new testing schedules, DrupalCon Portland is May 6-9. We might as well pick a date around then.

I would say disable around a week before - that will again encourage folks to keep moving over to GitLabCI at contribution day.

Regarding task "Discourage patch file uploads" this is likely to cause many more MR issues branches to be created. Contributors who are not familiar with the workflows are also likely to create more than one, unnecessarily. Is there any plan to give module maintainers the permission/ability to delete unmerged branches once an issue is closed? Then we can contribute to tidying up the wasted space used. Or is there no problem with 1000s of repositories and unmerged MR just being left there? I know there has been discussion about not allowing anything to be deleted. This is not an urgent problem, no need for a prompt reply, just asking what the current feeling is.

> ... delete unmerged branches once an issue is closed?

"Issue is closed" isn't a guarantee that users aren't using the branch.

That also relates to my question:

Can someone confirm that either (a) a patch file upload workflow will continue to be available under the new system; or (b) the new system provides equivalent functionality: persistent URLs for specific revisions of a patch (regardless of the current state of the MR/branch, and immune to git garbage collection).

It sounds like it's only the testing of patch files which will be disabled, so presumably we do still get option (a) sans testing; but that being the case, option (b) would be nicer -- otherwise users still have to deal with patch files, but now they have to deal with MRs as well, and there's no obvious connection between the patch URL and the testing that was performed for it.

Last I knew, the nearest merge request option was a patch URL for "whatever the MR head happens to be at the moment" and users were being told to download local patch files as a workaround (which I've been presuming is a temporary workaround because it's a bit rubbish by comparison). https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... doesn't indicate any improvements in this area.

Based on all the info available, I added this planned schedule to the issue summary. Please correct if I misunderstood.

Planned schedule

• Done: Projects without DrupalCI testing cannot add this testing anymore. Projects with DrupalCi testing cannot add new DrupalCI testing configurations anymore.
• Late April 2024: A week or so before DrupalCon, no existing DrupalCI schedules will be able to be updated.
• July 1, 2024: Running of DrupalCI tests will be shut down. No more tests run after this.
• Jan 1, 2025: End of DrupalCI test result data retention.

@jweowu - users will still be able to attach accepted file types to issues (even when they move to GitLab) so that may include patch files. They won't have any automated features or testing associated, but they will be attachable.

However we have *never* recommended hot-linking to patch files on a remote server. That is a really bad/dangerous development practice. We know people have been doing it for years, but it has always been against Drupal.org recommendations.

It has always been much safer and more reliable to host copies of patches you are using locally.

There is a feature request (actually multiple feature requests) open requesting GitLab add stable urls for diffs:

• https://gitlab.com/gitlab-org/gitlab/-/issues/15593
• https://gitlab.com/gitlab-org/gitlab/-/issues/217206
• https://gitlab.com/gitlab-org/gitlab/-/issues/16178
• https://gitlab.com/gitlab-org/gitlab/-/issues/27447

We absolutely agree this is a feature GitLab needs to add. However it won't block the migration, and we still won't recommend hot linking to them in any deployment process.

The pairing of a stable patch URL and a checksum of its expected contents is also safe, and significantly more convenient -- developers can safely share reviewed pairings without having to pass around the actual patch files.

For composer users, version 2 of cweagans/composer-patches supports this out of the box, aborting noisily if it fetches a patch which does not match the checksum specified in the patches.json file.

Expanded the timeline's done section with "Direct access to log output and artifacts on DrupalCI is no longer available. Results are still summarized on the Automated Testing tab of project pages."

Amending attribution.