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 love this. Fewer things I need to cobble together and worry about how to integrate. I mean, it's already the case that if GitHub goes down that my CircleCI jobs won't work, so having one company to yell at and monitor alone is a plus.
But long term it makes the competitive ecosystem much less robust. And as a startup employee, makes me feel how disrupting established platform competitors gets that much more difficult - even if you have a better product, it's hard to fight against the "platform" as they have more integrated points of value.
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.
In this case, Github is actively competing and adding features that helps all of their users. If that means that some other companies lose market share then it's just a sign that the value proposition has changed. I see no problem with this, it's how the market works.
As a .NET developer, this just smells like trying to rope in more people to Azure DevOps and then the Azure cloud. This is Microsoft's endgame. Everything they do is to win marketshare in the cloud.
I don't think it's an evil plan by any means, though, and their competition has been nothing but good for the ecosystem. Remember, they were evil about Windows because so many people didn't have any other real choice. They don't have a monopoly over the cloud, so they can't be bullies (and management is totally different now, too, probably as a result).
However on my very first impressions, the tools they're rolling out kind of look like Azure DevOps under the hood. There's a good chance they'll leave the github brand alone though and just make it better.
Personally, I've been happy working in the MS stack. They really want to earn the love and mindshare of developers.
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.
I think you’re conflating monopoly and vertical integration. GitHub is not abusing its power as the market leader just yet. What it is doing is what Apple has been for years: make its core product and other products work better together causing users who use one to want to use all the others.
Honestly, I think it's a good thing in general. Like you've said, being able to just do things here and cut out all of that wasted time spent connecting disparate services... I mean assuming they pull this off well, it will absolutely make things better for me personally.
That all being said, I'm not sure how the long run comes into play here? It's bad if we extrapolate a long run prediction where no one else innovates or creates something in this space. But in reality, someone's going to be annoyed by it, someone's going to start up a different solution, and whether it works or not...it'll be there. Whether it's a small startup or a big enterprise challenging - if there's market gains to be had from adding this, it'll get added.
Don't get me wrong, you're on point with a lot of things in tech. Monoculture and monopolies are becoming super "in-your-face" considering just how much control the FAANG companies have in influencing tech and the like. However, I do find it odd that a single feature release by a larger company results, more often in not, in much of HN community losing their minds over prospective world domination. (not you op, but just in general...granted similar outrage happens to small open source stuff just as much so maybe this point is moot).
As John Maynard Keynes put it, "In the long run we are all dead." But in the short run, this just seems like a super useful feature added to a super useful product that will just make things easier for all developers.
This is interesting to people viewing the events in isolation.
These happen routinely on a daily basis. And being in a strategically foundational position makes such moves straightforward.
In the developer tooling market, GitHub is foundational, obviously. So it naturally will expand, and can also easily do so.
And it was these moments I lament Google's inability to buy GitHub. All these stuff are just repeating Google has had for a decade, they would have been the perfect marriage but Google refuses to pay big money...
I think its seriously such a hard problem to solve in tech. Its so easy and beneficial even for customers if one company does everything. Github can (and does!) offer the most open, accessible, and integrated APIs possible for CI/CD to plug into. But, when Github builds it, its just another tab in your PR, which is much more convenient.
We use Jira for ticketing and Github for code storage, like many companies. We've had SOC2 auditors tell us that they'd prefer to see us on Bitbucket just because the integration with Jira is more seamless; it guarantees a much deeper audit trail to go from RFC in Confluence -> Ticket in Jira -> Code in Bitbucket -> Deploy in whateverthefuck atlassian does for CI/CD. They didn't dock us, certainly.
But they're not wrong! I agree with them entirely! There's a part of me that hates that monopolization of our stack into one company, but there's another part of me that's like "that auditability and integration is so nice, and we literally will never see it if we're using ten different SaaS providers for each thing". How do you rectify those competing viewpoints? I don't know if you can.
CircleCI invented many of their own problems. No API to trigger workflow runs and the only trigger “API” is pushing to a git branch. A horrible job-centric UI when all you really care about are workflows. Workflows that don’t let you express conditionality and assume all errors are fatal. A broken data model that confuses the same workflow on different branches with different workflows (no good way to figure out how long your PR workflow takes on average because each PR is it’s own workflow, for some reason). No good state management or data passing options. Hopefully they will sort those things out, but it feels like they went out of their way to build a thing with a crazy data model and triggers that are tightly coupled to github.
I would say that monocultures, monopolies, vertical integration, etc. are all really good at making a local maxima, but at the expense of making it harder to find things that might be better still. And... sincerely, they are good for local maxima. They have the mindshare, they have the money, they have everything they need to succeed, today. And then tomorrow will come and they'll be stuck. But that doesn't mean that they can't be good, just that costs have to be weighed.
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 are already looking to add support for more platforms. It is hard to depend on a marketplace when it starts competing with you, from planning (Waffle.io), to dependency scanning (Gemnasium acquired by us), to CI (Travis CI layoff where especially sad).
It is interesting that a lot of the things GitHub is shipping is already part of Azure DevOps https://docs.microsoft.com/en-us/azure/architecture/example-... The overlap between Azure DevOps and GitHub seems to increase instead of to be reduced. I wonder what the integration story is and what will happen to Azure DevOps.
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 to escape. You have an issue with your setup you can't figure out - happened to me with Gitlab CI - sorry, you're out of luck. Every application is different, DevOps processes is something to be carefully crafted for each particular case with many considerations: large/small company, platform, development cycle, people preferred workflow etc. What I like to do is to have small well tested parts constitute my devops. It's a bad idea to adopt something just because everyone is doing this.
To sum it up, code should be separate from testing, deployment etc. On our team, I make sure developers don't have to think about devops. They know how to deploy and test and they know the workflow and commands. But that's about it.
I don't think it's that bad for CircleCI. CircleCI's focus is CI/CD and it's highly unlikely GitHub is going to do it as well as them. It's hardly commoditized technology. Their current customers are already heavily integrated with them and their orbs offering is further solidifying that relationship. Also, GitHub is expanding the CI/CD market with Actions so competitors in this space are likely to benefit.
Furthermore:
- waffle.io was acquired and shutdown by the acquiree
- TravisCI was sold to a private equity firm and lost their way
I think a good strategy for Microsoft would be to reuse as much as possible CI/CD code from github in Azure devops. Azure devops probably doesn’t need to be as flexible as long as it is robust and just works. Github will probably be the place where experiments can happen.
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 into it but no fix in sight yet. While this announcement sounds useful, don't throw away your current CI/CD tooling which is probably a lot nicer to use.
Lastly I really dislike how pretty much any really useful actions are created and maintained by single people. There are just some actions I'd want to see be supported by GitHub, I don't wan to have to handover things like Slack access keys to a non-trusted third party to post messages.
Every time I try to use actions I'm surprised it was launched in it's current obscure, unpolished state.
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:
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.
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!
As a Gitlab user that's not strongly committed to the platform, this looks like a pretty interesting option.
Anyone have thoughts on how this compares to e.g. Google Cloud Builder in terms of functionality? Being integrated into the GH backend seems like a big perk, rather than having to use webhooks for everything.
One thing that's great about Gitlab is the Gitlab server/runner split, where you can run workers in your own VPC, but still use their hosted offering. This makes it easier to keep your deploy secrets (aka the keys to the kingdom) locked down, as they never leave your cloud provider.
People will think twice when investing the time & money in develop an app for the github marketplace as if it succeed, Github could just built the app inside their system. They bought PullPanda which was good for his creator because I think it was less expensive that build that themselves.
I can't help but feel a little worried about this. GitHub's UI has become a lot less coherent as they rapidly develop new functionality. The simplicity/focus was one of the main reasons I preferred it to GitLab. Blurring the line between the two makes it easier to imagine switching, not harder.
What have they “always” supported exactly? I’ve used GitHub for a long time, but I use it entirely as a git server and sometimes an issue tracker. That said, I’m pretty sure they didn’t support anything that even remotely resembles CI/CD back when I started using it.
I wonder what they'll offer for Github Enterprise. Especially for organisations that are using it on prem and would prefer not to use Azure for builds.
Really interesting. My project just migrated to Azure DevOps and I noticed that their configuration file looks really similar. My suspicion is that Azure DevOps is backing GitHub CI/CD.
Free CI/CD for repos public and private is one thing that makes Gitlab really attractive to me. If Github's is simple/sane enough I would probably consider that also.
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'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?
I also find the ability to process the logs with some other platform like Kibana to be a top feature; I suppose there will be apps on top of this soon enough to meet the demand.
Lots of comments here about what this means for CircleCI. Found it interesting that CircleCI's CEO has a testimonial in the "What our community is saying" at https://github.com/features/actions:
“CircleCI has been building a CI/CD platform since 2011, and GitHub has been a great partner. GitHub Actions is further validation that CI/CD is critical for the success of every software team. We believe that developers thrive in open, connected ecosystems, and we look forward to working with GitHub to lead the evolution of CI/CD.”
Jim Rose
CEO of CircleCI
I work for Codefresh a CI/CD solution for Kubernetes/Helm/Docker.
One of our main goals when creating Codefresh was to make plugins that are not tied to Codefresh itself. As a result we followed the obvious model with plugins where they are just docker images and nothing else.
We are very glad to see that Github actions follows the same model. This means that we instantly get all Github actions as possible Codefresh plugins (and the opposite).
I would be really happy if other CI companies follow suit so that eventually a central CI/CD plugin repository can be created for all competing solutions.
[+] [-] hn_throwaway_99|6 years ago|reply
As a developer, in the short term I love this. Fewer things I need to cobble together and worry about how to integrate. I mean, it's already the case that if GitHub goes down that my CircleCI jobs won't work, so having one company to yell at and monitor alone is a plus.
But long term it makes the competitive ecosystem much less robust. And as a startup employee, makes me feel how disrupting established platform competitors gets that much more difficult - even if you have a better product, it's hard to fight against the "platform" as they have more integrated points of value.
[+] [-] manigandham|6 years ago|reply
In this case, Github is actively competing and adding features that helps all of their users. If that means that some other companies lose market share then it's just a sign that the value proposition has changed. I see no problem with this, it's how the market works.
[+] [-] asdfman123|6 years ago|reply
I don't think it's an evil plan by any means, though, and their competition has been nothing but good for the ecosystem. Remember, they were evil about Windows because so many people didn't have any other real choice. They don't have a monopoly over the cloud, so they can't be bullies (and management is totally different now, too, probably as a result).
However on my very first impressions, the tools they're rolling out kind of look like Azure DevOps under the hood. There's a good chance they'll leave the github brand alone though and just make it better.
Personally, I've been happy working in the MS stack. They really want to earn the love and mindshare of developers.
[+] [-] bad_user|6 years ago|reply
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.
[+] [-] gigatexal|6 years ago|reply
[+] [-] signal11|6 years ago|reply
[+] [-] colemorrison|6 years ago|reply
That all being said, I'm not sure how the long run comes into play here? It's bad if we extrapolate a long run prediction where no one else innovates or creates something in this space. But in reality, someone's going to be annoyed by it, someone's going to start up a different solution, and whether it works or not...it'll be there. Whether it's a small startup or a big enterprise challenging - if there's market gains to be had from adding this, it'll get added.
Don't get me wrong, you're on point with a lot of things in tech. Monoculture and monopolies are becoming super "in-your-face" considering just how much control the FAANG companies have in influencing tech and the like. However, I do find it odd that a single feature release by a larger company results, more often in not, in much of HN community losing their minds over prospective world domination. (not you op, but just in general...granted similar outrage happens to small open source stuff just as much so maybe this point is moot).
As John Maynard Keynes put it, "In the long run we are all dead." But in the short run, this just seems like a super useful feature added to a super useful product that will just make things easier for all developers.
[+] [-] justicezyx|6 years ago|reply
These happen routinely on a daily basis. And being in a strategically foundational position makes such moves straightforward.
In the developer tooling market, GitHub is foundational, obviously. So it naturally will expand, and can also easily do so.
And it was these moments I lament Google's inability to buy GitHub. All these stuff are just repeating Google has had for a decade, they would have been the perfect marriage but Google refuses to pay big money...
[+] [-] 013a|6 years ago|reply
We use Jira for ticketing and Github for code storage, like many companies. We've had SOC2 auditors tell us that they'd prefer to see us on Bitbucket just because the integration with Jira is more seamless; it guarantees a much deeper audit trail to go from RFC in Confluence -> Ticket in Jira -> Code in Bitbucket -> Deploy in whateverthefuck atlassian does for CI/CD. They didn't dock us, certainly.
But they're not wrong! I agree with them entirely! There's a part of me that hates that monopolization of our stack into one company, but there's another part of me that's like "that auditability and integration is so nice, and we literally will never see it if we're using ten different SaaS providers for each thing". How do you rectify those competing viewpoints? I don't know if you can.
[+] [-] weberc2|6 years ago|reply
[+] [-] yjftsjthsd-h|6 years ago|reply
[+] [-] Fnoord|6 years ago|reply
[+] [-] sytse|6 years ago|reply
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 are already looking to add support for more platforms. It is hard to depend on a marketplace when it starts competing with you, from planning (Waffle.io), to dependency scanning (Gemnasium acquired by us), to CI (Travis CI layoff where especially sad).
It is interesting that a lot of the things GitHub is shipping is already part of Azure DevOps https://docs.microsoft.com/en-us/azure/architecture/example-... The overlap between Azure DevOps and GitHub seems to increase instead of to be reduced. I wonder what the integration story is and what will happen to Azure DevOps.
[+] [-] snitko|6 years ago|reply
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 to escape. You have an issue with your setup you can't figure out - happened to me with Gitlab CI - sorry, you're out of luck. Every application is different, DevOps processes is something to be carefully crafted for each particular case with many considerations: large/small company, platform, development cycle, people preferred workflow etc. What I like to do is to have small well tested parts constitute my devops. It's a bad idea to adopt something just because everyone is doing this.
To sum it up, code should be separate from testing, deployment etc. On our team, I make sure developers don't have to think about devops. They know how to deploy and test and they know the workflow and commands. But that's about it.
[+] [-] Axsuul|6 years ago|reply
Furthermore:
- waffle.io was acquired and shutdown by the acquiree
- TravisCI was sold to a private equity firm and lost their way
[+] [-] rmetzler|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] triceratops|6 years ago|reply
[+] [-] bamboozled|6 years ago|reply
There are issues open to look into it but no fix in sight yet. While this announcement sounds useful, don't throw away your current CI/CD tooling which is probably a lot nicer to use.
Lastly I really dislike how pretty much any really useful actions are created and maintained by single people. There are just some actions I'd want to see be supported by GitHub, I don't wan to have to handover things like Slack access keys to a non-trusted third party to post messages.
Every time I try to use actions I'm surprised it was launched in it's current obscure, unpolished state.
[+] [-] bob1029|6 years ago|reply
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:
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.[+] [-] httgp|6 years ago|reply
[+] [-] theptip|6 years ago|reply
Anyone have thoughts on how this compares to e.g. Google Cloud Builder in terms of functionality? Being integrated into the GH backend seems like a big perk, rather than having to use webhooks for everything.
Seems like you can do things like build your Docker containers (https://developer.github.com/actions/creating-github-actions...).
One thing that's great about Gitlab is the Gitlab server/runner split, where you can run workers in your own VPC, but still use their hosted offering. This makes it easier to keep your deploy secrets (aka the keys to the kingdom) locked down, as they never leave your cloud provider.
[+] [-] t3rabytes|6 years ago|reply
It's actually Cloud Build under the covers. Their Actions Library sure beats have to figure out how to write the configs yourself for GCB though.
[+] [-] myself-or-not|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] saagarjha|6 years ago|reply
[+] [-] koalaphant|6 years ago|reply
[+] [-] vitomd|6 years ago|reply
[+] [-] marceloabsousa|6 years ago|reply
Does anyone know how they are going to bill for the compute used in the CI?
[+] [-] NathanKP|6 years ago|reply
It is totally free for public repos. For private repos:
- Free accounts get 2000 free minutes
- Pro accounts get 3000 free minutes
- Team accounts get 10k free minutes
- Enterprise accounts get 50k free minutes
Additional runner minutes are:
- Linux: $0.008 per min
- Windows: $0.016 per min
- macOS: $0.08 per min (yeah that's not a typo, it is copied straight from the page, macOS is mad expensive)
[+] [-] bdcravens|6 years ago|reply
No doubt there will soon be a Gitlab blog post passive aggressively complaining about Github copying them again.
[+] [-] n42|6 years ago|reply
[+] [-] dubcanada|6 years ago|reply
[+] [-] rehemiau|6 years ago|reply
[+] [-] 0xffff2|6 years ago|reply
[+] [-] scanr|6 years ago|reply
Anyone know?
[+] [-] myself-or-not|6 years ago|reply
[+] [-] renke1|6 years ago|reply
- Actions can fail, but still continue (more like an additional success/failure status)
- Manually triggered actions (maybe with parameters that need to be entered by the user)
- Artifacts attached to actions especially HTML reports (next to plain text, this is the universal output type for a lot of quality tools)
[+] [-] abalaji|6 years ago|reply
[+] [-] wyldfire|6 years ago|reply
[+] [-] oaiey|6 years ago|reply
[+] [-] jeanleplar|6 years ago|reply
True? microsoft person on stage https://devblogs.microsoft.com/devops/author/jeremy-eplingou...
Sorry Github! Not good!
[+] [-] the_duke|6 years ago|reply
[+] [-] qubyte|6 years ago|reply
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?
[+] [-] paulcarroty|6 years ago|reply
[+] [-] enricosada|6 years ago|reply
[+] [-] marceloabsousa|6 years ago|reply
[+] [-] cyode|6 years ago|reply
“CircleCI has been building a CI/CD platform since 2011, and GitHub has been a great partner. GitHub Actions is further validation that CI/CD is critical for the success of every software team. We believe that developers thrive in open, connected ecosystems, and we look forward to working with GitHub to lead the evolution of CI/CD.” Jim Rose CEO of CircleCI
[+] [-] pinko|6 years ago|reply
Although it's possible they can successfully position themselves as the premium upgrade, it's hard to see how this isn't a threat to CircleCI.
[+] [-] kkapelon|6 years ago|reply
One of our main goals when creating Codefresh was to make plugins that are not tied to Codefresh itself. As a result we followed the obvious model with plugins where they are just docker images and nothing else.
https://steps.codefresh.io/
We are very glad to see that Github actions follows the same model. This means that we instantly get all Github actions as possible Codefresh plugins (and the opposite).
I would be really happy if other CI companies follow suit so that eventually a central CI/CD plugin repository can be created for all competing solutions.