Given that parallelization is likely to increase our usage of CI resources, and therefore increase our costs, it would be prudent to understand our current costs and to estimate how much parallelization will increase those costs.
For a very rough estimate, assuming review-qa-all runs once per pipeline, in 8000 pipelines per month, at a cost of $0.0950 per hour, with a job execution time of 7m 30s (not parallel) or 17m (parallel: 5 jobs), the cost per month would be:
not parallel: $95
parallel: $215
That extra cost would save us about 3m 30s in each pipeline (because the instead of waiting 7m 30s for the job to complete, we'd wait only the duration of the slowest parallel job, which is about 4m).
Note: this estimate only considers parallelizing the review-qa-all job, and assumes it will run in every MR. We should also consider the cost of parallelizing package-and-qa
In that MR 27 tests consistently took around 7m 30s total test execution time and around 17m total job execution time when one test failed, but about 25m when 4 tests failed.
It's difficult to predict the number of times the E2E test jobs would be run. Even if we assume once per pipeline and count all pipelines, the number of pipelines if fairly consistent on CE, but rose substantially on EE over the last 2 months:
But for the sake of comparing parallel vs. non-parallel execution, I'll assume the last 2 months were unusual, and so the average number of pipelines on CE and EE is about 8000 (but could be anywhere between 3600 and 17500)
For a very rough estimate, assuming review-qa-all runs once per pipeline, in 8000 pipelines per month, at a cost of $0.0950 per hour, with a job execution time of 7m 30s (not parallel) or 17m (parallel), the cost per month would be:
not parallel: $95
parallel: $215
That extra cost would save us about 3m 30s in each pipeline (because the instead of waiting 7m 30s for the job to complete, we'd wait only the duration of the slowest parallel job, which is about 4m).
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks. As part of this migration, issues will be moved to the
current gitlab-ee project.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?