Hacker News Reader

Comment by monster_truck | Hacker News Reader

Had these exact same thoughts while I was configuring a series of workflows and scripts to get around the multiple unjustified and longstanding restrictions on what things are allowed to happen when.

That sinking feeling when you search for how to do something and all of the top results are issues that were opened over a decade ago...

It is especially painful trying to use github to do anything useful at all after being spoiled by working exclusively from a locally hosted gitlab instance. I gave up on trying to get things to cache correctly after a few attempts of following their documentation, it's not like I'm paying for it.

Was also very surprised to see that the recommended/suggested default configuration that runs CodeQL had burned over 2600 minutes of actions in just a day of light use, nearly doubling the total I had from weeks of sustained heavy utilization. Who's paying for that??

View on HN

I'm baffled you can't clone internal/private repos with anything other than a developer PAT. They have a UI to share access for workflows, let cloning use that...

I use GitHub apps for this, it’s cumbersome but works.

SSH also works, but I’d love to be able to just use git-credential-oauth [0] like for any other repo.

[0]: https://github.com/hickford/git-credential-oauth

Use a GitHub app, that’s what it’s for.

what with actions/checkout@v4, hows that documented?

https://github.com/actions/checkout/issues/567#issuecomment-...

GH has a `permissions:` entry and this mechanism already for internal repo action sharing. And thousands of our dollars per month.

It used 1.8 days of time to run for a single day? I'm less curious about who's paying for it than who's _using _ it on your repo, because I can't even imagine having an average of almost two people scanning a codebase every single minute of the day.

Not the OP, but a poorly behaving repo can turn and burn for six hours on every PR, rather than the handful of minutes one would expect. It happens - but usually that sort of thing should be spotted and fixed. More often then not, something is trying to pull artifacts and timing out rather than it being a giant monorepo.

Have you looked at the default configuration? It runs any time there is a push to main.

2600 minutes still seems pretty high to me; even if every run took 10 minutes, that's 260 pushes! Even the busiest projects I've worked on have never merged triple-digit numbers of changes in a single day. It's hard for me to imagine seeing that level of activity outside of something like a monorepo with a lot of different projects in it or something with a huge number of external contributors, and I wouldn't have any expectation that the default configuration would make sense for me if I were managing a repo like that. Maybe I've just worked on smaller projects than the average developer, or I've just been in charge of creating new CI actions infrequently enough to be paranoid about what exactly would be happening, but I wouldn't even consider enabling something on a repo with that much traffic before spending a lot of time looking at the configurations.

I've been saying for years, GitHub Actions is alpha software.

Reply on news.ycombinator.com