GitLab 10.6 released with CI/CD for GitHub | Hacker News Reader

GitLab 10.6 released with CI/CD for GitHub

about.gitlab.com

273 pointsrbanffy101 comments

Gitlab's CI/CD is amazing. Of all the systems I've seen, it's the easiest to (a) deploy your own runners easily, and (b) mix private and public runners (i.e. the equivalent of using a free plan on Travis, with the benefit that for heavy-duty jobs you can run your own machines). That and first-class support for docker (no more being at the whims of what Travis chooses to deploy in their images), make it a really great system.

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.

Have you tried CircleCI? I've found it really straightforward to use in a lot of the same ways you mention, except for perhaps the docker support -- it uses docker images and you can of course have a docker image that supports docker, but it doesnt upload to dockerhub out of the box.

I'm curious to know how the two compare because I haven't tried Gitlab before.

So last time I checked (and I sent an email to sales to confirm) CircleCI doesn't have support for a configuration where you want to use both public and private runners.

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).

Ah interesting. Thanks for the reply.

We use buildkite at work, and it works well. Buildkite hosts the CI master, and you run the workers on your own infrastructure -- as many as you want. So you don't get the free public agents like you want, but you do get private runners.

My company's also using Buildkite, and I've been hugely impressed with how easy it is to work with, and how flexible it's been for us.

Disclosure: I work at Shippable.

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.

Edit2: This is wrong, see replies below.

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.

Hi Eslaught - So the new CI/CD for GitHub feature should be solving the pain points of the old manual mirroring process. When you set up a project and Oauth to GitHub it should automatically implement 3 components: - Bidirectional Mirroring https://gitlab.com/gitlab-org/gitlab-ee/issues/3745 - push webhook to GitLab to trigger CI/CD immediately once a code is committed (e.g. "push mirroring") https://gitlab.com/gitlab-org/gitlab-ee/issues/4691 - GitHub project service integration (to webhook CI status back to GitHub.) https://gitlab.com/gitlab-org/gitlab-ee/issues/3836

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?

FWIW, if you created the connection between GitLab and GitHub for your project before 10.6, you'll have to remove the connection and then re-add it to get the push-based mirroring to happen. Otherwise, yes, it will still poll.

How do you do this?

It seems like you should be able to do this, but there may need to be an update to work with already-mirrored repos since the feature was designed to have a flow that expects a new project to be created.

I've logged an issue to track down the process: https://gitlab.com/gitlab-org/gitlab-ce/issues/44552

I guess I got lost on my initial pass through the UI.

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?

> Is there a way to do this for existing repos?

You can add a webhook on GitHub and have it point to our Pull Mirroring API [1], followed by manually setting up the integration to send status updates back [2].

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.

[1] https://docs.gitlab.com/ee/api/projects.html#start-the-pull-...

[2] https://docs.gitlab.com/ee/user/project/integrations/github....

It also seems massively overpriced. $99/user/month? Pff. No one is going to pay that. Certainly not large enterprise businesses.

I'm planning on open sourcing my service and was planning on using GitHub because I wanted to get people involved. However, currently I'm using a local server with Jenkins to poll GitHub for the deployment with a separate repository for deployment configuration. This isn't ideal and I'm not a huge fan of Jenkins itself in the first place. (It took a huge amount of time to setup!)

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.

Since "X adds support for Y" is nearly always ambiguous and confusing:

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.

The original title was "GitLab adds support for GitHub". Now that GitLab supports GitHub, I'll go to GitLab for all my support questions about using GitHub!

Pssh. Gitlab was obviously just tallying the individual sentiments of whether the users were generally in favor of Github continuing to exist as an organization. How could you have missed this?

So GitLab's CI/CD is now modularized and theoretically can be used in place of Circle CI or similar?

Nope, it's not modularized, just a group of *-hooks to trigger, update and report pipelines (and their statuses) GitLab <-> Github (a 2-way communication channel) you'll get the status when opening PRs right in GitHub and so on.

