GitHub Actions – Now with built-in CI/CD! Live from GitHub HQ


[MUSIC PLAYING] NAT FRIEDMAN: All
right, good morning. How’s everybody
doing this morning? Awesome. Welcome to GitHub. We’re so excited
to be here today. I’ve been looking forward
to this day and the news we’re going to share with
you here today for months, and the whole
GitHub team has too. There’s a lot of GitHub
employees here in the room. There’s a lot of developers,
open-source developers, developers locally
here in San Francisco, and there’s thousands
more folks watching on the various livestreams. So welcome this
morning to GitHub. We’re very excited. [APPLAUSE] This is the second time
in about 3 and 1/2 months that we’ve done a new product
announcement on this stage, and it’s a lot of fun. It’s really great. We do one announcement–
super crisp and exciting. And for those of you
who are here in person, the GitHub employees
who are here are the ones who built the
product we’re announcing, so they’d love to talk
to you about, you know, what you think,
get your feedback, answer your questions,
that sort of thing. Before we get into our
announcement today, I wanted to take a
step back and recap some of the recent
things we’ve been up to at GitHub
because 2019 has been a very busy year at GitHub. We started the year in January
by making private repos– unlimited private repos
free for all developers. It’s pretty awesome. [APPLAUSE] At the beginning of spring, we
announced the GitHub Package Registry, so that you
can share packages for private and public repos. You get a feed for every repo. We’ve had an awesome
reception to that. We announced the
acquisition of Dependabot to create automatic security
remediation pull requests, if you have vulnerable
dependencies. That’s now free
for all developers. In May in Berlin, we
announced GitHub Sponsors, which allows you to financially
support the developers that you follow on GitHub. If you like their work, if you
want them to do more of it, you have the option to subscribe
and give them your patronage, which we’re very excited about. It’s been really well-received. And then really recently,
we announced Pull Panda– the acquisition of Pull Panda,
which helps you and your teams more productively work together,
stay on top of pull requests, reduce your code review times. Developers are
loving Pull Panda. And then just last
month, we released GitHub Desktop
2.0, which now has support for rebasing,
and stashing, and lots of other
great features. And it’s just been an awesome
run for the last six months or so. This isn’t everything, though. This is really just
the tip of the iceberg. The team is shipped over
100 new product enhancements just this year, so
it’s been awfully busy. [APPLAUSE] The team has worked really
hard here at GitHub. And I’m happy to share, though,
that the momentum that we’re seeing is not just in our
engineering teams and the stuff we’re shipping in the product. It’s in the community, as well. And so today, I want
to share with you that more developers are using
GitHub now than ever before. And in fact, just this week,
we hit a huge milestone, with more than 40 million
developers on GitHub. This is an astounding stat. [APPLAUSE] If you go out and you
read industry surveys, people will say there’s about 15
to 20 million total developers in the world. So who are all these
40 million people then? That’s what I want to know. Now, with so many
developers on GitHub, we hear all the time from
you, from developers, about what’s
exciting, what’s fun, and also what’s challenging
about building software in 2019. And one of the things that comes
up again and again is the need that developers and teams have
to automate manual processes so that you can focus on the
hard problems in the projects that you’re building– so
you can do the creative work and write the code that matters,
and automate everything else– eliminate the drudgery. So the way teams
typically do this is there’s a set of services
and tools that are out there, and you’ll kind of
wire are these together and connect them to
build your workflows. And then you want
those workflows to run perfectly every time. And these are things like
you’re doing a new release and you need to draft the
release notes or issues, and pull requests
are coming in and you want to triage and label
those as they come in– or of course, you want to build,
test, and deploy your code. So at the end of 2018, we
introduced GitHub Actions, which is a platform
for developer workflow orchestration and automation,
and we launched it at our big annual
conference, GitHub Universe, in October last year. And since then, tens of
thousands of developers have been using
Actions, and we’ve been getting a ton
of great feedback. And your creations, you’ve
been releasing them publicly. We’ve seen hundreds of really
creative and inspiring actions open-sourced or released
on the GitHub Marketplace. But over the course of
the last nine months, as we’ve been receiving tons of
feedback about GitHub Actions, there’s one comment, one piece
of feedback we hear again and again and again– you want GitHub
Actions to do CI/CD. And so today, we’re
thrilled to announce the all-new GitHub Actions,
now with built-in support for CI/CD. [APPLAUSE] I can’t tell you
how hard people have worked to make this possible. And when we decided to
add CI/CD to GitHub, we didn’t want to just
do it the basic way. We wanted to do
it the GitHub way. And what does that mean? It means doing it the way that
developers want it to work. And so first of
all, GitHub Actions is fully integrated into GitHub. It’s built in. From the Merge Box,
to the Checks tab, from the UI to the API, it
works the way GitHub works. Second, we know that
you want to run jobs, not just when someone pushes
new code or on a pull request– you want to be able to trigger
workflows on any GitHub event– any event that
occurs on GitHub– a new contributor, a new
issue, maybe a dependency in your GitHub Package
Registry gets updated and you want to trigger
a workflow based on that. Any event where there’s a
webhook that you can listen on can now be used to trigger a
workflow with GitHub Actions. Third, community is really
at the heart of GitHub. GitHub’s about
sharing, so anything that you build
with GitHub Actions is shareable, because
ultimately, it’s just code in a repo. So you can make it
public, you can fork it, you can edit it, build
on it, and make it yours. And then finally,
GitHub is agnostic. Whatever language you’re
using, whatever platform you’re building for, wherever
you’re deploying your code, it’ll work with GitHub Actions. And of course,
because it’s built in, we eliminate all the
drudgery for you. There’s no need to manually
configure and setup CI/CD. You don’t have to
set up webhooks. You don’t have to buy hardware,
go reserve some instances out there, keep them up to
date, do security patches in your images, spool down
idle machines– none of that. We do everything for you. You just drop one file in
your repo, and it’s working. So the best way to understand
the power of GitHub Actions is actually for you to see it. And so please
welcome my colleague from the GitHub Actions
team, Jeremy Epling. Come on up, Jeremy. [APPLAUSE] JEREMY EPLING: –really
excited to show what we’ve been working on
for the last couple of months with GitHub Actions. And I’m just one
person that’s part of a big team
across all of GitHub that’s been making this happen. So the best way to go see this
is to actually see it live and in action. So let’s jump into a repo. What I have in this repo is
I built a simple node module that’s never had
CI/CD set up at all, and I’m going to show
you how easy it is to get started with GitHub Actions. So the first thing
I’m going to do is just go over here and
click on the Actions tab right in this repository. One of the things
that you’ll notice is we automatically
suggested a set of workflows to help you get started. So we know that I’m using
JavaScript in this repository, so we said, hey, here’s two
sample workflow files that you could use to get started. One of them sets up
CI for a Node.js app. One of them looks at a
package and not only does CI, but it also will deploy that
to GitHub Package Registry and to NPM. But we don’t GitHub’s a lot more
than just a single language. We support any language,
any platform, and any cloud. So if I go down, depending
on what my repo– what the code is
in that– you’ll notice we have
starter CI templates for every single
language you can imagine. So you can see Rust, Python. If I scroll down, you can see we
have many, many more of these, just to make it really easy
for you to get started. But as Nat said, GitHub
Actions is really a lot more than just CI/CD. It really can connect all of
the different tools and services that you use, and it can
respond to any event on GitHub. It doesn’t just have
to be a code push or something like that. It could be creating a
new issue, a comment, someone new comes
to your repository and joins as a member. So we have another
set of workflows you can get started with, as
well, for a lot of common tasks that maintainers
have to deal with, such as greeting
a new contributor. You can go ahead
and automate that, if someone’s a new contributor. You can automatically
label issues based on files that are changed
in the repository or label pull requests, and you can
automatically mark and close stale issues. And these are really
just the beginning of what I’m excited to see
the community go and build. I think of GitHub,
when it’s at its best, really a canvas for developers
to express their creativity and build lots of cool things. So let’s go back up and
just get started with CI/CD. So I’m going to click right
here and set up this workflow. And what you’ll notice
is we automatically created a YAML workflow file
directly in your repository. So we have a very
easy syntax that’s easy to go and learn
to get started with. We have a simple CI template,
again, set up right here. And then you’ll
notice over here, we actually– just to make it
even easier to get started, we have a sample of some of
the common things developers want to go do. And then this has links
to even more detailed help documentation on the format. So what I’m going
to do is scroll down to actually do a matrix build. So one of the things that we
support is not just Linux, but you can build a cross
Mac, Windows, and Linux. [APPLAUSE] So I’ll go over here, make
some edits to this YAML file. And because it’s just a
file in my repository, I’m going to go through the
normal process of committing and creating a pull request. So we’ll go through and
create a new branch, and then let’s go ahead and
kick off a pull request. And what you’ll notice is we
immediately started running CI. So you can see
the CI jobs coming in now, where we’re running
across Linux, Windows, and Mac OS. This is all right in
your pull request, right in the merge box, right
where you expect it to be. Now, we can go over here, and
let’s click on the Details to go see what this is. GitHub now has live
streaming logs built directly into the experience. [APPLAUSE] And you’ll notice,
as they come in, we have color coding and
emoji support, as well. So just like you would expect
from anything that you would see on your terminal,
you see it right here in all of its glory and beauty. So over here, you
can see we already finished the Linux build. The Mac’s build is
running, as well. And then Windows is coming too. Maybe I want to go
search my logs, though, because a lot of the times,
I’m looking for a test or there’s an error
I’m trying to go find. So I can go over here and look
for a specific test– getList– and I can search across
all of my logs right there. If I click here, I can
do other things too. Maybe I’m debugging a
time-sensitive error, and I want to go show
timestamps on every single line. Maybe I want to go download
an archive of all the logs so I can get all the
logs all together across all the different jobs, or I
could just view the raw logs right there in plain text. So this shows you how
easy it is to get started, but let’s look at a little
bit more interesting case. So a lot of
open-source is really about building and
deploying packages. So let’s go in here and
look at a workflow file that does a little bit more. So one of things you’ll notice
is right in my repository, I have a .github
folder with workflows, and I could have multiple
different workflows in there. So I have greetings already
set up, stale, as well as CI. But if I had a
large repository, we could even do filters
on specific paths. So I could have multiple
different builds kicked off for that same repository, if
I had different apps in it, as well. So let’s click on the
ci.yml and see a little bit more interesting case here. One of things you’ll see is
that I named this workflow. So it’s my CI workflow. Over here, you’ll
notice this on event. This is where you can specify
the trigger for your workflow. And we work with any events
that happens on GitHub. But not just events that happen
on GitHub– it’s anything in the entire GitHub ecosystem. So any app that’s
installed into your repo can also produce events
that you can trigger off of. So let’s say that you’re
going ahead and using any one of the many
tools that are out there. Maybe you’re using
Jenkins, or you’re using Artifactory, or anything else. You can go ahead and trigger
workflows off those, as well, or GitHub events, as well. So just to show you that, I
can show you the broad list of events that we support here. And it’s just about everything. You can imagine
editing on a Wiki, uploading a package to
GitHub Package Registry, doing a deployment, a
comment on an issue, whenever a label is created. Any of those events
you can automate. So down here, what I’ve done
is, for this one, it’s CI. So I’m just doing a
couple of code events. So I’m doing, OK, let’s go ahead
and kick this whenever a pull request happens, but I only want
to do that if the pull request is targeting the master branch. And same for push. So we have built-in
filtering, as well. We can filter on
branches and then also file paths, and
again, many more things. Down below here,
you can see the jobs that are running in the build. So we have a matrix
strategy running right here. So this one is doing
a little bit more. It’s not just building across
three different operating systems. It’s also building across
multiple different versions of Node, as well. And this doesn’t
have to be Node. It could be Go or
any other runtime. So what this is doing is
really multiplying this out. So there will be nine
simultaneous jobs kicked off at the same time. So what that allows you to do
is really speed up your testing and deployment processes by
doing all of this much faster and getting a much
broader set of testing. Down here, these are
the individual steps that are running
inside this job, and this is where it gets
really exciting for me to think about GitHub Actions. One of things you’ll
notice is we have this uses command right here. So this lets you
reference an action that lives in another repository,
and one of the awesome things about this is you don’t
have to go install an action or deal with any of that,
or install a GitHub App just to be able to leverage
another action. All you have to do is
put a JavaScript file inside a repository,
and that is an action. So let’s go over here
and see this one. This one is living in the
actions org on GitHub, in the setup-node repository. And the version of that what
I’m picking is just a branch. So that could be
a branch or a tag. So let’s click over
here, and let’s go check out this repository. So one of the things that
you’ll know right here– again, actions are just a repository. So we can drill into
the source for this, and we can see we wrote
this one in TypeScript. And again, this is
just a JavaScript file sitting in a repository. That’s how easy it is to get
started with GitHub Actions. Again, when you think of the
evolution of where the GitHub platform’s come, originally,
we had commit status, where you could just post some
basic data to let people know, hey, is this good or bad? Is there something? Then we had GitHub Apps,
where you could extend. Now, you don’t
even have to worry about setting up compute,
or deploying a server, or anything like that. You just go ahead and check a
JavaScript file into a repo, and anyone in the
entire GitHub community can go ahead and leverage that. So we’re running that for you
right in the GitHub Cloud. So let’s jump back
to our workflow file. And in addition to having
these different actions– you can obviously pass and
parameters for those actions just using with– and then we also support
running inline scripts. So any tool that you can
imagine that’s out there that has a CLI, GitHub
Action supports it. Down below here, obviously, I’ve
kicked off a lot of these build and tests all simultaneously
for a fan out scenario. Now, I want to fan back in to
actually publish my packages. So in this case, I have two
publishes going in parallel. So you can see I’m
publishing to NPM right here. And then I’m also publishing
to GitHub Package Registry. And this needs is
basically saying, hey, whenever the build
completes– whenever all those complete, go ahead
and take these off in parallel. And what you’ll
notice is, obviously, when I’m publishing to NPM, the
last thing I want to be doing is checking my credentials
into my source code. So GitHub has a
built in secret store to make it easy to go ahead and
deploy to any package registry or to any cloud. And you’ll notice
right here, I just set an environment variable,
and I said, here’s my token. And then I do secrets.npm-token,
and then that’s how I reference our secret store. But let me show
you where that is. It’s right in your repository. So if you just click on
Settings and then you go over to Secrets,
you can see my tokens right there– a secure
secret store built into every repository on GitHub. [APPLAUSE] Now, this is really
inching to see what we’ve done for our being
able to build, test, and deploy packages. Now, I want to welcome up Maël,
one of the maintainers of Yarn, to show how Yarn is using
this for CI/CD, but then also, an awesome action that he built. [APPLAUSE] MAËL NISON: Hi. As you might know, Yarn is
a quite large open-source project, and that means that
we have to interact with a lot of different people– users and contributors alike– in order to make it work. What you might not know is
that we are also a very small core maintainer team. So in this context,
anything we can do to decrease the maintenance
friction is welcome. Be the time spent running CIs
or pull request review process, or issue triaging,
everything we can trim helps. So when GitHub told me
that they were working on enhancing Actions,
the first thing I did was to try out switching
our existing CI workflow to this new system. And it actually worked. In fact, it actually
worked so well that I had some extra time
to spare on other things. So one thing I did in particular
was a batch reproduction cases. See, one of the
problem we have, when working in the open-source,
is that we often get issues. And most of this time
isn’t spent actually fixing those issues. Most of this time is
often spent trying to understand the issues,
trying to figure out how to reproduce it. Is it actually a problem? Why can’t I reproduce it? And then you go back to
the author of the issue, and then you ask
more information. And all of this is
extremely time-consuming. So I wanted to try
something in order to automate this process so
that, when I go to an issue, I know for sure how
to reproduce it. So in order to do
this, I built an action that is triggered each
time an issue is opened. And when it happens,
it finds out that code block surrounded
by a special type of fences, and runs it locally. And so, for example,
in this case, it detected that there
is this code block. It runs it inside a container,
and then reported back on the issue to tell me whether
the issue is reproducible or not. And it allows a lot
of other use cases. For example, if
I want to release a new version of the
project, then the bot can just check whether on the
opened issues are still valid or not. So this kind of automation
is extremely valuable for us because working in the
open-source, as I mentioned, is extremely time-consuming. So the less time we have to
spend on the maintenance side is the more time we can spend
on building the project, which is what really matters. Even better, those automated
workflows also improve the quality of life of
our external contributors, making it more
likely that we will continue to get valuable
contributions in the future. [APPLAUSE] JEREMY EPLING: I
love that action. Maël’s being a
little modest here. He actually started
that yesterday morning. So one of the things– yeah. [APPLAUSE] That’s what gets
me up every day. It’s like, why do I
love to work at GitHub? I love to see what
developers can do with the platform we build. It’s just so exciting. And I think that Actions is this
brand new part of the GitHub platform that are
really expanded out. You don’t have to worry
about running your code. You don’t have to worry
about our runtime. You can just write
some JavaScript and automatically
automate anything that happens on
GitHub or anything on the entire GitHub ecosystem. And it’s just amazing to
see what people will build. And I know this is
just the beginning. People are going to be
remixing these actions into different workflows. And because they’re just
files in a repository, you can go to any
open-source project. You can go to Yarn and be like,
I love the way Yarn works. Let me see what those are. You can go ahead and fork. You can look at
those workflow files. You can copy them over,
fork them, customize them, make them your own. So a core part of
GitHub Actions is really about customizing that
GitHub experience, to make it your own, so that you can
focus on what matters, which is working on your
code in your project. So we’ve shown you a couple
of different examples here, but obviously, we can do a
lot more than build, test, and publish packages. Another core scenario is CI/CD
for web services, as well. So what I’ve got here
in this repository is I’m actually building
a container, testing it, and then I’m deploying it to
multiple different clouds. So let’s go ahead and open
up this workflow file. And one of things
you’ll notice– again, familiar syntax at the top. I can subscribe to any event. I’m looking at a couple
of different events here. And then I have this build job. Again, I’m checking out
using a built-in action, and then I’m just running
a script right here to go ahead and
build a Docker image, and then push this to
GitHub Package Registry. Down here below, I’m immediately
kicking off a deployment, but I could have
had my event just be, hey, when ever something
is pushed to GitHub Package Registry, whenever something’s
is pushed out Artifactory, any of those, I could also
be kicking off a deployment. But down below,
what you’ll notice is I’m also deploying to
AWS, Azure, and Google Cloud. And with each one of these,
I’m using a specific action that’s living at a repo at a
specific branch or version. In this case, I’m
passing in– or setting environment variables. In this case, I’m passing
in some parameters for a JavaScript action. But again, this is
how easy it is just to get set up to deploy to
any cloud that’s out there. So now, let’s go over here
and look at a pull request that I merged a
little bit ago and see what the output of one
of these looks like. So I’ll go over to the Checks,
and just as you saw before, we have live logs that
are all right there. I can go ahead and
open this up right here and see the output of what
happened while I was building this Docker container image. So you’ll notice we also have
code folding built directly in, as well. So this allows you
to really focus on what matters when
you’re reading the logs, and not get kind of drowned
in repetitive output. One of the cool things
that we do here, though, is we
actually color code and highlight the exact lines
of what you wrote in your file. So you can easily see
what did you wrote, and how did we interpret that. So in this case, we
took this and turned it into a shell script
just to execute it. But again, if you had passed
parameters or anything like that, you’ll be able
to see all that right there. And then if I
scroll down, you’ll notice we’ve automatically
color coded this warning. So maybe this was an
error or a warning. Actually, I’m not really
sure what this is telling me, so I want to go share
this with somebody else and get some help. What I can do is just come
over here, and with one click, I can copy a link directly
to that line in the logs. Go over here, and you’ll notice
the entire page will refresh. We’ll go ahead and scroll the
logs down directly to the line, and then you can see that that
line is already highlighted. So again, when you’re
going to someone else, instead of telling them,
hey, open up this step, go to this line number,
they’re digging, they’re looking for what it is,
you can send a line directly to what they need to do to
keep them in their flow. [APPLAUSE] So a big part of any deployment
is obviously feature flags. So I’d like to welcome up
Edith, the CEO of LaunchDarkly, to show how they’re using
GitHub Actions for CI/CD, as well as the awesome
action that they built. [APPLAUSE] EDITH HARBAUGH: Hi. I’m Edith Harbaugh. I’m the founder and
CEO of LaunchDarkly. LaunchDarkly helps software
teams worldwide deliver and control their software. Feature management
is a best practice that’s used by our customers,
like NBC, Intuit, and BMW, and we serve over 300
billion features a day. So I’m really passionate
about feature flagging. And here is what I’m excited
about in particular is — a major complaint about feature
flagging is technical debt. So to back up a little
bit, a feature flag is a way to ship a bit of code
off and then selectively turn it on for different people. So this is the
LaunchDarkly dashboard, and here, we have a
Show Live Tiles feature that we selectively enabled
to turn on to people after a certain date. You can also do stuff with
us, like a kill switch, and even do a
progressive roll-out with some people at a time. So this feature’s live. It’s running great. I can go into our Insights
tab– yep, going really well. And now comes the hard
part for a lot of people. Their feature is great
out in the field. And it’s like cleaning up
your room– nobody really wants to go and
tidy up the socks. You’re like, well,
everything is great. So with GitHub Actions,
we added this feature of code references. And this tab allows you to
click in and see exactly all the places where
a feature is used. And then you can go
and view it in source. And it jumps down to exactly
where it is in your source so that you can really
easily clean it up. And this is all
enabled by Actions. So we’ve built an action here,
where every time somebody checks in code, it is– pushes out to LaunchDarkly
exactly where the code is used. So now, we have a workflow
where a developer can say, when a code– when a feature
is completely rolled out, they can go in, see exactly
where it is, pull it out, and then have
a much tighter code path without stale code. And this is all enabled by an
extremely simple YAML file. This is just 18 lines of code– so very simple and
very easy to use. LaunchDarkly itself
is– has over 18– sorry– has exactly
18 client libraries. They’re all hosted on GitHub
and they’re open-source. We have all the most
popular languages, and we have both client
and server side support. So I’m personally very
excited about this new feature of code references and how it
was enabled by GitHub Actions. It was an honor to be part of
the launch activities today. [APPLAUSE] NAT FRIEDMAN: OK, thank you,
Jeremy, Maël, and Edith. Isn’t that awesome? I’m pretty excited. Let’s recap a few of the
highlights of what you just saw, and some of the
reasons that we’re excited about GitHub Actions. So first, your GitHub Actions
can run in a container or on a virtual
machine with support for Linux, macOS, and Windows. Actions support
matrix builds natively so that you can run parallel
jobs across operating system versions, runtime versions, or
any variable you want to use to multiply your workflows. And as Jeremy showed,
Actions have built-in support for real-time feedback in
the form of streaming logs that are searchable,
support colors, emojis, and are deep
linkable that you can use to help pinpoint a
log line and send that to a friend or colleague. We know that a lot
of the work that you need to do with GitHub
Actions and in your workflows involves integrating
third-party services and tools. And to do that
securely, you don’t want to put your tokens
in your source code. You need a secret store. And so every repo
on GitHub now comes with a secure secret store where
you can store your secrets, update them easily. And then, of course,
because it’s GitHub, actions are easy to write. They’re easy to share. You can build on them. And this is really,
I think for me, at the core of what
we’re doing here. Our world view and
GitHub is this view that software development is
actually a global team sport. And we often think
about developers as working in isolation, solo on
projects, alone in their rooms. But the truth is that
every line of code we write builds on the work of
thousands of other developers. And with GitHub Actions, because
your workflows are just code, you can now build on
people’s workflows too. So we’re really excited to open
up this possibility for all of us to learn from the
world’s most productive, most inventive teams. I was also super blown away by
Maël’s action that he demoed earlier, where he can
automatically check issues that get filed to see if they’re
reproducible or not. That’s an incredible,
creative idea, and now, we can all go to Maël’s
repo and learn from that. And so I think that’s
incredibly exciting. And so to make this possible,
we are making GitHub Actions completely free for
public repositories so the open-source community
can use GitHub Actions. [APPLAUSE] Our aim is to support
any community that chooses to use GitHub
Actions for CI/CD or workflow automation. Now, for private repos, we’re
going to offer really simple pay-as-you-go
per-minute pricing. Every GitHub user will get
a bunch of free minutes, whether you’re a free
user, whether you’re paying us to get you started. And then above that,
you’ll just pay as you go. So you’ll get anywhere
between 2,000 minutes a month for free accounts up to
50,000 minutes a month included in your GitHub
plan for enterprises. And then if you
need extra minutes, we have really competitive
great pricing– different prices for
Linux, Windows, and Mac. And so by including these
offers in every GitHub plan and by making GitHub Actions
free for public repositories, we are enabling 40 million
developers around the world to leverage GitHub for CI/CD
and for workflow automation out of the box at no extra cost. Really excited about that. Now, if you don’t want
to run on our machines, you don’t have to. Later this year, we are going
to release and open-source our runners so that
you’ll be able to run all these actions, all
these workflows, all these builds on
your own machines for free, at no
cost to you at all. It’ll work on Linux,
Windows, and Mac. It’s the same one that we’re
running up on our hardware. It’s super portable. Runs on x86, runs on ARM. You can even run it on a
Raspberry Pi, if you want to. So we’re pretty
thrilled about this. Look forward to getting
your pull requests. Now, you heard from Maël
and the Yarn project, but over the last
several months, we’ve been so lucky to get to
work with a bunch of really great open-source projects
on GitHub Actions. These are all projects that
have been using Actions and providing us with feedback. They include awesome communities
like SciPi, and Bootstrap, and Ruby, and NumPy, and others. And so later today,
you’ll be able to go to some of these repos,
like Yarn and Bootstrap, and just look at
their workflow files, see how they’re using
Actions, learn from them, and build on them. We’re also incredibly
lucky at GitHub to be working with some of the
biggest companies in the world. And so we want to
offer our thanks to companies like UBS,
Dow Jones, Philips, and SAP for all their great
feedback on GitHub Actions so far, as well. Thousands of developers
at these companies rely on GitHub every single
day to do their jobs, and we’re honored to
have the opportunity to serve their workflow
automation and CI/CD needs, as well. Now, one of the things that I
find most amazing about GitHub is it’s not just a
tool that you use. It’s also a platform that
developers around the world can extend. And every day, we see
these different creative and unexpected ways that
developers and companies are extending GitHub,
extending developer workflows using the GitHub platform. And as Jeremy said,
what’s really exciting about GitHub Actions is it
makes the platform more rich. It’s a richer platform. There’s more new ways that
you can extend the platform. There’s new APIs. There’s new events
that you can listen to. And any GitHub app can also
generate its own custom events that can trigger
workflows, so there’s a real extensibility
at play here that we think is really
exciting for developers. Any third party,
like LaunchDarkly, can use actions to
trigger a CI/CD build or any other workflow, and
can listen on any event. And then you, as developers,
and in your teams, can choose any tool in the
world to integrate with GitHub through GitHub
Actions very easily, whether that’s one of our
partners like LaunchDarkly, or Codecov, or Coveralls,
or another CI vendor, like CircleCI or Codefresh. GitHub gives you the choice,
and that’s very important to us. So we’re working with
all the companies that are listed here to provide
great integration with GitHub Actions. And some of these have already
released some integration, and some of it will
be coming soon. I personally can’t wait to
see what the community does on GitHub Actions and to
see more creative ideas get released, and for us
all to get to learn and work like the best. So you can actually get
started doing that today by signing up for the beta. So for those of you who are here
in the room in San Francisco, we’re going to be
enabling GitHub actions with this new CI/CD
support on your accounts in the next 24 hours or so. So please be patient. Some people have already
cornered me and been like, hey, it’s not enabled yet. So it’s happening. It’s happening. If you’re already
in the Actions beta, we’re going to be rolling out
these new features for you over the next week or two. So we’re going to be releasing– the phrase that was used
is opening the floodgates. So prepare yourselves. It’s coming. And we’ll be letting
a new sign-ups in aggressively over the
course of the next month. But — we are not going
to be in beta for long. In fact, we’re planting a
stake in the ground today, because GitHub Actions
will be generally available on GitHub for all
users on November 13 this year. That’s in 97 days. [APPLAUSE] There will be 97-day countdowns
in front of every GitHub developer over the next– and GitHub Package
Registry we’re also planning to make generally
available at the same time. So that’s just 97 days away. Please give it a try. Send us your feedback. People seem to have no trouble
finding me on Twitter, so continue to do that. It’s totally fine. November 13 is also
a special day for us because it’s the first day
of our annual developer conference, GitHub Universe,
where we first unveiled GitHub Actions last year. It’s here in San Francisco. It’s November 13 and 14. And in addition to the
news that we just made, we’ve got some other major
product announcements that’ll be coming out then that
we’re really excited about. So tickets are on
sale now, and we hope you can join us in person. OK, the GitHub team
has worked awfully hard to get to this day. This is the culmination
of a ton of work. We are so excited that we
got to share it with you. Thank you for spending part of
your day, part of your morning, afternoon, or evening–
wherever you are– with us today. We’re hope you’re as excited
about GitHub Actions as we are, and we look forward to
hearing your feedback. Thank you very much. [APPLAUSE] [MUSIC PLAYING]

Posts Tagged with…

Reader Comments

  1. Mike Wyatt

    35:50 – start
    42:45 – walkthrough of actions / workflows
    53:10 – how yarn are using these new features
    57:20 – deploying to multiple cloud providers
    1:00:15 – feature flags
    1:03:28 – recap

  2. Adam Sabla

    This is great!! Thanks! …Is there any chance we could get to Beta? We're setting up CI/CD right now and now we're puzzled about wether to go with GitLab and then consider switching, or wait… but to wait 3 months, it's a lot O:-)

  3. Joonas Yliaho

    I have enrolled to the actions beta, but none of the new features demonstrated in this video doesn't seem to be available to me…

  4. René Baron

    Absolutely great stuff. I can imagine that GitHub Action might massively simplify and therefore change habits not just for software developers but for anyone using GitHub for other purposes as well (i.e. we have repos just for professional requirements managements or collaborative product documentation – no code).

Write a Comment

Your email address will not be published. Required fields are marked *