[HN Gopher] CircleCI Announces Support for Gitlab
___________________________________________________________________
CircleCI Announces Support for Gitlab
Author : octavianc
Score : 106 points
Date : 2022-07-26 18:31 UTC (4 hours ago)
(HTM) web link (circleci.com)
(TXT) w3m dump (circleci.com)
| pid_0 wrote:
| Who even uses external CIs anymore? GitHub and gitlab ones are
| great otherwise you have plenty you can deploy yourself.
| gtk40 wrote:
| We were evaluating CircleCI at work (wanting to move on from
| Jenkins) and ended up going with GitHub Actions near launch as
| it was a similar enough project but without needing another
| vendor involved. We have had some kinks but GHA works well for
| us now with a substantial spend.
| zamalek wrote:
| We recently moved off of Circle CI to self-hosted GitHub
| Actions runners. It is ridiculously expensive: our solution is
| in the region of 27x cheaper.
| mr337 wrote:
| I've seen some projects where the Circle CI costs are more
| expensive than hosting.
| pojzon wrote:
| Datadog+CircleCI+Dynatrace and your project costs more than
| fee full time ppl working on them.
|
| But for some companies paying extra to be able to blame
| someone is crucial.
| nickstinemates wrote:
| (sorry to sidetrack) but what is the usecase of deploying
| _both_ dynatrace and datadog in the same environment? I
| don 't think I have ever heard of this combination
| before.
| sureglymop wrote:
| They're "great"? Really? Imo the only sane thing is to write
| CI/CD pipelines in a scripting language like sh. That way it is
| portable and doesn't depend on one platform. Gitlab CI supports
| "include" but not for scripts, just for templates. It's hard to
| have a centralised repository of scripts and include ones to
| use in a pipeline. I just don't understand why CI/CD couldn't
| just be in sh...
| nickstinemates wrote:
| It's funny I started my career building exactly what you
| suggest. Even in shell. Before adopting Hudson (now Jenkins)
| and the like.
|
| Bespoke CI/CD solutions are great, especially if you're the
| author and tailor it to the business, for a certain size and
| class of use case.
|
| As a business though, it's hardly ever worth the
| investment/maintenance and ongoing operational cost vs. just
| externalizing it and dealing with the consequences unless it
| is your business or a fundamental part of how your business
| is delivered. Thus, generic (but extensible) solutions are
| the happy medium.
| mappu wrote:
| You may be interested in Laminar CI.
| tpmx wrote:
| I just tried out the AWS offering for CI/CD
| (CodePipeline/CodeBuild) and was disappointed with time-from-
| commit-to-deploy (to ECS, although it's the launch/build time I'm
| primarily concerned with here). It appears to waste 1-3 minutes
| on just queueing and provisioning a new VM to do the build. It's
| highly variable, too.
|
| The main tradeoff (if the cost difference is insignificant)
| between this and a third party service like e.g. CircleCI appears
| to be between:
|
| a) security (another service that can be comprised - with the
| implicit capability to instantly deploy something that owns your
| service)
|
| and
|
| b) latency/performance (CircleCI consistently starts builds
| within a few seconds)
|
| How do you think about these things?
| lflux wrote:
| Still no support for arm64 docker executors after years of asking
| for it.
| mtlynch wrote:
| Can't you run Docker on an arm64 machine executor?
|
| https://circleci.com/docs/using-arm
|
| I know it's not as convenient as being able to use a docker
| executor directly, but it seems straightforward to work around.
| lflux wrote:
| I can and it would require porting my entire CI workflow to
| machine. We use a lot of docker-executor specific stuff, and
| if I'm going to spend the time to port several thousand lines
| of CI config, I can just port it to a different CI platform
| instead.
| mtlynch wrote:
| Oh, gotcha. You have CI for multiple architectures already
| and you want to add arm64? I was thinking it was brand new
| code you wanted to write, but I get why you wouldn't want
| to rewrite everything.
| lflux wrote:
| Just on amd64 right now, we want to move to add support
| for arm64.
|
| Sadly we adopted CircleCI early on and make heavy use of
| their support for multiple containers - if you specify a
| list of containers in a Docker job, it will execute the
| tests in the first container and connect the other
| containers as "data" containers (think redis, mysql et c)
| for use in tests.
| dugab wrote:
| If you need services for your tests in CI, you might want
| to look at what Gitlab CI "services"
| https://docs.gitlab.com/ee/ci/services/
| mtlynch wrote:
| I've been a CircleCI customer for 3 years. I'm interested in
| moving from Github to Gitlab, as I'm philosophically more aligned
| with Gitlab.
|
| I tried out CircleCI's Gitlab integration a few weeks ago during
| the public beta, and it felt like CircleCI was really phoning it
| in.
|
| The instructions led me down paths where the product would just
| break. It told me to connect CircleCI to Gitlab through OAuth,
| and then my first build immediately died asking for a personal
| access token.[0] I generated a PAT instead, and then CircleCI
| failed my build because it was provisioning an empty SSH private
| key.[1]
|
| They had a channel for reporting bugs with the integration, but
| it doesn't create a real support ticket. Their feedback channel
| was just their public Canny feature request board. I submitted my
| feedback anyway, and they didn't respond for over two weeks, at
| which point the response was basically just, "Oh, we fixed a lot
| of bugs, so maybe we fixed yours. Can you delete everything and
| try again?"
|
| [0]
| https://twitter.com/deliberatecoder/status/15430630495982714...
|
| [1] https://circleci.canny.io/gitlab-vcs-experience-
| feedback/p/n...
| pojzon wrote:
| In case you consider Gitlab as an e2e solution or devops
| platform as a whole:
|
| Why would you need CircleCI?
|
| Gitlab can work as a full CICD platform.
| mtlynch wrote:
| Yeah, I'd like to, but I found Gitlab's CI to be a
| substantial step down from Circle's CI product. I elaborated
| a bit more in another comment:
|
| https://news.ycombinator.com/item?id=32242463
| ollien wrote:
| Can Gitlab CI use CircleCI workflows? There's less risk in
| just changing your VCS platform, rather than both your VCS
| and CI/CD at once, especially if you have to rewrite all your
| workflows.
|
| Obviously something like Dagger[1] solves this, but I don't
| know how widely used that is at this point.
|
| [1] https://dagger.io/
| candiddevmike wrote:
| What does it mean to be more philosophically aligned with one
| corporation vs another?
| CameronNemo wrote:
| Maybe more philosophically aligned with the _product_ ,
| rather than the corporation behind it. Microsoft is slowly
| turning GitHub profiles into networking tools and the core
| SCM offering into a social media experience. GitLab is
| similar in some ways, but not quite as aggressive about it in
| my view.
| jeremyjh wrote:
| Github has always had a social media aspect. Profiles,
| stars, feeds, followers have been there since early days.
| One of their tag lines was "social coding".
| 999900000999 wrote:
| Whenever I want to view my private repos, I have to
| navigate a painful UI first.
|
| I'm given badges, and other gamification crap.
|
| Then again, when I publish my projects I tend to post them
| either here or on Reddit.
|
| Maybe Microsoft, with some justice, wants a cut of the
| traffic?
| TAForObvReasons wrote:
| GitLab offers a free and open source self-hosted "community
| edition" and understands it to be in their strategic
| interests to continue with the open source offering. GitHub
| does not offer it and does not appear to believe that an open
| source self-hosted offering is in their best interests.
|
| Supporting GitLab on those reasons alone, and choosing to pay
| for GitLab Enterprise Edition because they offer the
| Community Edition, is "philosophically aligned"
| djbusby wrote:
| That the buyer believes in the same thing the company
| "believes" in.
|
| Eg: GitLab has an open-core product and GitHub is owned by
| (evil?) Microsoft.
| robertlagrant wrote:
| Also the company is incredibly open, with lots of its
| documentation and meetings done in public and available on
| YouTube. Pretty interesting.
| mtlynch wrote:
| I like many things Gitlab does: open-sources most of their
| product, publishes their documentation openly, promotes
| remote work.
|
| I strongly dislike some of the things that Github does: suck
| up open-source code and re-sell it through Copilot, stifle
| competition by offering free services that their non-MS-owned
| competitors can't afford to offer.
|
| I don't think either one is purely good or purely evil.
| Overall, I like both companies better than average, but I'd
| rather support Gitlab.
| bloppe wrote:
| The co-pilot concern I get. I think the root of the problem
| is that everybody seems to have almost signed away their
| copyright to GitHub as part of their terms of service:
| https://fossa.com/blog/analyzing-legal-implications-
| github-c... "If you look at the GitHub Terms of Service, no
| matter what license you use, you give GitHub the right to
| host your code and to use your code to improve their
| products and features"... yeesh
|
| I don't really agree with the concern that they "stifle
| competition by offering free services that their non-MS-
| owned competitors can't afford to offer". GitLab is clearly
| able to differentiate with with their terms of service, as
| evidenced by your and others' comments here. I don't fault
| the vast majority of FOSS developers, especially those
| using permissive MIT-style licenses, for favoring cost-
| efficiency over control. It's good to have both options.
| hawaiianbrah wrote:
| GitHub also promotes remote work. Most of the company is
| remote and will always be remote.
| mtlynch wrote:
| That's fair, but I think Gitlab promotes it more
| strongly. They're 100% remote, and they publish guides
| teaching other companies how to replicate their remote-
| first setup:
|
| https://about.gitlab.com/company/culture/all-
| remote/guide/
| soneca wrote:
| Gitlab advocates for paying local salaries. That's
| actually against my "philosophy" as you put it, as it is
| against my direct interest, being a non-US based software
| developer.
|
| Their way to promote remote work is, ironically, hurtful
| to my prospects as a remote worker.
| CSMastermind wrote:
| Yeah location based salary discrimination is one of the
| biggest issues in our industry in my opinion. I'm really
| hoping that the move to more remote-forward working
| cultures spurred by Covid will lead to this being
| corrected.
| mtlynch wrote:
| That's fine. I'm not trying to convince anyone that
| Gitlab is the messiah or anything. Someone just asked me
| why I align more philosophically with Gitlab than Github,
| so I explained what appeals to me personally.
|
| If they don't align with your philosophy, that's cool
| too. You get to choose how that affects your choice of
| VCS/CI provider.
| forty wrote:
| Overpaying remote workers compared to the local market is
| bad as it create distortion of local markets (on housing
| especially where local non remote workers cannot afford
| living where they work).
|
| (I'm a remote worker outside of the US and my personal
| interest would be to be paid more, but I don't believe it
| would be the general interest)
| Benjamin_Dobell wrote:
| This line of reasoning doesn't consider equity, and the
| fact that people _want_ to move - especially out of low
| socioeconomic areas. If you 're paid a local wage,
| there's basically no way you'd ever be able to relocate
| to somewhere more expensive since selling your house
| wouldn't put a dent in the price of a home elsewhere.
| ok_dad wrote:
| Gitlab should just offer to cover moving expenses for
| employees 1 time per X years, then even the poorest-paid
| person working there would have that freedom (aside from
| any immigration concerns). I don't think it's in their
| best financial interests, but would cost maybe 10k at
| most and whatever the additional salary per year is and
| garner more support for their "local pay scale" strategy.
| inferiorhuman wrote:
| Sure, but paying a high wage relative to the local
| prevailing wage is different than paying the same high
| wage everywhere. _Part_ of the problem in the Bay Area is
| that tech companies distorted the local wages so
| dramatically.
| criley2 wrote:
| People are going to min-max whatever system you offer. If
| you don't pay equally and you adjust for cost of living,
| people are likely going to go for high CoL locations and
| make you pay the most. If you don't adjust for CoL,
| you'll likely see your devs leave high CoL areas for
| lower ones. While you might be "overpaying" them
| according to their chosen CoL, you're likely underpaying
| what the high CoL would have demanded.
|
| It seems counter-intuitive but I imagine that not doing
| CoL adjustments actually lowers total payroll.
| inferiorhuman wrote:
| I interviewed with Github recently (a pretty mediocre
| experience overall) and it seemed like they've fully
| committed to remote work. They don't even bother with on
| site onboarding anymore.
| IfOnlyYouKnew wrote:
| I feel GitHub is the best thing that ever happened to the
| Open Source Community.
|
| Before, it was freshmeat and, for collaboration, arbitrary
| mailing lists each enforcing their same "standards" to send
| in patches. I can only assume the process was sometimes
| smooth, sometimes terrible. In any case: I never did it.
|
| In the GitHub era, I have regularly made pull requests.
| Small ones on a maybe weekly basis, larger ones twice a
| year or so.
|
| I feel confident in the estimate that the number of
| contributors has grown by at least an order of magnitude,
| and that GitHub was a significant factor in this
| development.
|
| Gitlab, meanwhile, started out as so obvious a clone their
| CSS still had classes named "gh-large-..." months after
| launch. Then, they would frequently have the audacity to
| complain when GitHub copied some minor feature they had
| first implemented.
| dijit wrote:
| Github is social media for code; which is great for
| discovering things or fly-by addons..
|
| Social media in the workplace is not as great, ask anyone
| using facebooks communication platform:
| https://www.workplace.com
|
| I much prefer working with gitlab as a product 9hours a
| day on internal systems.
| superb-owl wrote:
| TIL CircleCI didn't support GitLab. I'm surprised it took them
| this long.
| mtlynch wrote:
| It's been their most requested feature for a long time:
|
| https://circleci.canny.io/cloud-feature-requests?sort=top
| bdcravens wrote:
| Isn't one of the main selling points of Gitlab their built-in CI?
| Anyone using Gitlab use an external CI?
| ramoz wrote:
| They offer a whole kitchen sink at this point and honestly it's
| not great.
| cyberpunk wrote:
| I really like GitLab's CI. Actions is probably winning the
| war, though.
| pas wrote:
| GitLab CI can launch multiple pipelines on the same
| push/trigger (use separate files, like GH Actions, etc),
| but even after using it for I don't even know how many
| years I'm still struggling with setting it up in a nice
| way.
| freedomben wrote:
| Actions does seem to be winning, but having used both
| extensively I'm convinced that it's on name recognition
| alone (with pricing being a second). Gitlab CI is my
| favorite of the many I've tried (gitlab, circle, travis,
| github), Actions is probably my least preferred. It gets
| the job done but there are always a lot of actions-specific
| stuff for every job, whereas with most of the others
| they're relatively portable. Actions feels like it was
| designed with lock-in as a primary goal.
| mtlynch wrote:
| It appeals to me as someone who likes Circle's CI offering but
| wants to move away from Github.
|
| I tried using Gitlab's CI and was surprised at how limited it
| was. The Gitlab CI syntax was harder to follow, and my
| integration tests took 17m to run when they ran in almost 1/3
| the time on Circle.
|
| A big part of the problem was that CircleCI lets me use an
| instance with 8 CPUs / 16 GB RAM with just a config file
| change[0], whereas every Gitlab instance is 1 CPU / 3.75 GB RAM
| unless you host your own runners.[1] But if I'm paying a
| company to manage CI, I don't want to provision my own hardware
| infrastructure
|
| [0] https://circleci.com/docs/configuration-reference#docker-
| exe...
|
| [1]
| https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner...
| judge2020 wrote:
| Related, GitHub has had 'use more powerful hosted runners' in
| the pipeline for over 2 years[0]. This issue replaced another
| now-deleted issue[1] from July 2020.
|
| Really disappointing, as I've had to resort to using `az vm
| start` -> run -> `az vm deallocate` to use an on-demand
| powerful runner.
|
| 0: https://github.com/github/roadmap/issues/161
|
| 1: https://github.com/github/roadmap/issues/95 (note: added
| `ga` `ae` and removed `beta` `cloud` labels on Oct 13, 2020 ;
| the previous text: https://web.archive.org/web/20200731200411
| /https://github.co... )
| robertlagrant wrote:
| As a former CircleCI customer (my new employer uses Gitlab)
| I can highly recommend them. They make that issue so easy.
| You can even request GPU machines and it all works really
| well.
| Dracophoenix wrote:
| Why are you a former customer?
| thinkafterbef wrote:
| I'm a bit biased as one of the founders of BuildJet, but we
| solve this exact issue.
|
| BuildJet for GitHub Actions, plugs elegantly into GitHub
| Actions. With 1-line change in your config, you get 2x
| speed for half of GitHub's price.
|
| Check it out @ https://buildjet.com/for-github-actions
| stusmall wrote:
| Oh this is good. I couldn't find it in your documentation
| but how big are the disks on these VMs?
| jacooper wrote:
| Quick question, why does every startup on earth have
| google as a customer? Shouldn't a company of this size
| have its own solutions and programs?
|
| This is in no way a deg against your project, its just a
| general question .
| judge2020 wrote:
| I imagine non-core-product teams at Google are encouraged
| to submit purchase requests for any tools they think
| would improve their processes instead of being
| constrained to existing solutions. They also could just
| be showing it because someone with an @google.com has a
| paid account, but I don't know for sure :)
| mqus wrote:
| We're using gitlab with (on-premise) jenkins. It seems just
| much more capable (and if we choose to switch away from gitlab
| it won't matter)
| philwelch wrote:
| My last job used Gitlab _as_ an external CI.
| superb-owl wrote:
| Funny, I was gonna say the same thing. But I also remembered
| GitHub now has built-in CI (Actions).
|
| I wonder if Circle is struggling to maintain market share.
| danielvaughn wrote:
| With all the built-in support for CI, I'm not sure how
| CircleCI is even operating anymore.
| avip wrote:
| Using built-in gitlab ci. It's definitely good enough for my ci
| needs. Setup was easy. Love having less tools involved in my
| day2day.
|
| Some features seem to work incorrectly (ex. some combinations
| of branch filter rules + file changes rules). Or I misread the
| docs. For a free service it gives excellent value.
|
| Circleci also good product. But having 1 less "thing" wins over
| most other considerations for me.
| mdaniel wrote:
| As a long-time GitLab CI user, I do miss how the local circleci
| runner binary _just worked_. I am aware of gitlab-runner but it
| is a sick joke designed to mislead folks who just skim the docs
| into believing that they have a local execution story
|
| Or, I guess a more conciliatory stance is: wow, folks must be
| using some pretty hello-world pipelines if `gitlab-runner exec`
| works for you
| goodoldneon wrote:
| We provision our self-hosted runners via Terraform and
| GitLab's Helm chart. It's a relatively painless setup, but
| obviously not a few button clicks and commands
| mdaniel wrote:
| > a local execution story
|
| I can see how "local" can have multiple meanings, but here
| I meant "as a developer on my laptop, can I have local
| docker run things the way GL is going to run things?"
|
| I hear people say a lot "oh, I just use shell scripts, NBD"
| but as I said, I'm sure for hello-world setups which don't
| have any includes or take advantage of GLCI constructs that
| can work fine, but what rubs me the wrong way is that
| "gitlab-runner exec" doesn't say "just use shell scripts,"
| it says "gitlab-runner exec - execute a build locally" and
| it for sure does not do that
| AtNightWeCode wrote:
| How can a CI-service not support ANY GIT source? All this garbage
| surrounding GIT is just baffling.
| mdaniel wrote:
| I would guess it falls into the "what assumptions does the
| runner make?" followed closely by "there is no standard for
| what env-var contains: the current branch, the commit sha, the
| commit message, the current pipeline identifier, ..." and a
| bazillion other bits of contextual information
|
| Made worse by: ok, fine, you magically have `eval $(git set-
| env-from-commit HEAD)`, now how do you report those run results
| back to the upstream UI, since there is _for sure_ no standard
| for that
| LukeShu wrote:
| As much as I want to agree with you, I get it:
|
| - To avoid polling, you want to be able to register a webhook
| to be notified when pushes happen. You're going to need Git-
| servicet-specific parsing of the webhook payload, and you
| probably want to be able to speak a Git-host-specific API to
| automatically register that webhook to make it easy for users.
| (Falling back to polling would be good, but few do.)
|
| - If you're a paid product, you definitely need to support
| private repos. You probably want to be able to speak a Git-
| service-specific API to set up the credentials to be able to do
| that `clone`; in GitHub parlance use the API to create a
| "deploy key", rather than requiring users to manually mint an
| SSH key, set up a bot account on the Git-service, add the SSH
| key to that account, and upload the SSH key to the CI-service.
| (Falling back to being able to provide a raw Git URL and
| credentials would be good, but few do.)
|
| - To avoid confusing user-account permission mismatches, you
| probably want to piggy-back on the Git-service's user system;
| supporting "sign-on with X" and using the Git-service's "is
| admin of this Git repo" for allowing access to your the CI-
| service's admin interface for that repo.
|
| - You want to be able to post statuses back to the Git-host.
| This takes a Git-service-specific API. (Falling back to letting
| the user provide their own script for posting statuses would be
| good, but few do.)
| aeyes wrote:
| Because the integration is entirely built on webhooks and each
| Git hosting provider has their own.
| jrockway wrote:
| I doubt there was a problem cloning GitLab-hosted repos on
| CircleCI before this announcement. But there are plenty of non-
| Git things that these hosts do; pull requests, status checks,
| etc. I am guessing that "support for ..." entails all of those
| extras.
| gmemstr wrote:
| As an ex-CircleCI employee, this is really exciting because it
| marks a pretty significant milestone in a particular internal
| effort. Very much looking forward to what comes after this.
|
| This might strike some as a weird event (Gitlab already has
| CI/CD!), but it _was_ highly requested and is (probably) of other
| similar things coming to fruition!
| fariszr wrote:
| Gitea next please! It would be awesome if Circle CI supports
| Gitea, which is in need of such an advanced CI/CD provider.
___________________________________________________________________
(page generated 2022-07-26 23:00 UTC)