I hate it that Gitlab is focusing too much on all these project-management features, while neglecting the basic code review features such as commenting on a block of code, or making a review session instead of creating individual comments, or the ability to blame previous revisions of a file

At least you can blame previous revisions of a file? Using an URL like gitlab.com/username/project/blame/COMMITHASH_OR_TAG/path/to/file

You can, but you need to copy-paste the hash to the URL manually, which is not exactly good UX.

No you don't? If you click on a particular commit, you can click "View file @ HASH" and from the click the Blame button?

When you click on a particular commit, you see all the files affected by that commit, which can be in the dozens. Now you have to search for the file you're interested in again, click on View file at..., then in there search again for the line you're interested in, click on it then go back to the top of the page and click on Blame (or click Blame first and search for your line later, same thing).

How many steps was that?

It's open source. I'm sure they wouldn't turn down a PR if you submitted one. I've poked around the codebase a few times; it's not too hard to contribute, despite my lack of experience with ruby.

It's open core, not open source. I'm pretty sure they would have a lot of incentives to turn it down.

We don't have a lot of incentives to turn down contributions. Quite the opposite.

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 [0].

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.

[0]: https://about.gitlab.com/stewardship/

That's reassuring, thanks for replying. I was commenting from a general perspective on open core licensing but I understand not all companies are created equal.

Product manager at GitLab here. We welcome contributions!

See https://about.gitlab.com/contributing/ and https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...

This release is mainly for improved CI/CD and Kubernetes support. How is that related to project management?

These are exactly the type of features we are focused on this year.

Commenting on a block of code: https://gitlab.com/gitlab-org/gitlab-ce/issues/4143

Making a review session: https://gitlab.com/groups/gitlab-org/-/epics/23

And here’s a greater overview: https://about.gitlab.com/direction/#merge-requests-approvals...

Now if you guys would get to...

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.

Here's an example of a blame on a previous commit of a file.

https://gitlab.com/gitlab-org/gitlab-ce/blame/57ce7c655cc58e...

Did you have some particular feature request beyond this view?

The use case is to be able to repeatedly blame on the previous revision of the change that was made to a line. This is especially useful when you're dealing with diffs resulted from code formatting, whitespace changes, etc. in a file and you want to see what is the "original" commit that the change was made.

This has been available on GitHub for a while now (see https://help.github.com/articles/tracing-changes-in-a-file/)

Thank you for the explanation. I've created an issue. Feel free to continue the discussion there.

https://gitlab.com/gitlab-org/gitlab-ce/issues/44553

Does this mean that gitlab doesn't generally employ people to simply learn their competitors products, to keep informed of their offerings?

This is a highly unfair criticism, you’re never going to have total feature parity with your competitors, nor is that even a good thing to strive for.

Mine is a perfectly valid criticism. You do nobody any favors by conflating the goal of total feature parity with the general concept of business intelligence, and understanding your direct competitor's key features.

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.

You seem pretty worked up about this one feature.

> 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, [0] 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).

