Change d9-basic to run with D10 as current and D9 as previous major

This is ready for feedback. The current approach means we should not opt in to previous minor, as that would be D11. But we could leave opt_in for next minor, as that would still test D11. Or maybe we have plenty of D11 coverage in the d10-plus branch, and we should make this d9-basic branch replicate a project which is only D9 and D10 compatible. That would mean we'd have only ^9 || ^10 in composer.json, and it would remove the need to edit that file with a 'upgrade-status-fail'.

It all depends on how we want to use these test branches. I assume there are still many contrib projects that are not yet compatible with D11, so having one like that here could make sense.

I think that given that we are calling it d9-basic we can just target the 9 to 10 scenario, and not 11, as we have the other branches for those, so yeah, we can simplify a bit the OPT_IN, composer.json and the upgrade status action.

Good. I have removed D11 compatibility from composer.json, deleted the upgrade-status-fail before_script, and also set the Upgrade Status job to be manual. This way, we run it when needed, but the normal pipeline ends green. If we always ran the job, even when not testing anything in it, the pipeline would always end amber, and just means we have to take a deeper look to check why. I think it's good if the GTD jobs normally end green.

So this is ready for review.

The changes to the d9-basic branch look good. RTBC.

Thanks. Merged.

I think having the 'upgrade status' job default to being manual would be a good thing to do in the real gitlab templates. There was a slack conversation about the origin of that job being from the update bot, and it was never intended to be run continually in pipelines. If we change the default to 'manual' I can add a couple of lines in a doc to show how to override it and make it automatic if the developer really wants that.

What do you think? I will start the issue if you think it's a good idea.

Given that this is a job that is disabled by default, I think it can stay as it is (aka automatic). There is a good number of modules using this already (https://git.drupalcode.org/search?group_id=2&repository_ref=main&scope=b...) and it'll change the behaviour of the pipelines if we do this.

Perhaps we can document how to do it a manual one in this page instead https://project.pages.drupalcode.org/gitlab_templates/jobs/upgrade-status/

OK, fair enough. I suppose those pipeline users would be annoyed if they had to manually trigger it. But it would have been good to have it as manual right from the start.

Yes I will add that onto the documentation list.

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