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
We use GitHub Actions to build GitHub
71–80 of 98 posts
Re: We use GitHub Actions to build GitHub
#72GitHub 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…
FWIW, while the UI for re-running jobs used to be better, the result was a LOT worse as it would re-run all the jobs instead of just the failing ones, so I am still MUCH happier with the new flow ;P.
Re: We use GitHub Actions to build GitHub
#73In other news, Mercedes executives drive Mercedes cars.
Re: We use GitHub Actions to build GitHub
#74We switched to buddy.works[0] about a year ago and honestly it’s just been… smooth. The UI is just great, the wealth and breadth of options is ever increasing and all the basics like knowing what went wrong, restarting, debugging, duplicating etc just work as you’d expect. One of the few companies I can recommend. [0] https://buddy.works
Re: We use GitHub Actions to build GitHub
#75GitHub 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…
> because of some flakey third-party service I've started building in auto retries to the CI scripts for this type of thing, at least once it annoys me to a certain extent. The most glaring and unavoidable ones that come to mind across several projects are external certificate time stamping services. I generally hate this type of thing: retry mechanisms are a lazy band-aid that can mask real problems. But at the same…
I disagree. Retry mechanisms is mandatory for any network request. You cannot expect a message to travel across the globe on a wire without ever failing.
I would say the opposite: you must have a retry mechanism for all requests performed by your application; unless it’s acceptable to pass on this failure to the client (who will retry the request).
Re: We use GitHub Actions to build GitHub
#76Re: We use GitHub Actions to build GitHub
#77Re: We use GitHub Actions to build GitHub
#78Earlier quoted context omitted.
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
#79I love everything about GitHub Actions except that there’s no official tool to run them locally.
Additionally, I can't picture a rationale for this decision, coming from Github.
Re: We use GitHub Actions to build GitHub
#80GitHub 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…