[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/37135

You seem to baselessly project negative emotions and motivations on to your interlocutors in lieu of coherent points that actually refute their arguments.

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.

Or basic modern web UX. Like using a wide screen effectively.

Under your profile settings/preferences, you have the ability to set your layout to 'fluid' This will allow the application to take up 100% of the width of the screen. If you have more specific UX issues you think we should address, I'd love to hear them!

I really want to try GitLab, but I can't log in to their service with oAuth using Google as a provider. I get a 422. I brought this up with GitLab's support, and they essentially told me it was my fault and doing something wrong with JS or something. It's just me clicking on links on their page, wtf.

The interaction with their support was enough to turn me away from their service if that's the type of help they provide.

I ran into this recently. You probably created a GitLab account with your Gmail address first and then afterwards tried logging in with OAuth and encountered the 422. Try logging in without OAuth, then enable social sign in under https://gitlab.com/profile/account

Unfortunately, it's not the same problem. I get the same results from multiple gmail/gsuite addresses. womp womp

Please email me directly. (email in profile) I'd like to look into what happened here.

I sent you an email.

Will this be the Trojan Horse that gets me to switch to GitLab? I've been reading a lot of great things about GitLab's CI/CD. They also have cheaper plans for developers and if everything is all integrated into one place, that would make setup for OSS projects that I maintain like gitignore.io really simple.

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.

I'm curious for the people that use GitLab CI/CD, what's the pro / cons vs Jenkins and the like?

A short while ago (eh, just noticed this was over a year ago...) I did a comparison between different testing solutions for all projects within the IPFS organization. Remember this was a year ago, so many things have changed but we ended up going with Jenkins and I'm now migrating projects from free usage of Travis/CircleCI to Jenkins.

- 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

"Haven't really found any good way of integrating the Gitlab-CI with Github"

Sounds like that is solved.

Nice summary. Did you test support for handling multiple changes to a single project in parallel? The only CI Platform I've found that tries to handle this in any meaningful way is OpenStack Zuul (https://zuul-ci.org/) and https://docs.openstack.org/infra/zuul/user/gating.html#testi... for details of the parallel support.

Do others have this need? Or are people generally focusing on keeping CI runs short and landing changes in a serial fashion?

No, this was not a consideration, as we often have so many PRs open at one time, that this is probably not feasible. If I understand the process correctly, it would merge each PR in order from the first made until the most recent one. So the most recent one includes all the proposed changes. For ipfs/go-ipfs, that would involve doing 104 tests + builds for each PR.

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.

Very Nice!

I did something similar but only for hosted solutions

http://blog.codepipes.com/hosted-ci-comparison/hosted-ci-com...

I am preparing another blog post for on-premise (GoCD, Jenkins, Concourse etc.)

We used both at previous and current job. As far as I'm concerned there's no reason to stick to Jenkins unless you really can't afford time to migrate. And even then you probably should. Main differences:

- 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.

So I use Gitlab CI on my personal projects, and in work I was "the Jenkins guy" on our team for a good while, though I've since changed projects to one using an internal tool so my Jenkins knowledge is ~1yr outdated.

Gitlab CI:

==========

+ 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.

Jenkins:

========

+ 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.

Thanks for reviewing GitLab. We introduced a way to share scripts in the last version as a paid feature https://about.gitlab.com/2018/02/22/gitlab-10-5-released/#in...

Both a sticky header and a sticky footer... This reminds me of the IE6 days when most of your screen real-estate was taken up by toolbars.

Related Jenkins announcement: https://jenkins.io/blog/2018/03/19/introducing-jenkins-x/

This makes a lot of sense to me. Gives Github users a taste of Gitlab's CI capabilities.

Note that today you can use the public hosted GL service and mirror a GH repo, and trigger GL CI when new commits arrive.

But this sounds even smoother still.

I've never used GitLab, and I'm curious if it's something my company could use.

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?

Gitlab solves 1 (manual UI config for each build) and 3 (Docker image build time) at least in my experience, but it's caching is transparent so I don't know if you were using a less common image would it be slower. It doesn't solve 2, you'll need a .gitlab-ci.yml for each repo, and it has the exact same problem 4 (no way to drill down into test failures).

> Jenkins: Nobody likes Jenkins, apparently.

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:

http://blog.codepipes.com/hosted-ci-comparison/hosted-ci-com...

If any GitLab people are still watching this thread, has there ever been any discussion on offering subscriptions to specific EE features? Instead of a full per user subscription.

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.

I feel your pain but unfortunately free doesn’t pay the bills.

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

Thanks for your comment. We would be happy to discuss options with you if you could submit a contact request by following the link here https://about.gitlab.com/sales/ we will reach out to you.

Finally!

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 seems this feature is only available in the Premium plan, if you're hosting your own instance.

It's free if you're using GitLab.com with a public GitHub repository.

https://about.gitlab.com/features/github/ -- "Large Enterprises"

Oh fuck that. I’m a student using this to host open source projects, I’m not going to pay more for GitLab than I pay for all my servers and software combined.

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.

Hi Kuschku - I think this is misunderstanding, we are offering GitLab CI/CD for free for GitHub.com projects. It'll be free for private repos for a year, and it will be free for public repos forever. See the "Open source projects" and "Anyone using GitHub.com" sections: https://about.gitlab.com/features/github/

According to

> For self-hosted installations, GitLab CI/CD for GitHub is available for customers with Premium and Ultimate license plans.

It’s not.

Edit: I see clearly now in the top-level comment you mention self-hosting

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.

Also available for free for "anyone using GitHub" - not just enterprises :) https://about.gitlab.com/features/github/#anyone-using-githu...

