A method of finding software bugs and defects as early as possible in the development cycle.
Something that can be bypassed because it takes too much time or effort.
Average test time: 1h30
Wait time: 0 to 4h
No distro matrix
Solved by executing tests on a pre-built binary image, either by maintaining custom scripts, either OOTB with drone.io and gitlab-ci
Solved by maintaining a CI infra with parallel build slots
Must grow continuously
Perhaps, if it meets all requirements of all projects:
28K/year
3.6k/year
+ no maintenance
- shared CPU: how secure ?
- shared RAM: how much ?
- shared bandwidth: how much ?
- developers waiting: how long ?
- closed source
- paid option for container cache
- cache over network: slow
- highly expensive
+ maintained by a hacker*
* that you already have when you need 48 executors of CI !
+ dedicated CPU
+ dedicated RAM: 256G
+ dedicated bandwidth: 1Gbps
+ CI *jumps* on patches
+ container cache on host
+ triple 1TB NVME SSD: fast !
+ super cheap
+ best ROI
+ Open Source
nomatch :)
In GitLab, User can also click to enable merge when CI and approvals validate the PR
No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch has been rebased.
When the branch has not been rebased, the user is given the option to do so.
Of course, for CI pre-provisioning !
Also: deployment pipelines
Developer
Public Repository
Push commit
Request test execution on runner
Fork, register runner for fork
Publish runner logs and result
Optionnal step, allowing me to run my own dedicated CI on my laptop, otherwise I can push in a branch of the main repo like on GitHub
In my fork, settings:
(Developer machine)
On GitHub UI, only the last build is shown for 1 commit
Prepare for OMFG
Approving as James Pic
Scheduled for GitLab 8.10 (current: 8.8)
gitlab-workhorse is a proxy for HTTP and git pull/push
GitHub | GitLab |
---|---|
$108/user/year ($9 / month) + Jenkins maintenance + Container registry maintainance |
$39/user/year - includes CI - includes container registry |
Dmitriy was unsatisfied with the options for git repository management. So together with Valery, he started to build GitLab as a solution for this.
Sid saw GitLab for the first time. He thought it was natural that a collaboration tool for programmers was open source. Being a Ruby programmer he checked out the source code and was impressed with the code quality of GitLab. He started GitLab.com as the first SaaS offering for GitLab.
In November 2012, Dmitriy also made the first version of GitLab CI.
In 2013, Dmitriy tweeted that he wanted to work on GitLab full time. Sid and Dmitriy teamed up and started bootstrapping GitLab as a company.
In the same year in August, we introduced GitLab Enterprise Edition.
In 2014 GitLab was officially incorporated as a limited liability corporation. GitLab released a new version every month on the 22nd, just as every year before and after. The first release of the year at January 22nd: GitLab 6.5. At the end of 2014, December 2014, GitLab 7.6 was released.
In the very start of 2015, almost the entire GitLab team flew over to Silicon Valley to participate in Y Combinator.
At this point, over 1000 people worldwide have contributed to GitLab and more than 100,000 organizations are using GitLab.
Our Tanuki logo symbolizes this with a smart animal that works in a group to achieve a common goal.
At GitLab we have one vision. Everyone can contribute to all digital content.
To ensure that everyone can contribute to our organization we have open business processes that allow all team members to suggest improvements to our handbook.
Conclusion by Richard Stallman
Y'a moins bien
mais c'est plus cher