[flagged]
We use GitHub Actions to build GitHub
91–98 of 98 posts
Re: We use GitHub Actions to build GitHub
#92[dead]
Re: We use GitHub Actions to build GitHub
#93" Turn weekly team photos into GIFs and upload to README" Well, as a remote worker that has my camera off as much as possible out of principle I'd really hate this. It actually puts me off applying knowing glimpses of my home get turned into GIFs for the entire company to see.
No post body was provided.
Re: We use GitHub Actions to build GitHub
#94Earlier quoted context omitted.
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.
Stack Exchange (and by extension, Stack Overflow) publishes all their data (anonymized) for download and offline usage as part of the Archive.org project. If you wanted, you too could have a copy of it locally to search while the site is down.
Re: We use GitHub Actions to build GitHub
#95Earlier quoted context omitted.
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 op…
Just looked at CircleCI recently. Great product, but the price difference between them and GHA was absolutely jaw dropping.
Re: We use GitHub Actions to build GitHub
#96Earlier quoted context omitted.
> 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 generally hate this type of thing: retry mechanisms are a lazy band-aid that can mask real problems. 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 c…
> 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.
Actually good point, and I agree. I didn't state that well. What I was thinking of was some other things in builds I've seen retries be the band-aid for: flaky, timing-based unit tests; locked files/directories; or applying database migrations. My usual reaction to adding a retry to a build step is "no, let's fix the actual problem". Network requests to external services are a special case though, and absolutely should always have retries.
Re: We use GitHub Actions to build GitHub
#97Earlier 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.
> This is why UI is hard. Is it though?. I mean, pretty much all mainstream CICD services do this right out of the box. GitLab does this so well it's even totally transparent and never an issue. How come GitHub actions, which succeeded all of its alternatives, managed to turn a solved problem into a constant source of headaches?
have you ever seen a simple microsoft product?
Re: We use GitHub Actions to build GitHub
#98I wish GitHub Actions worked more like Drone. Just run commands in specified Docker containers. None of this weird probably dangerous in-channel signaling via STDOUT. Completely skip the base level OS with a billion tools people might want pre installed that shifts over time, that’s just asking for your build to break while you’re on vacation. It’s a very Microsoft way to do it. It’s messy. I know GitHub Actions has…
What did happen with Drone? Haven't heard much about it recently, now that I think about it.