Live data from Hacker News

We use GitHub Actions to build GitHub

github.blog

61–70 of 98 posts

Re: We use GitHub Actions to build GitHub

#61

It's weird to me that GitHub doesn't have larger machines types available for actions yet. I don't want to bother with a self-hosted runner just to get more CPUs. They have much larger machines available for Codespaces - why not actions? I'm happy to pay for them.

Hey founder of BuildJet here, With BuildJet for GitHub Actions, you can get up to 64 vCPU as a GitHub Actions runner. We plug right into your existing setup and have a significantly higher per core performance compared to the native runner. Check us out here: https://buildjet.com/for-github-actions

Any arm64 resources in the works?

Re: We use GitHub Actions to build GitHub

#62

How does GitHub fix GitHub using GitHub when GitHub is down?

Maybe they use GitHub Enterprise Server to host internal repositories?

Huh, it just occurred to me that Stack Overflow would still have access to their own database and probably be able to run a copy of it locally.

If Stack Overflow went down, they'd still be able to check Stack Overflow to fix their issue.

Re: We use GitHub Actions to build GitHub

#63
I’m trying to love GitHub Actions, however, when builds and tests randomly fail on custom runners when they’re configured the exact same and there’s no option to debug, it becomes painstakingly frustrating. We’ve tried most of the big CIs, Travis/CircleCI/codeship- and while GH Actions integrates nicely with GitHub itself, it’s a far less superior product compared to its peers.

Re: We use GitHub Actions to build GitHub

#64
post #59

Earlier quoted context omitted.

Sure, but that's actually worse than useless for my use-case. Image this, you have an action that publishes your plan to your PR (#1 - it's a biggish feature). It gets merged and goes to approval. Then people happen. PR #2 is addressing a customer-facing bug so it gets fast-tracked and rammed through before PR #1. Suddenly PR #1 is silently invalid. It _should_ be rejected at this point but the whole point of CI/CD i…

specifically for your terraform example, wouldn't it make more sense to have the PR merged only when apply was successful? i'm not sure how well that can be represented in GH actions, but that would surely be the better option? you'll always risk some kind of race condition there, e.g. atlantis locks the project while something is planned but not applied to avoid such things from happening. this of course prevents ha…

This still can't use GHA to enforce any sort of integrity so it's kinda moot. I have some of my projects set up to deploy with CircleCI...which can give me the build, approve, apply (specifically the thing you approved) chain that I'm looking for (so there's no race condition). "Why not use CircleCI?" well i do, but if my company decides to cut costs, it may not survive the chopping block...so I'm looking at other options.

Re: We use GitHub Actions to build GitHub

#66

GitHub Actions has a lot of basic usability issues, none of which are fatal but all of which irritate me on a daily basis. Let's start with the first and simplest: Why did my build fail? You'd think this should be front and center. Yet, the UX is "click through a couple links, then wade through thousands of lines of log output". In practice this is "download the logs and grep them for text strings like FAILURE". The…

This is why UI is hard. In a parallel universe they made the re-run jobs button like you want, and there's some person at the top of the Hacker News comments in that universe making the complaint that it's too hard to tell what the buttons do, and that only the common path of rebuilding failed builds is easy and once you need to do something uncommon it becomes irritatingly complex.

I dunno. In my experience UI is hard because some PM decided to start switching everything around, citing some engagement metric that seems to go up, even though it's obvious to everybody that it's a bad idea at a human level.

Re: We use GitHub Actions to build GitHub

#67

I've used GitHub Actions quite extensively now, across infrastructure automation, Python CI/CD, and iOS CI/CD, and while not perfect, it's the best platform I've used for this stuff so far. Compared to Jenkins it needed far less maintenance. Compared to CircleCI it felt much easier to work with and to build reliable pipelines due to the locking primitives it provides, and compared to Semaphore I found it easier to un…

Thanks for the feedback! I'm one of the PMs for GitHub Actions, and I appreciate this. Thinking about Actions as a set of primitives that you can compose is very much how I think about the product (and I think the other PMs as well) so I'm glad that resonates. We're always welcome to feedback, and we're continuing to invest and improve on the product, so I'm hopeful that we can address the features that you're missin…

No post body was provided.

Re: We use GitHub Actions to build GitHub

#68

GitHub Actions has a lot of basic usability issues, none of which are fatal but all of which irritate me on a daily basis. Let's start with the first and simplest: Why did my build fail? You'd think this should be front and center. Yet, the UX is "click through a couple links, then wade through thousands of lines of log output". In practice this is "download the logs and grep them for text strings like FAILURE". The…

This is why UI is hard. In a parallel universe they made the re-run jobs button like you want, and there's some person at the top of the Hacker News comments in that universe making the complaint that it's too hard to tell what the buttons do, and that only the common path of rebuilding failed builds is easy and once you need to do something uncommon it becomes irritatingly complex.

I don't agree. I've used other CI platforms that get UX a lot more right.

Re: We use GitHub Actions to build GitHub

#70
If anyone at GHA is reading comments, could you pressure your upstream VM hosts to all allow ‘rr’ (Mozilla record and replay) usage? They must enable performance measurement counters (PMU), but it is game-changing to be able to use CI not only to detect issues, but also exactly reproduce rare bugs by simply downloading an exact replay of the exact steps that led to it. We currently use self-hosted buildkite and buildbot runners specifically because we can enable the required performance counters, and temporarily save every run as an rr file so any result can be reproduced locally and investigated.

To quote an old post by the program author for more specifics: https://news.ycombinator.com/item?id=23076703

Post reply on HN