I’m doing you a favor

  • korstmos@kbin.social
    link
    fedilink
    arrow-up
    37
    arrow-down
    1
    ·
    1 year ago

    I dont post my code to github because I would rather use gitlab

    We are not the same

    • tool@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      I want to start moving stuff into Gitlab, but Github Actions is just too good. Is the CI/CD stuff in Gitlab comparable?

      • korstmos@kbin.social
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Ive never used githubs CI/CD, but gitlab has quite a large ecosystem for its CI/CD.
        Seems to me like you could use gitlab as a one-stop-shop to host everything from your code to your artifacts and containers, if you are willing to pay for those fancy features

        Free is able to just do basic CI/CD for like 250 minutes a month, or unlimited via your own runners/build servers, thats about it

      • Nato Boram@lemm.ee
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        GitHub’s actions are so good once it clicks and you understand them. On GitLab, you start from a docker image, so it’s harder to setup some things but easier for others. If you are very good at docker and don’t mind making your own images just for CI purposes, then go ahead.

        Ideally, you should just try them both. You can mirror a project between the two and setup the CI at both places.

        • tool@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          On GitLab, you start from a docker image, so it’s harder to setup some things but easier for others. If you are very good at docker and don’t mind making your own images just for CI purposes, then go ahead.

          I think I’d probably consider myself at/near expert-level with Docker, but CI/CD runners instanced in containers just doesn’t work for some of our workloads.

          As an example, some of our projects have a bunch of Docker images that get built via their own Dockerfiles in the repo, are ran and discarded during the workflow, and each one is modifying the checked-out source tree in some fashion (NPM stuff, composer, whatever, etc), and then a final prod Docker image is built and tested from that source repo tree that has been modified by the Docker containers built/ran/discarded during the workflow. So in Gitlab, it sounds like we’d be running Docker in Docker for some projects.

          You ever ran Docker in Docker? It’s temperamental at the very best and there are a thousand gotchas associated with it, not to mention having to worry about how many variable scopes deep you are and keeping track of that, how to properly bind mount volumes into the nested Docker containers because the method and paths will vary depending on how nested you are, etc. It’s just an absolute nightmare to deal with all-around in that context.

          I’ll see if we have some projects I can try out on it, but the majority of ours are like what I described above.