Live data from Hacker News

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

github.blog

161–170 of 239 posts

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

#161
post #48

I do not understand why Microsoft finances this. I understand the hosting as a specialized social platform, but GitHub Actions vs. Azure DevOps Pipelines are a duplicated effort. Better integration for GitHub for the Azure DevOps suite would solve that in a similar way without duplication of capabilities.

I think (hope) they intentionally avoid tight integration with Microsoft branded stuff. Even at the slightest indication of such a thing happening, I bet it would lead to an exodus and outrage among developers, however irrational that might be.

Yeah... That is a reason I could imagine. Also the lack of hype in pipelines.

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

#162
post #83
post #2

This is great news for developers. The trend has been to combine version control and CI for years now. For a timeline see https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-c... This is bad news for the CI providers that depend on GitHub, in particular CircleCI. Luckily for them (or maybe they saw this coming) they recently raised a series D https://circleci.com/blog/we-raised-a-56m-series-d-what-s-ne... and…

It's a horrible trend. CI should not be tied to version control. I mean we all have to deal with it now, but I'd much rather have my CI agnostic and not have config files for it checked into the repo. I've browsed through the article you linked to, one of the subtitles was "Realizing the future of DevOps is a single application". Also a horrible idea: I think it locks developers into a certain workflow which is hard…

I 100% agree and am building https://boxci.dev to solve this problem for myself and I hope others too.

It's a CI service that lets you run your builds however you want, on any machine you want (cloud vm; in house server; your laptop) using an open source cli that just wraps any shell script/command and streams the logs to a service to give you all the useful stuff like build history, team account management, etc.

In other words, how you configure and run your builds will be up to you - scripts in the same repo, in another repo, in no repo - whatever you want, since you could just git clone or otherwise copy the source from wherever it is - there's no 1-1 relationship between the source repo and the CI, unless you want that. It'll be launching very soon :-)

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

#163
post #145

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…

Now that you mention it maps hasn't really improved since streetview. Search is worse. Gmail hasn't really changed much. I guess after it's launched new features are too difficult to add for google.

What? All of these products probably have a miles long changelog.

I mean, I can assume you don't care for the change, but it's there. Streetview was launched in 2007.

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

#164
post #113

Earlier quoted context omitted.

In my experience maintaining an active project at a large enterprise, these kinds of things happen nearly daily. Sometimes I wake up and our EMEA team has merged in a change that requires a CI change as well, and they are able to self-service those through their PRs.

I'll give you a counter example: whenever I change CI workflow for something that has nothing to do with the repo - like a new deployment scheme to staging - I have to go and ask people to merge/rebase from master into their branches or they won't be able to deploy. It happens pretty often and I'd rather avoid this.

To fix this problem you can set up you CI server to merge into the base branch automatically before running the code (in fact you should probably do this by default for other reasons).

This way your devs won't have to merge, they can just rerun their tests, which should be the same workflow as if your CI config is separate from your codebase.

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

#165

Earlier quoted context omitted.

Thanks! I'm not sure if for large open source projects, these machines will be nearly enough to run the CI jobs. The price for Linux seems quite steep when you compare with for example what you pay with GCP. It will be interesting to see the Github security teams catching those "public" repos doing nasty stuff like mining crypto - even with hard timeouts on each job it will be cool to see how this plays out!

For large open source projects it's free. Over time I can see them expanding their feature set including more powerful machines.

I didn't mean about the costs for large OS projects but on the requirements. As an example, in my experience, I couldn't build the `semantic` project (https://github.com/github/semantic) with those requirements.

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

#166
post #82
post #77

Earlier quoted context omitted.

Sure, if your site is solely static content, which is all GitHub pages supports. You can’t run “production code”. I know some people use the service with a static site generator as a free way to host a blog, but it’s not really the same thing at all.

Works pretty good for blogs and in general if you use serverless tech. However i wouldn't consider it for mission critical stuff - github's infrastructure can't be compared to actual paid-for cloud hosting.

> github's infrastructure can't be compared to actual paid-for cloud hosting.

I think the idea in this thread is that since github is owned by MS, and they have Azure, that won't be an accurate statement for very long. Github doesn't have to build that infrastructure, they just need to competently integrate into MS existing infrastructure.

I can't believe I didn't piece this together sooner but I agree with this threads premise. I'm already hosting my source on Github so why not build it there? And if I'm building it there then why not deploy it there? Rather than manage a complicated pipeline, I just `git push` and everything else just works ... all the way to massive scale.

As someone who has worked on hand-built github to AWS pipelines ... I can actually see this being the killer feature Azure needs to actually win a large market share.

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

#167

This is very interesting to me. It also makes me think about the natural rise of monopolies and monoculture in tech. GitHub has really been extending to "eating the world" as of late. Recently in terms of their package registry that must have folks like Artifactory and Nexus a bit shaken, and now this, which is bad news for folks like CircleCI (and I say this as a CircleCI user). As a developer, in the short term I l…

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 that TravisCI has nailed

2. basic functionality, like triggering a notification on Gitter via a simple HTTP hook when the build has finished, does not work

I do love CircleCI for our work project, as it doesn't need a build matrix or notifications to Gitter and thus was fairly easy to setup.

But I also love to see some competition for my public projects.

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

#168
I've been on the beta for a while, and while it was understandably limited, I really enjoy it and have done a lot with it. I'm excited about the announcement because it appears that a lot more can be done now.

However, it's not clear what happens to existing actions and workflows. Do they just stop working? Can actions still be made from a dockerfile and entrypoint script?

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

#169
post #168

I've been on the beta for a while, and while it was understandably limited, I really enjoy it and have done a lot with it. I'm excited about the announcement because it appears that a lot more can be done now. However, it's not clear what happens to existing actions and workflows. Do they just stop working? Can actions still be made from a dockerfile and entrypoint script?

See -

https://twitter.com/gimenete/status/1159521518403145728?s=20

https://help.github.com/en/articles/migrating-github-actions...

Already used the "migrate-actions" binary on a few projects, and while I don't have the new version enabled (you'll get a notification when the repo is available for an upgrade), this is better in terms of simplicity since you don't have to manage action references or the "resolves" field (when you were manually editing the hcl).

The only downgrade is that it doesn't look like you can run actions in parallel within the same "job"; so you can't have eg. "cd project1 -> npm i" and "cd project2 -> npm i" running at the same time and then have a third action that can use the output/filesytem of both of those commmands. Now the "job" will run one, wait for completion, then run the other, then you can have an action that uses the changes of those.

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

#170

I remain incredibly happy with Semaphore CI and don't see this as a value improvement.

I don't love the yaml of its 2.0 version. The visual build steps is horribly horizontal (why not just wrap it vertically?).
Post reply on HN