-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split up testing pipelines #22010
Labels
outdated/backport/v1.18
This PR should be backported to Gitea 1.18
topic/build
PR changes how Gitea is built, i.e. regarding Docker or the Makefile
type/feature
Completely new functionality. Can only be merged if feature freeze is not active.
type/proposal
The new feature has not been accepted yet but needs to be discussed first.
Comments
Merged
techknowlogick
added a commit
that referenced
this issue
Mar 10, 2023
- This PR attempts to split our various DB tests into separate pipelines. - It splits up some of the extra feature-related tests rather than having most of them in the MySQL test. - It disables the race detector for some of the pipelines as well, as it can cause slower runs and is mostly redundant when the pipelines just swap DBs. - It builds without SQLite support for any of the non-SQLite pipelines. - It moves the e2e test to using SQLite rather than PG (partially because I moved the minio tests to PG and that mucked up the test config, and partially because it avoids another running service) - It splits up the `go mod download` task in the Makefile from the tool installation, as the tools are only needed in the compliance pipeline. (Arguably even some of the tools aren't needed there, but that could be a follow-up PR) - SQLite is now the only arm64 pipeline, moving PG back to amd64 which can leverage autoscaler Should resolve #22010 - one thing that wasn't changed here but is mentioned in that issue, unit tests are needed in the same pipeline as an integration test in order to form a complete coverage report (at least as far as I could tell), so for now it remains in a pipeline with a DB integration test. Please let me know if I've inadvertently changed something that was how it was on purpose. --- I will say sometimes it's hard to pin down the average time, as a pipeline could be waiting for a runner for X minutes and that brings the total up by X minutes as well, but overall this does seem to be faster on average. --------- Signed-off-by: jolheiser <[email protected]> Co-authored-by: techknowlogick <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
outdated/backport/v1.18
This PR should be backported to Gitea 1.18
topic/build
PR changes how Gitea is built, i.e. regarding Docker or the Makefile
type/feature
Completely new functionality. Can only be merged if feature freeze is not active.
type/proposal
The new feature has not been accepted yet but needs to be discussed first.
Feature Description
The current state of the testing pipelines that run the various tests are they are arbitrarily divided into two. This could be optimized in a way that'll speed up the running of the pipelines. An way that this could be done is to split up unit tests into their own pipeline, and to split up the runs that use DBs into their own pipelines. ES and MSSQL both use significant resources when run, and having them both run together in same pipeline means that they slow the whole pipeline down, but having them in different pipelines means that the overall speed could be faster.
By running this all on the same arch, amd64 (or possibly all on aarch64), we could utilize the autoscaler to provision CI servers on demand to keep idle usage to a minimum, rather than having multiple autoscaler processes running and attempting to maintain multiple arches (especially since the arm provider we use doesn't have an autoscaler provider available)
Screenshots
No response
The text was updated successfully, but these errors were encountered: