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

GitHub Actions now supports CI/CD, free for public repositories

github.blog

Post reply on HN
Print view View original

221–230 of 239 posts

Re: GitHub Actions now supports CI/CD, free for public repositories

#221

Post by dmix »

johnday wrote: post #191
hn_throwaway_99 wrote: post #127

Earlier quoted context omitted.

> A monopoly is not inherently bad. They often benefit users with increased efficiency and productivity. They're only bad when progress stagnates and/or prices rise. My argument is every single monopoly eventually becomes 'bad' and makes progress stagnate and prices rise . Just look at Google and Amazon. Up until I'd say late-ish 00s, nearly everyone loved Google and Amazon. I remember when Google search, GMail, Maps…

I hate to point this out on HN but it does seem relevant. If you dislike Google's use of ads, why not block them? I think you've acknowledged that Google and Amazon provide the best services of their respective classes. Can we find a way to maintain that high standard without the crud that comes with it?

I'm still not convinced someone couldn't build a better gmail.

The web app is bloated and slow. The ads. The awkward design. Privacy issues. There's a bunch of benefits someone could offer. Fastmail tried but I still think it could be better and not based in Australia where privacy has been eroded.

The barrier to entry for doing categorization, spam detection, search, autosuggestions, and even complex JS frontends is significantly lower than it's ever been. You could even offload some of the above challenges to the client with prepackaged ML models. The spam filtering stuff could even be open sourced and community run like Adblockers. Abuse could still be handled server side.

Re: GitHub Actions now supports CI/CD, free for public repositories

#222

Post by oefrha »

skissane wrote: post #213
elevenbits wrote: post #196

Earlier quoted context omitted.

The point I think is that as GitHub adds more and more integrations (git + issues + fork graph + CI/CI + ...) then it's not so simple to move to another service. The vertical is more convenient until you realize you're an Oracle customer all over again.

