Comment by embedding-shape

1 month ago

That the entire ecosystem seems to have moved to GitHub Actions is such a loss for productivity. I remember when CircleCI first launched, and you could "Rebuild with SSH" which gave you a bash command to connect to the running instance whenever you wanted, was such a no-brainer, and I'm sure why many of us ended up using CircleCI for years. Eventually CircleCI became too expensive, but I still thought that if other services learnt anything from CircleCI, it would be this single feature, because of the amount of hours it saved thousands of developers.

Lo and behold, when GitHub Actions first launched, that feature was nowhere to be seen, and I knew from that moment on that betting on GitHub Actions would be a mistake, if they didn't launch with such a table-stakes feature. Seems still Microsoft didn't get their thumb out, and wasting countless developer's time with this, sad state of affairs.

Thank you pbiggar for the time we got with CircleCI :) Here's to hoping we'll have CircleCI.V2 appearing at some point in the future, I just know it involves DAGs and "Rebuild with SSH" somehow :)

19 comments

embedding-shape

Reply
olafmol  1 month ago

We (CircleCI) are still there, and doing just fine :) Out of interest, what are you currently missing and what would those "essential" V2 features be? tnx for sharing your thoughts!

kevmo314  1 month ago

I am surprised Docker didn't launch into the CI market. Running a container build as CI seems like it would both be a boon for simplifying CI caching and also debugging since it's ~reproducible locally.

  • hobofan  1 month ago

    They _are_ in the CI market. Two of their products are the Docker Build Cloud and Testcontainers Cloud. IIRC Docker Hub also came with automated builds at some point (not sure if it still does).

    I do get your sentiment tough. For the position they are in, a CircleCI-like product would seem to be quite fitting.

    • kevmo314  1 month ago

      Wow you're right they are. Yeah, they could really use some improvement there.

      https://docs.docker.com/build-cloud/ci/

      This could've been a "change runs-on to be this" like all the other faster GHA startup products, but instead the way they set it up I would have to keep paying for GHA while also paying for their build cloud. No fun!

fyhn  1 month ago

I've gotten used to this essential feature too via Semaphore CI, and I just can't stand not being able to SSH into a GitHub Action. Debugging is so slow.

  • embedding-shape  1 month ago

    I've seen people spend something like 2 hours fixing something that can be fixed in minutes if you had a normal feedback cycle instead of the 5 minute "change > commit > push > wait > see results" feedback cycle GitHub Action forces people into. It's baffling until you realize Microsoft charges per usage, so why fix it? I guess the baffling part is how developers put up with it anyways.

    • Storment33  1 month ago

      Does not sound like a GitHub failure, sounds it is the company's failure. They haven't invested in the developer experience and they have developers who cannot run stuff locally and are having to push to CI in order to get feedback.

      8 replies →

ljm  1 month ago

Still using CircleCI. I do not love YAML at all, in fact I hate it because it's basically a 1980s text preprocessor on steroids and with dependency management. Too much logic applied to config that depends on implicit syntax and unintuitive significant whitespace.

I mean, I had an issue once where this broke the pipeline:

   key:
     - value 1
     - value 2

But this was fine:

    key:
    - value 1
    - value 2

Fuck that noise!

Otherwise it works just as good as it ever did and I don't miss Github Actions where every pipeline step is packaged into a dependency. I think Github has stagnated harder than CircleCI.

  • woodruffw  1 month ago

    > I mean, I had an issue once where this broke the pipeline:

    It seems fair to dislike YAML (I dislike it too), but I don't understand how this broke for you unless CircleCI (or whoever) isn't actually using a legal YAML parser.

        irb(main):009:0> YAML.load <<EOD
    irb(main):010:0" key:
    irb(main):011:0"  - value 1
    irb(main):012:0"  - value 2
    irb(main):013:0" EOD
    => {"key"=>["value 1", "value 2"]}
    irb(main):014:0> YAML.load <<EOD
    irb(main):015:0" key:
    irb(main):016:0" - value 1
    irb(main):017:0" - value 2
    irb(main):018:0" EOD
    => {"key"=>["value 1", "value 2"]}

    (This works for any number of leading spaces, so long as the spacing is consistent.)

  • jborean93  1 month ago

    There shouldn't be any difference between those two values. I'm not saying you are wrong and it didn't break but it's definitely surprising a parser would choke on that vs YAML itself being the problem.

    Don't get me wrong I can empathise with whitespace formatting being annoying and having both forms be valid just adds confusion it's just surprising to see this was the problem.