Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions Pitfalls

fusectore.dev

Post reply on HN
Print view View original

11–20 of 111 posts

Re: GitHub Actions Pitfalls

#11

Post by franky47 »

ryan-duve wrote: post #4

I've used Github Actions at work for the past year and I'm a fan overall. The clearest sign of this is my feedback for improvement is almost entirely about missing features instead of broken ones. For examples, it'd be nice: 1. for Github to natively allow CI management for several repos in a centralized way, so repo setup can just be "select this CI config" instead of "copy this YAML file and change the project name…

Looks like there is a solution for #1: https://docs.github.com/en/actions/using-workflows/reusing-w...

I haven't tried it yet though.

Re: GitHub Actions Pitfalls

#13

Post by yebyen »

darthcloud wrote: post #8

The most annoying thing for me is that a workflow_dispatch only workflow can't be launch manually until it's push into default branch as they are not listed. I can understand the Web-UI won't list them but even GitHub cli can't launch them. Once they appear in the default branch, only then you are free to launch them on any branch.

There's something in here I don't understand, and I thought I knew the reason why it does this (for at least some workflow types, maybe not workflow_dispatch)

If you're only free to run those workflows when they land in the default branch, does that also mean that the workflow that runs is the one from the default branch and if you change the workflow in a PR, it will only run the new workflow on merge?

I know there's something in here to permit non-owned commits (from an external contributor) to be tested against a trusted workflow from the main branch, but I don't think it has anything to do with workflow_dispatch. I would expect that if you're able to run workflows and target any branch, then if the workflow you run is the one contained in that branch, you'd be able to select any workflow that is named and defined in the branch's configuration.

I'm not saying that's how it works, I'm saying that's how I'd imagine it to work. If someone knows "the rule" that we can use to disambiguate this and understand it from the precepts that went into the design, maybe speak up here? I don't get it.

Re: GitHub Actions Pitfalls

#14

Post by xvello »

darthcloud wrote: post #8

The most annoying thing for me is that a workflow_dispatch only workflow can't be launch manually until it's push into default branch as they are not listed. I can understand the Web-UI won't list them but even GitHub cli can't launch them. Once they appear in the default branch, only then you are free to launch them on any branch.

Agreed. The workaround my team uses is to first merge an empty action with the right parameters set, then open a second branch to implement the action steps. Once the action hits main, you can start it, using the definition from any branch.

Re: GitHub Actions Pitfalls

#16

Post by pydry »

The biggest pitfall I see is people inadvertently making them "smart" which causes massive headaches when debugging them.

As much intelligence as possible ought to be pushed down to and tested and debugged on the script level so that you're left with little more than a linear sequence of 4-5 commands in your YAML.

The debugging tooling on github actions is, frankly, abysmal. You need a third party ngrok action to even run ssh.

Re: GitHub Actions Pitfalls

#17

Post by gscho »

Another pitfall I have encountered is the lack of a true ephemeral agent runner solution for running the actions runner agent in your own infrastructure. The way it works (the last time I checked) is when you register a worker as "ephemeral: true" it automatically deregisters itself from your runner pool and kills the agent process when a job is completed, but it is up to you to clean things up. This leads to somewhat hacky scripts to delete the compute instance after the agent process exits. There is also no officially supported kubernetes controller for creating ephemeral agents but the community created one [1] is often mistaken as an official github project.

- [1] https://github.com/actions-runner-controller/actions-runner-...

Re: GitHub Actions Pitfalls

#19

Post by judge2020 »

gscho wrote: post #17

Another pitfall I have encountered is the lack of a true ephemeral agent runner solution for running the actions runner agent in your own infrastructure. The way it works (the last time I checked) is when you register a worker as "ephemeral: true" it automatically deregisters itself from your runner pool and kills the agent process when a job is completed, but it is up to you to clean things up. This leads to somewha…

https://github.com/github/roadmap/issues/555 Would this fix anything?

Re: GitHub Actions Pitfalls

#20

Post by jrochkind1 »

ryan-duve wrote: post #4

I've used Github Actions at work for the past year and I'm a fan overall. The clearest sign of this is my feedback for improvement is almost entirely about missing features instead of broken ones. For examples, it'd be nice: 1. for Github to natively allow CI management for several repos in a centralized way, so repo setup can just be "select this CI config" instead of "copy this YAML file and change the project name…

Me, I looove that the actions config has to be in a file in the repo, so I know where to find it, and if I have read access to the repo, I have access to the config. (Don't even need to be logged into a GH acct, although I usually am).

If they allowed config to come from an internal setting not visible in repo, i'm sure repos I collaborate with would start using that feature, and I would not be able to find their Actions configs.

(I work mostly on open source, which may lead to different patterns of access and such).

Post reply on HN