With CI, I wonder if someone could build a tool which had some sort of DSL to define your CI pipeline, and then translated that to configuration files for multiple CI providers (Travis CI, CircleCI, GitHub Actions, Jenkins, etc.) If you write all your CI pipelines in that DSL, then moving to another provider would be just telling the tool to generate output for another backend. (One issue is that such a DSL could onl…

Having migrated from Travis to CircleCI for most of my active projects, I’d say their models are so vastly different it’s pretty much impossible to have an AST of sort that can be translated to both except for the simplest and most well-encapsulated cases (at least not before Travis supposedly improved Docker support, by which point I was already gone).

Re: GitHub Actions now supports CI/CD, free for public repositories

#223

Post by _frkl »

alkonaut wrote: post #192
_frkl wrote: post #75

Earlier quoted context omitted.

What would you like instead? Personally, for those type of things I never thought yaml was limiting in any way, but would be keen to hear what better options you think are out there. I like the simplicity and readability of yaml, as long as there's not too much logic to be expressed.

I think the future is that all configuration is code. Code in a proper functional/imperative language (preferably the one you wrote the app code in), rather than a special declarative language. The attraction of toml is minimalistic and simple definitions initially - but there is always too much logic for these languages. If not immediately, then eventually. "Real" programming languages have good compilers, good erro…

Yeah, I know pulumi, and I'm working on something similar myself. Personally, in my experience, I don't think there's always too much logic, far from it.

A lot of times you really only have a list of tasks that are executed one by one, and the nature of that doesn't really change. I think it's overkill to introduce a new wrapping layer in those cases (and that is what Pulumi really is, it mostly just wraps Terraform if I understand right). But yes, sometimes it's better to have 'real' code at your disposal. It's just a matter to know when's when. Like always :-)

Also, debugging those yaml problems or real code doesn't really seem to make a difference for me. It's both equally annoying, and since there is a 'declarative' layer involved most of the time anyway, just a bit deeper down, debugging the 'real' issues (not typos and such -- btw. check out yamllint if you don't know it) is not any easier with wrappers like Pulumi. But maybe we have just worked on different type of complexities in our pasts. That usually explains different preferences for tooling. Just saying that this is not a thing we should/can generalize.

Re: GitHub Actions now supports CI/CD, free for public repositories

#224

Post by _frkl »

symlinkk wrote: post #195
_frkl wrote: post #75

Earlier quoted context omitted.

What would you like instead? Personally, for those type of things I never thought yaml was limiting in any way, but would be keen to hear what better options you think are out there. I like the simplicity and readability of yaml, as long as there's not too much logic to be expressed.

JSON

Well then, that settles it...

Re: GitHub Actions now supports CI/CD, free for public repositories

#225

Post by davnicwil »

weberc2 wrote: post #208
bad_user wrote: post #167

Earlier quoted context omitted.

CircleCI is fine for the private repositories of work projects, but not for public libraries. In trying to migrate a fairly popular open source library I maintain to CircleCI, from TravisCI, I bumped in the following two problems: 1. setting up a build matrix with various configurations (JVM version, compiler version, coverage on or off, etc) is a pain in the ass (possible, but a pain nonetheless), a configuration th…

We’ve had to build a lot on. Like support for passing state across jobs in a workflow, or branching, or triggering a workflow with parameters, or triggering a workflow from a different branch, or etc. CCI went to unnecessary lengths to not support obvious use cases, or that’s how it feels. :(

I've been there and spent hours if not days shaping builds and using workarounds/hacks to fit the esoteric manner in which CI services need your builds to run (setting up the build pipeline as a series of containers but without easily accessible persistent storage between the containers seems to be the current popular model - which is the case because it's very easy for a service provider to provide and manage the compute this way but pushes all the work onto you instead to get it working).

This problem is what I'm trying to solve with https://boxci.dev for myself and hopefully others too. The idea is it'll do all the management stuff that a CI service should do, but let you run the actual builds however and wherever you like, on your own machines, using an open-source cli. Check it out, perhaps you'll find it useful. It's launching very soon!

Re: GitHub Actions now supports CI/CD, free for public repositories

#226

Post by httgp »

bamboozled wrote: post #190

Just a warning for those who haven't ventured into actions yet, I would have to say so far I've found the experience very, very average. Even just doing something simple like posting a release notification to Slack seems to end up with me having the action triggered a random number of times causing multiple messages being posted to slack. The whole experience feels amateur and clunky. There are issues open to look in…

Good point. This could very easily lead to the same problems plaguing the NPM ecosystem — an action repo could be sold to a malicious actor, giving them full access to your entire codebase!

Re: GitHub Actions now supports CI/CD, free for public repositories

#228

Post by pushpop »

manigandham wrote: post #178
hn_throwaway_99 wrote: post #153

Earlier quoted context omitted.

Huh? MS is the perfect example of how monopolies cause things to stagnate. It was only when new technology paradigms allowed for the growth of companies like Google and Amazon (wrt AWS) did MS turn around. IE stagnated for years after MS killed Netscape. No company has really ever challenged Windows on desktop PCs. It was only when new platforms like the Internet and mobile computing came along that provided space fo…

Sure, but that's the example of monopolies facing competition when they turn bad. Sometimes that takes a new platform shift, other times its just a better product, but either way if there's new value then the monopoly breaks down. I think if anything, the problem today is companies that could be challengers just end up selling to the very incumbent they're competing against.

In the instances you’ve described where “monopolies” haven’t dominated the market, they were not actually monopolies because they didn’t have total ownership of the market.

A company can be a tech giant and still not be classed as a monopoly. Which are the kind of examples you’re think of.

Re: GitHub Actions now supports CI/CD, free for public repositories

#229

Post by bob1029 »

bamboozled wrote: post #190

Just a warning for those who haven't ventured into actions yet, I would have to say so far I've found the experience very, very average. Even just doing something simple like posting a release notification to Slack seems to end up with me having the action triggered a random number of times causing multiple messages being posted to slack. The whole experience feels amateur and clunky. There are issues open to look in…

This feature release has been a dumpster fire from my perspective. I love GitHub and what they are trying to do, but I read over the Actions documentation 2x and I still can't tell if my use case is supported: I just want to see if master builds on a net core app without spinning up or otherwise utilizing some other cloud instance.

Also, I am not even sure what the appropriate syntax to use is with all the mixed messaging and examples (YAML or the other thing? Which do I use!?).

Regardless of which variant of syntax I attempted, the actions UI told me there was some generic error and that nothing was to be done. One additional problem I noticed is that if you have a protected master branch, you are going to be forced to get code reviews from your team every single time you try to iterate on the workflow script. There is no apparent way to test or validate actions without committing directly to master and seeing what the result may be.

All around, a complete mess in my estimation. I will be sticking with Jenkins for the foreseeable future. This GH feature is apparently not designed for people who care about straightforward solutions to simple problems:

  git clone 
  dotnet build
That is all I want to do, Microsoft. Can you handle that? I feel like there should just be a simple toggle switch in my GH repo for this concern, considering Microsoft is now responsible for that entire vertical stack.
Post reply on HN