Enable GitLab CI, and use it to build out a core code base with Automatic Updates and Package Manager as core modules

I talked with @phenaproxima about this and I was wondering whether we could try to get tests only running on gitlabci and ask for a core exception to allow skipping our tests run in core drupalci. I thought this would be ok because our test would still run on gitlab ci.

but then I talked to @effulgentsia and he pointed out that some issue are done only via patch in core. In that case gitlab-ci would not run. So we might introduce regressions without knowing it until the gitlab pipelines ran on the branch after commit.

so that is probably not possible until core stops using the patch development workflow together. But effulgentsia thought we should check to see if there is timeframe. We might not have to wait for any infrastructure changes for that since there is limited number of Drupal 10 core committers and they could just agree to all stop using patches or always run a merge request before committing issues.

You could even imagine a core committer script
create-mr-from-patch [PATCH-URL] [ISSUE_NUM]

This situation is especially bad for this module

1. We are trying to maintain a workflow where our core MR's made from conversion script
2. By the nature of our build test they need the Composer templates that are in a core clone
3. Test in contrib gitlab-ci does not use a core clone, drupalci does

I am working on #3391715: Change core merge request converter to either produce the Package Manager only MR or with AutoUpdates and running into problems I think this issue could help with.

1. Many times a lot of the problem of doing the core merge request conversion is actually that our test fail against 11.x.
2. Right now I don't think we can test against 11.x in drupalci
3. I don't think 2) is going to be fixed because Drupalci is going away

This effectively keeping the merge request anywhere up-to-date very hard because we can only test 11.x in core merge request

Right now it looks like the problems with gitlab tests in the current MR that @phenaproxima is working on are

1. The build tests fail
2. GitExcluderTest fails
3. PHPCS fails

Here is what I propose we do.

1. If possible in our .gitlab-ci.yml exclude the build tests from running. We are still running them in drupalci for now so we won't introduce any regresssions
2. Try to get GitExcluderTest passing on gitlabci if it is not hard. If it is hard introduce a temporary skipOnGitlabCI() function. and open up a follow-up to remove this for GitExcluderTest. Again this will still run on drupalci
3. Exclude the PHPCS on gitlabci but open up a follow to get this passing
4. If possible have our gitlab CI run on against 10.1.x and 11.x. If not just run again 11.x

This obviously is not where we would like to be but will make sure we don't introduce any incompatibilities with 11.x

Also the core merge request the build tests will run in core clone which is what they are currently written assuming. So we could still work on the core merge request changes to core's own gitlabci.yml to get the core MR build tests passing even if they aren't passing yet in contrib module.

Basically lets get what we can passing now on gitlabci and commit that while continue to also run drupalci. Then lets try to get everything running on gitlabci

About to propose a new plan

unexpected test failures in the new more limited MR.
retesting existing MR to see if it has this new fails too

This doesn't to be postponed see #5

I talked with @Wim Leers and @phenaproxima I have updated the summary plan. Basically we just use gitlab to test the version of the module that is converted for the core merge request in #3253158: Add Alpha level Experimental Update Manager module

for we will use drupalci to test the contrib version

Looks like it creates the codebase correct!