But we had been on Github, and that turned into something of a pain.
First we tried mirroring Github to Gitlab. This worked, but (a) it added a minute or two of latency to starting jobs in the CI, (b) since it went through one account, all the build emails went to a single person, and (c) the mirroring happened on our own infrastructure, which turned out not to be so reliable. So we got tired of this approach.
Eventually we decided to move development to Gitlab, but we didn't want to move our users, so we left all the user-facing elements on Github (issues, PRs, etc.). This also kind of works but has its own set of issues.
Things might have been different if we'd started on Gitlab from the very beginning, but as things are, I think having the repository on Github and the CI on Gitlab would be the best of both worlds for us.
An update, having now tried this on a toy Gitlab/Github instance.
It looks like this still relies on Gitlab's support for mirroring an external repo, which relies on polling. This is less than awesome, because it means we're back into the (many) minutes latency range from pushing changes to seeing them appear in the mirrored repo (and therefore CI). When I did this before, we had to set up a mirror on our own machines to get this latency down into the ~1 minute range, otherwise it was unusable.
What appears to have been added was syncing the build status from CI builds back to Github. That part seems to work as intended.
There does appear to be a Gitlab API for triggering a mirror update, but I don't see an easy way to get that hooked up to Github out of the box. The CI status feature would be much more aweseome with the addition of push-based mirroring.
Edit: And the problem with mirroring manually like we did before is that there isn't a clean way to mirror pull requests (it requires manipulating web APIs, not just pushing a Git repo). So if we went back to that route, we wouldn't really get the seamless experience we've been hoping for.
Is this not working for you? (may be a bug)
Did you set up the toy instance by creating a CI/CD project and use the GitHub Oauth?
I've logged an issue to track down the process: https://gitlab.com/gitlab-org/gitlab-ce/issues/44552
I deleted my toy repo and did it over again; it seems to be working now. Latency seems to be in the 20-30 second range for incremental pushes, which is pretty good.
Is there a way to do this for existing repos? Or do we have to delete and re-create our production repo to do this?
You can add a webhook on GitHub and have it point to our Pull Mirroring API , followed by manually setting up the integration to send status updates back .
We're looking to make this process easier, and have explored ways we might implement this in https://gitlab.com/gitlab-org/gitlab-ee/issues/5220.
I'm curious to know how the two compare because I haven't tried Gitlab before.
I want to use my own machines to build certain jobs (perhaps because those jobs require heavy computation), but I want to use the free, shared, cloud-based runners for the rest (to increase overall throughput). And I want to do this while keeping the master CI instance (the node which keeps track of which jobs are running and serves the webpage which shows the job status) on hosted infrastructure so that I don't have to manage it myself.
Nearly everything that exists today, except Gitlab, forces you to choose between shared runners in the cloud and doing it completely yourself (including hosting the master CI instance). Gitlab allows you to connect both shared and private runners to a hosted CI instance, so we get the benefit of private machines, the throughput of shared machines, and ease-of-use of not having to host the CI ourselves.
Edit: And note, to use private runners with basically any of the commercial CI's, you have to pay big money for a enterprise instance (even if you're open source). Whereas the ability to connect private runners to Gitlab comes for free (I think on all accounts? but definitely open source ones).
I think the latest features we launched at Shippable meets all of your requirements. You can mix and match on-demand and dedicated nodes, allocate them to specific projects if you'd like, all of this is available in our SaaS edition, and pricing is (in my opinion) quite reasonable.
Could you explain more about how you've got public and private CI/CD setup? I'd love to get the tests to run publicly, but I'd love to deploy privately and not have all of that information right there in the repo because the plan is to offer it as a service as well.
It looks like GitLab's CI/CD system can now be pointed at GitHub repositories. So that means you can point your GitLab CI system at a GitHub repo and get build/test/deployment of your code, probably integrated with PR checks and so forth.
Commenting on a block of code:
Making a review session:
And here’s a greater overview:
1. ... allow to specify somehow a size of TAB symbol per user or per project (or per review), so we might be able to review Go code normally, without plugins or custom CSS for the browser (8 char default is making code a lot harder to review,especially side-by-side). Yes, there were at least 3 different tickets opened about it the last time I have checked. No, the answer "we going to have .editorconfig support one day" or "good suggestion, maybe one day" are not making it after 2+ years, sorry)
2. ... filename not being hidden by icons would be so awesome in knowing which Java file with 200 char filepath I am trying to review without copying filename to clipboard, and looking at it in VS Code. Wrapping icons is ok, I don't care where is "copy file name" button is located that much.
3. ... have some file patterns rules about what files I would like to have collapsed by default. And while we are at it, add what files to display with ignore-space diff, and which do not, so I will not start every review with the same magic mouse triple click with full reloads of 15 files in between.
Sorry for the rant, code reviews is one of my main responsibilities and this just drives me nuts every day.
See https://about.gitlab.com/contributing/ and https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...
We not only encourage this, we actively help people contributing to GitLab. It's humbling to be a steward to an open source project and something we don't take lightly .
And to be blunt, for an organisation as ours, with very ambitious goals, and highly demanding users, having someone else than us contribute something that makes the product better is the best possible deal we could do. We can compensate for the 'lost' value in our enterprise product by spending that time on other things that are maybe more interesting for our paying customers.
Did you have some particular feature request beyond this view?
This has been available on GitHub for a while now (see https://help.github.com/articles/tracing-changes-in-a-file/)
The strawman you float is the complete opposite of what I asked. It simply occurred to me as strange that there are features that meet all of the following requirements:
1. Available on github for quite sometime
2. Long enough in fact to get a dedicated article in their knowledgebase
3. A popular enough feature to possibly gate the entire calculus for users to switch services.
4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea.
5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line.
> 3. A popular enough feature to possibly gate the entire calculus for users to switch services.
I'd say GitLab's CI/CD system is a lot more useful of a feature. At the very least you can use the actual git blame or another git UI as a workaround. Good luck setting up a replacement CI/CD system.
> 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea.
That's not how triage works. Just because a bug is filed doesn't mean it's "obviously useful". If the employee had immediately given it a high importance, a release date, and assigned it to somebody, that'd be a different story.
> 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line.
Well, since there is another bug already filed for this feature more than six months ago,  I'd say they are quite aware, they just don't consider it as important as you do. The particular person that replied to you just didn't know about it (not surprising when they have more than 10k bugs open).
chinhodado, the GP, framed his feature request as one of the major reasons he is forced to continue using github. Gitlab's motivation for the very feature this thread is regarding, is to poach github customers, or at the very least, increase their customer base by giving people a smoother onramp to transition from github. More power to them.
The feature he describes does, in fact, have obvious utility, which is why it was so strange to me, someone who only uses gitlab for its most basic features, to see the exchange with the gitlab engineer. Surely a company with the venture capital that gitlab has raised would perform the basic ongoing market research that any company in nearly any competitive market performs.
It honestly made me wonder if gitlab on one hand, realizes that they need to inform themselves of useful features, but for whatever reason, doesn't avail themselves of github's features.
How many steps was that?
The interaction with their support was enough to turn me away from their service if that's the type of help they provide.
The main thing that is keeping me on GitHub is the community. GitHub still feels like the main place where developers go to find open source projects. They've done a great job at pulling all of the major corporations like Apple, Microsoft, Google, Netflix, Amazon etc... While that shouldn't really matter because it's just a code repository, some how it does.
- GL is waaaay easier to setup and maintain, both initially (installation, configuration and upgrades) and especially when configuring runners and per-project tasks
- GL saves information about tasks in a file which is part of repo. This might seem counter-intuitive at first, but it makes sense when you realise that build process depends on version (if you want to be able to build old versions of your products). Also, this way config is part of source repo so backup is easier.
- Jenkins can do anything - with a proper plugin. Hunting for the right plugins however is a neverending story. God forbid you ever have to reinstall Jenkins...
Of course that's just my experience. Until GitLab came along we have used Jenkins for a few years and... well, it worked. But it's UX is not comparable to GitLab's.
- Brief explanation: https://github.com/ipfs/infrastructure/issues/100#issuecomme...
- Spreadsheet comparing features: https://docs.google.com/spreadsheets/d/11kTloM6d1CGu_ycmP3Xz...
Check out those links and you should get a good overview
Sounds like that is solved.
I did something similar but only for hosted solutions
I am preparing another blog post for on-premise (GoCD, Jenkins, Concourse etc.)
Do others have this need? Or are people generally focusing on keeping CI runs short and landing changes in a serial fashion?
Rather, we test each branch as it was merged into master (in isolation), and when master changes, trigger builds for PRs that now are changed.
The "Cross Project Testing" and "Cross-Project Dependencies" is something we're deeply in need of though, and already do somewhat. The dependencies are implicit now though (via npm or our golang package manager, gx) rather than explicit.
If anyone have ideas for "cross project testing with dependencies" on Jenkins, I would be very happy to hear them.
+ No infrastructure required. I like to work on my private projects and not their servers.
+ Mostly-declarative syntax with a easy way out when required. Jenkins until recently only had imperative options (scripts in a UI/scripts in classic Pipeline)
+ Caching between builds is inbuilt, while in the past we had to roll our own with Jenkins
- No easy way to share the same script between repos without copy/pasting your .gitlab-ci.yml.
+ More options to display output. Need to have your tests list which ones passed and which failed? Done.
+ Credential Management is better, at least at the "early adopter" free tier I'm on for Gitlab.
- The Legacy/Default UI is bad. The Blue Ocean UI is a bad UI in a winamp skin.
- Integrating plugins designed with pre-workflow jenkins in mind to Jenkins Pipeline is a bit awkward, often requiring you to know which class is used internally in the plugin.
But this sounds even smoother still.
Almost all our Github projects use Docker. We don't use automatic deploys at the moment, but CI basically consists of building a Dockerfile, then running tests with "docker-compose run", then pushing the image to GCR.
We do have some projects that consist of multiple dockerfiles, but they're outliers. Everything else follows the same convention.
We currently use Semaphore, which has several downsides:
* Every project needs to be created and configured individually. We have many, many small projects. On Semaphore, setting up a project requires clicking through 4 or 5 screens to configure. I know Semaphore has an API (two incompatible ones, actually), but that means we have to write code for something that should be included in the box.
* To alleviate this burden, we have a single shell script, hosted with HTTPS and basic auth, that every project runs to build. It does things like log into GCR, set up secret build args, then do the build. Again, stuff that's identical across all projects. It's a bit silly to fetch this script every time rather than have it be shared across the whole organization.
* Semaphore's Docker layer caching (achieved with docker pull + docker build --cache-from) seems inconsistent. Some builds are fast, some don't get any caching.
* Semaphore is terrible at describing test failures. You'd think that a CI system would be great at doing things like show "4 failures/2 skipped/123 successful" on some kind of board. But instead you just get success/failure, and the entire build log. If the test is something like "go test", then you get 99% noise, and it's hard to zero in on what the failure was. I'd love to get the actual failing test in the Slack notification.
We've tried a few alternatives:
* Self-hosted Drone: Great, but too immature when we ran it, and development seems slow, with the organization behind apparently focused on a SaaS solution?
* Google Cloud Container Builder: Better, but requires each project to be "mirrored" within Google Cloud, which is a pain, and the mirroring is flaky. Also, no layer caching. And apparently not appropriate for running Docker Compose tests, and secrets management requires more tendrils into GCP, whereas we prefer things to be ore self-contained.
* CircleCI: Similar problems as Semaphore. Seemed a bit messy.
* Jenkins: Nobody likes Jenkins, apparently.
Based on the above, would Gitlab be a better fit?
That is not a good reason for not using Jenkins. You should try to see if it covers your needs and if it does, you should not care about what other people think about it.
Also you can discover more options here:
I work at a small community college and we have a self hosted instance of GitLab-CE. There's no way we could budget anything for a subscription (as much as I'd love to support GitLab's development.) So, if I could tell my boss that we could get a needed feature for x-dollars/month, that might actually be doable.
I was one of the people asking for the GitHub -> GitLab-CI integration. So I am fairly disappointed it ended up in EE instead of CE.
It’s more than fair that CI/CD is a billable feature.
And making a product plugin play as you ask would make supporting it a huge pain in the ass.
Keep in mind Jenkins is still free if needed
I'm running a custom GitLab instance, and I have most of my projects in there, but I have to have some of my projects on GitHub, and having the same CI workflow available for them is going to be amazing.
It's free if you're using GitLab.com with a public GitHub repository.
https://about.gitlab.com/features/github/ -- "Large Enterprises"
I’ll just hack it in there myself then, like I had to put some of the other "premium" features in myself.
Long-term it looks like I’ll have to migrate to something else then.
> For self-hosted installations, GitLab CI/CD for GitHub is available for customers with Premium and Ultimate license plans.
Ah, my apologies, didn't realize you were self-hosting GitLab vs using GitLab.com. Yes, this is the case for self-hosted instances it is part of the Premium feature. On GitLab.com is is available for free.
All three currently have two big flaws IMO though:
1. They all use YAML which is an awful, unintuitive format.
2. The only way to test a configuration is to commit it and push it. Why is there no way to paste a config file in their website and run that?
Hopefully one day we'll get a CI system that supports Windows, Linux and OSX and has a sane config format, and free minutes for open source projects. A man can dream!
Yaml is honestly the best option here.
and i'm unsure if it really is. There are some imo really good features missing such as document separation, cross references and the newline to space conversion.
toml would be great for pretty much everything thats under /etc/ though.
Main downside: Only paid Mac support, no Windows support.
With GitLab ci, you can run their "gitlab-runner" command locally pretty easily. I use it often to check my builds before actually pushing. It's a simple Go CLI that requires no setup.
As williamchia mentioned above, it's possible to configure GitLab builds for a Bitbucket Cloud or Server repository via webhooks and our build status API today. We're open to helping build better integration, but given the APIs already exist, it would mainly be a project on the GitLab side.
1. We mirror your project
2. We set up the integration with GitHub
3. We report the status and link back on GH's pull requests
More details :
You are also not writing if you use their SaaS solution or if you've installed it on your own servers.