Comment by cobertos

Comment by cobertos 2 days ago

23 replies

View on Hacker News

Re: 6. ... Github Actions

Github Actions left a bad taste in my mouth after having it randomly removed authenticated workers from the pool, after their offline for ~5 days.

This was after setting up a relatively complex PR workflow (always on cheap server starts up very expensive build server with specific hardware) only to have it break randomly after a PR didn't come in for a few days. And no indication that this happens, and no workaround from GitHub.

There are better solutions for CI, GitHub 's is half baked.

paulddraper 2 days ago

This is documented currently (supposed to be 14 days). [1]

That said, I have found runners to be unnecessarily difficult.

But Jenkins and its own quirks, and when I used GitLab, it used ancient docker-machine and outdated AMIs by default.

I think Buildkite has been the only one to make this easy and scalable. But it is meant for self hosted runners.

[1] https://docs.github.com/en/enterprise-cloud@latest/actions/h...

Reply View 1 reply
swyx 2 days ago

bugs happen to all of us. whats your better solution - gitlab?

Reply View 20 replies
  • shoo 2 days ago

    Roll 2d6, sum result. Your CI migration target is:

      2. migrate secret manager. Roll again
  3. cloud build
  4. gocd
  5. jenkins
  6. gitlab
  7. github actions
  8. bamboo
  9. codepipeline
  10. buildbot
  11. team foundation server
  12. migrate version control. Roll again
    Reply View 6 replies
    • swyx 2 days ago

      somehow i am really liking the kind of people that comment in the comment sections of sysadmin posts. i wonder what personality type this is

      Reply View 3 replies
    • mroche 2 days ago

      Bump up to 2d10 and add:

          - Travis
    - CircleCI
    - Drone/Woodpecker
    - Tekton Pipelines
    - TeamCity
    - Zuul
    - Buildkite
    - Agola
      Reply View 1 reply
  • esseph 2 days ago

    GitLab pipelines are really good.

    Reply View 4 replies
    • Balinares 2 days ago

      Not in love with its insistence on recreating the container from scratch every step of the pipeline, among a bundle of other irksome quirks. There are certainly worse choices, though.

      Reply View 3 replies
      • friendzis 2 days ago

        Opposite of Jenkins where you have shared workspaces and have to manually ensure workspace is clean or suffer from reproducibility issues with tainted workspaces.

        Reply View 1 reply
        • maratc 2 days ago

          It's up to you whether you have a shared workspace or not. My machines/pods are destroyed and recreated after each job, so I never had this issue.

          Reply View 0 replies
      • esseph 2 days ago

        You don't actually have to.

        If you use the built in container registry and build artifacts, you can pass between steps.

        Reply View 0 replies
  • sharts 2 days ago

    honestly jenkins really isnt that bad

    Reply View 6 replies
    • friendzis 2 days ago

      Hudson/Jenkins is just not architected for large, multi-project deployments, isolated environments and specialized nodes. It can work if you do not need these features, but otherwise it's fight against the environment.

      You need a beefy master and it is your single point of failure. Untimely triggers of heavy jobs overwhelm controller? All projects are down. Jobs need to be carefully crafted to be resumable at all.

      Heavy reliance on master means that even sending out webhooks on stage status changes is extremely error prone.

      When your jobs require certain tools to be available you are expected to package those as part of agent deployment as Jenkins relies on host tools. In reality you end up rolling your own tool management system that every job has to call in some canonical manner.

      There is no built in way to isolate environments. You can harden the system a bit with various ACLs, but in the end if you either have to trust projects or build up and maintain infrastructures for different projects isolated at host level.

      In cases when time-wise significant processing happens externally, you have to block an executor.

      Reply View 0 replies
    • bionsystem 2 days ago

      Yeah I was thinking of using it for us actually. Connects to everything, lots of plugins, etc. I wonder what the hate is from, they are all pretty bad aren't they ?

      Will test forgejo's CI first as we'll use the repo anyway, but if it ain't for me, it's going to be jenkins I assume.

      Reply View 4 replies
      • n4bz0r 2 days ago

        Cons:

          - DSL is harder to get into.
  - Hard to reproduce a setup unless builds are in DSL and Jenkins itself is in a fixed version container with everything stored in easily transferable bind volumes; config export/import isn't straightforward.
  - Builds tend to break in a really weird way when something (even external things like Gitea) updates.
  - I've had my setup broken once after updating Jenkins and not being able to update the plugins to match the newer Jenkins version.
  - Reliance on system packages instead of containerized build environment out of the box.
  - Heavier on resources than some of the alternatives.
        Pros:

          - GUI is getting prettier lately for some reason.
  - Great extendability via plugins.
  - A known tool for many.
  - Can mostly be configured via GUI, including build jobs, which helps to get around things at first (but leads into the reproducibility trap later on).
        Wouldn't say there is a lot of hate, but there are some pain points compared to managed Gitlab. Using managed Gitlab/Github is simply the easiest option.

        Setting up your own Gitlab instance + Runners with rootless containers is not without quirks, too.

        Reply View 3 replies