Sorry, I don't understand your point. Is there anything in my comment that was incorrect?

No, I'm sorry, your comment is correct. It is free on GitLab.com for public repos. It is also free for private repos on GitLab.com for the next year.

Not really related to the story, but I just saw that you can run Gitlab on a Raspberry Pi. Has anyone done this and care to share how well it works? Seems like a nice way to get a Git server for the homelab.

This is great, although I'll probably stick with Travis & Appveyor for my open source project since Gitlab.com currently only has Linux runners.

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!

You could replace Travis with Gitlab, since you are using AppVeyor for Windows anyway.

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.

Gitlab doesn't have free cloud-based OSX runners. Travis does.

On CircleCI you can SSH into a running instance. This helps to test/debug configuration changes without coommitting/pushing. My preferred CI experience so far. (I'm not affiliated.)

Main downside: Only paid Mac support, no Windows support.

Ive got mixed feelings about yaml as well, but which format would you prefer? The Jenkins DSL ist terrible to debug and XML is way too verbose for such a usecase.

Yaml is honestly the best option here.

TOML is much better.

i don't know any CI/CD framework which utilizes it though.

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.

Gitlab runners have different "executors". One of which is virtualbox. if you have a windows vm where you can ssh into, it works well

Is this available for Stash/Bitbucket as well?

Hi - with GitHub everything is configured automatically. A future feature may implement this for BitBucket as well, but you can get a similar experience today by manually configuring the component parts (mirroring, webhook to GitLab on commit, add a script to push the pipeline status to Bitbucket). There is a guide here on how to do that: https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/bitbu...

Bitbucket Cloud PM here. We'd love to see more usage of Bitbucket (both Cloud and Server) by GitLab users.

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.

Is there a way to migrate a repo from Bitbucket Server into gitlab preserving pull request history?

There is a lack of APIs from bucket to allow that kind of operation. You should consider the lockin each platform have, before jumping in

what makes it different than ordinary webhook ?

That's possibly what was implemented now.

More details :

* https://gitlab.com/gitlab-org/gitlab-ee/issues/3835

* https://gitlab.com/gitlab-org/gitlab-ee/issues/4691

In short:

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

Please fix this to point to the original article, not this blogspam.

https://about.gitlab.com/features/github/

I'm not sure if you noticed but this "blogspam" is literally a release note, as says in the title " GitLab 10.6 released", support for GitHub is one of many features.

You're commenting on the changed link. The original was techcrunch blogspam.

We've updated the link from https://techcrunch.com/2018/03/22/gitlab-adds-support-for-gi... to this announcement.

We used big(6gb) git repo on gitlab. I lived to many problems and moved to gogs now we are hapy with gogs. It is much more lightweight. Just try gogs and gitlab.

The headline is that GitLab adds CI/CD support for GitHub and you are writing about migrating to Gogs which has not nearly as much features. Gogs is a lightweight git hosting solution, so basically the opposite of GitLab. I am not saying Gogs is bad, in fact I use it myself but you are comparing two completely different things. If you only need a simple git solution, you can use Gogs, if you need more and like the features GitLab has you don't have any self-hosted alternative.

You are also not writing if you use their SaaS solution or if you've installed it on your own servers.

Reply on news.ycombinator.com