Add fault tolerance to build processing machinery
#1 in the chain
- Add fault tolerance to build processing machinery (!5003 - closed) • Georgi N. Georgiev | GitLab • 18.5 (You are here)
- Add file store to fault tolerance (!5004 - closed) • Georgi N. Georgiev | GitLab • 18.5
- Make Kubernetes executor fault tolerant (!5005 - closed) • Georgi N. Georgiev | GitLab • 18.5
What does this MR do?
Adds the base-most functionality required to support fault tolerance in GitLab Runner.
By itself this MR provides no new functionality. The fault tolerance interfaces are implemented by no executors. The store configs support no particular stores other than noop.
This MR is a part of the effort of adding the fault tolerance functionality in as small chunks as possible. It appears huge but in fact most of the changes are to migrate the tests to use the NewBuild constructor rather than construct the Build object manually ad-hoc, or work around the new Trace mechanics.
The existing tests should continue working the same verifying that there are no breaking changes.
Why was this MR needed?
First step of Add fault tolerance to the Runner K8s executor ... (#36951) • Georgi N. Georgiev | GitLab • Backlog
Broken out of Draft: Ggeorgiev/fault tolerance (!4906 - closed) • Georgi N. Georgiev | GitLab
What's the best way to test this MR?
Old tests should be as close to what they were prior to changes as possible - to verify that old functionality would continue working the same way it did up until now, despite the changes in the base of Build processing machinery.
Similarly manual tests should result in no visible changes as far as this MR is concerned.
For the full picture in one place - look at Draft: Ggeorgiev/fault tolerance (!4906 - closed) • Georgi N. Georgiev | GitLab
What are the relevant issue numbers?
Related to #36951