GitHub Actions could be so much better • Hacker News Board

Re: GitHub Actions could be so much better

#51

Post by evntdrvn » Fri, Sep 22, 2023, 4:32 PM UTC

woodruffw wrote: post #44

Pxtl wrote: post #39

Earlier quoted context omitted.

They share a lot of code. My understanding is that it was an MS project first, but I might have that backwards. > GitHub Workflows execute on runners. The runner code is essentially a fork of the Azure Pipelines code, so it's very similar. It's also cross-platform and you can also use hosted or self-hosted runners. https://learn.microsoft.com/en-us/dotnet/architecture/devops...

Thanks for the link -- I knew that GHA workflow runs ran on Azure, but I didn't know the workflow runner itself was a fork of Azure's runner/instrumentor. That's interesting context!

if you look at the source of the GHA runner, you can see where they regex-replace all references to Azure Pipelines with GitHub Actions lol

Re: GitHub Actions could be so much better

#52

Post by taeric » Fri, Sep 22, 2023, 4:34 PM UTC

ramraj07 wrote: post #47

taeric wrote: post #35

Earlier quoted context omitted.

I'm actually confused and scared on how often this isn't the case? What are people doing in their actions that isn't easily doable locally?

All the linting checks and end to end tests I don’t want to bother setting up locally for every repo I touch.

Aren't these just other targets in whatever build system you are using, though?

Re: GitHub Actions could be so much better

#53

Post by bastardoperator » Fri, Sep 22, 2023, 4:34 PM UTC

simse wrote: post #21

A linter can catch some obvious errors: https://github.com/rhysd/actionlint . But yes, I agree, it's not a fun debugging experience.

act would also be helpful here in terms of debugging and development of Actions workflows.

https://github.com/nektos/act

Re: GitHub Actions could be so much better

#54

Post by taeric » Fri, Sep 22, 2023, 4:35 PM UTC

ghayes wrote: post #40

taeric wrote: post #35

Earlier quoted context omitted.

I'm actually confused and scared on how often this isn't the case? What are people doing in their actions that isn't easily doable locally?

A huge portion of my actions are for things like caching or publishing artifacts, which are unique to actions itself.

I'd assume you would be able to publish and deploy locally before setting up actions. Such that those are likely targets in your build system?

Caching, I can mostly understand as unique there. Though, I think I'm living with whatever the default stuff in actions is. Slow for builds that don't happen often, of course, but not so slow that I care.

Re: GitHub Actions could be so much better

#55

Post by sitzkrieg » Fri, Sep 22, 2023, 4:36 PM UTC

one thing to be aware of, if you use windows, and submodules in a repo, ci will fail to clone over 50% of the time (with internal retries) with early eof errors

it's apparently a fixed problem in upstream openssl beta that isnt bundled yet, but i think a custom runner would be better too (but not an option at my org)

still, some days it gets in a rut and quickly fails for 10+ runs all billed at full rate. the entire eng group is severely annoyed by it because we cross test all oses on each commit so its becoming an expensive problem. basically 3x the billing on windows ci

Re: GitHub Actions could be so much better

#56

Post by ZeWaka » Fri, Sep 22, 2023, 4:38 PM UTC

re: `pull_request_target` and fork PRs - You can get around the !Even More Fun! limitations this has (GITHUB_TOKEN being read-only) by having a workflow called by another workflow.

For example, I wrote a set of workflows[1] to automatically apply a label after 2 'review approvals'.

First, a 'dummy' workflow triggering off PRs (in that context) that uploads an artifact: the PR number

Second, the 'real' workflow that runs in the context of the actual repository, set to be `on: workflow_run: workflows: - Final Review Labeler` - this pulls in the artifact, runs a GraphQL query, and applies the label if applicable.

[1]: https://github.com/goonstation/goonstation/blob/master/.gith...

Re: GitHub Actions could be so much better

#57

Post by giobox » Fri, Sep 22, 2023, 4:39 PM UTC

My personal wish is for the ability to attach HTML reports the the action runs without having to use the current actions/upload-artifact etc.

Particularly for test builds, I very often just want to quickly view the output HTML report. The current approaches I am familiar with are the aforementioned upload-artifact, or using GH pages, but GH pages is not great when you have multiple different reporting output for the same repo, or you wanna quickly view historical reporting rather than latest.

I'd love a simple "attach-report" action that just put a link to an HTML report on the job summary, and clicking on it renders the html.

Other automated CI/CD style systems have much richer support out of the box for dealing with HTML report capturing and viewing.

Re: GitHub Actions could be so much better

#58

Post by ZeWaka » Fri, Sep 22, 2023, 4:40 PM UTC

baq wrote: post #41

taeric wrote: post #35

Earlier quoted context omitted.

I'm actually confused and scared on how often this isn't the case? What are people doing in their actions that isn't easily doable locally?

It's the cloud. Runners are ephemeral (pretend, but still) with no persistent storage. This makes you either rebuild everything in every release stage (bad) or put artifacts in s3 or whatever (also bad) - this is especially painful for intermediate artifacts like dependency bundle caches etc. As much as I like make it just doesn't work with the typical cloud stateless by default configs. If it works for you, your pro…

> with no persistent storage

There's https://github.com/actions/cache though?

Re: GitHub Actions could be so much better

#59

Post by andix » Fri, Sep 22, 2023, 4:41 PM UTC

I'm really not sure if we are using CI correctly. Sometime i think all those CI Templates should be replaced by just one executable that does everything, like a modern alternative to Makefiles (and there are a lot of build tools).

So the CI pipeline would only call the build tool, like "./build containers push-to-registry release:1.0.0 run-tests"

Those scripts can be tested and debugged everywhere. Also migrating to a different CI platform would be really easy.

Re: GitHub Actions could be so much better

#60

Post by MenhirMike » Fri, Sep 22, 2023, 4:41 PM UTC

MoreQARespect wrote: post #24

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

Option 2 also makes it easier for developers to run their builds locally, so you're essentially using the same build chain for local debugging than you do for your Test/Staging/Prod environments, instead of maintaining two different build processes.

It's not just true for GHA, but for any build server really: The build server should be a script runner that adds history, artifact management, and permissions/auditing, but should delegate the actual build process to the repository it's building.