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

The Pain That Is GitHub Actions

feldera.com

Post reply on HN
Print view View original

121–130 of 584 posts

Re: The Pain That Is GitHub Actions

#121

Post by kelseydh »

carderne wrote: post #104
kelseydh wrote: post #30

We recently had a developer -- while trying to debug container builds for a version upgrade for a PR on their local branch -- accidentally trigger a deployment of their local branch's docker container to production (!) while messing around with Github action workflow files in their pull request (not main). Outside of locking down edit access to the .github workflow yml files I'm not sure how vulnerabilities like this…

Your prod deployment should require access to some secrets that are only available to workflows running against main.

I'm interested in learning more about this. How would we go about adding a secret only available to runners on the main branch? Is there a configuration option on Github to create a secret only available to runners on main?

Presumably anything configured via a .github workflow wouldn't assure safety, as those files can be edited to trigger unexpected actions like deploys on working branches. Our Github Action workflow yml file had a check to only deploy for changes to the main branch. The deploy got triggered because that check got removed from the workflow file in a commit on a working branch.

Re: The Pain That Is GitHub Actions

#122

Post by ozim »

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

Good insight, because that is just a complex issue - especially when there is team churn and everyone adds their parts in yaml or configuration.

Doesn’t matter Jenkins or actions - it is just complicated. Making it simpler is on devs/ops not the tool.

Re: The Pain That Is GitHub Actions

#123

Post by ed_mercer »

jicea wrote: post #33

Genuine question: what's the GitLab equivalent of GitHub Actions? I'm using GitHub Actions to easily reuse some predefined job setup (like installing a certain Python version on Linux, macOS, Windows runners). For these tyoe of tasks, I find GitHub actions very useful and convenient. If you want to reuse predefined jobs, written by someone else, with GitLab CI/CD, what can I use?

Kaniko + base container images

Re: The Pain That Is GitHub Actions

#124

Post by gazereth »

hn_throwaway_99 wrote: post #19

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I used GitHub actions when building a fin services app, so I absolutely used the hash to specify Action dependencies. I agree that this should be the default, or even the required, way to pull in Action dependencies, but saying "almost no one doe…

Pinning dependencies is trading one problem for another.

Yes, your builds will work as expected for a stretch of time, but that period will come to an end, eventually.

Then one day you will be forced to update those pinned dependencies and you might find yourself having to upgrade through several major versions, with breaking changes and knock-on effects to the rest of your pipelines.

Allowing rolling updates to dependencies helps keep these maintenance tasks small and manageable across the lifetime of the software.

Re: The Pain That Is GitHub Actions

#125

Post by baq »

pinkgolem wrote: post #84
mubou wrote: post #77

Earlier quoted context omitted.

Devil's advocate: They could make the github CLI capable of doing all of those things (if it's not already), and then the only thing the container needs is a token.

There are multiple ways you can do this already from within a script

Ah, the Dropbox comment.

> For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

Re: The Pain That Is GitHub Actions

#126

Post by ozim »

ehansdais wrote: post #111
deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

After years of trial and error our team has come to the same conclusion. I know some people might consider this insanity, but we actually run all of our scripts as a separate C# CLI application (The main application is a C# web server). Effectively no bash scripts, except as the entry point here and there. The build step and passing the executable around is a small price to pay for the gain in static type checking, b…

I don’t think it is insanity quite the opposite - insanity is trying to force everything in yaml or pipeline.

I have seen people doing absolutely insane setups because they thought they have to do it in yaml and pipeline and there is absolutely no other option or it is somehow wrong to drop some stuff to code.

Re: The Pain That Is GitHub Actions

#127

Post by quantadev »

GitHub Actions is just a way to build a remote single point of failure into your pipeline. I don't get why people do this. If GitHub goes down, or has problems for whatever reasons it can interfere with your deliverables to customers. I learned early in my career not to trust 3rd parties as any part of any mission critical process. 3rd parties will always fail you, it's just a matter of time.

Re: The Pain That Is GitHub Actions

#128

Post by qweiopqweiop »

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

Can you explain YAML? I've found declarative pipelines with it have been... fine?

Re: The Pain That Is GitHub Actions

#129

Post by baq »

gazereth wrote: post #124
hn_throwaway_99 wrote: post #19

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I used GitHub actions when building a fin services app, so I absolutely used the hash to specify Action dependencies. I agree that this should be the default, or even the required, way to pull in Action dependencies, but saying "almost no one doe…

Pinning dependencies is trading one problem for another. Yes, your builds will work as expected for a stretch of time, but that period will come to an end, eventually. Then one day you will be forced to update those pinned dependencies and you might find yourself having to upgrade through several major versions, with breaking changes and knock-on effects to the rest of your pipelines. Allowing rolling updates to depe…

Not pinning dependencies is an existential risk to the business. Yes it’s a tradeoff, you must assign a probability of any dependency being hijacked in your timeframe yourself, but it is not zero.

Re: The Pain That Is GitHub Actions

#130

Post by robinwassen »

ehansdais wrote: post #111
deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

After years of trial and error our team has come to the same conclusion. I know some people might consider this insanity, but we actually run all of our scripts as a separate C# CLI application (The main application is a C# web server). Effectively no bash scripts, except as the entry point here and there. The build step and passing the executable around is a small price to pay for the gain in static type checking, b…

Did a similar thing when we needed to do complex operations towards aws.

Instead of wrapping the aws cli command I wrote small Go applications using the boto3 library.

Removed the headaches when passing in complex params, parsing output and and also made the logic portable as we need to do the builds on different platforms (Windows, Linux and macOS).

Post reply on HN