[Music]

Hello everyone and welcome. Today we're

going to talk about GitHub actions and

ways to automate them. Now, how many of

you use GitHub actions today? How many

of you use them for just CI/CD?

Good. You can put those hands down in a

minute because we're going to do

something really cool. So to get started

today, I want to talk about how we use

actions beyond CI/CD. So I'm going to

start introducing how we go more than

CI/CD. Then how do we go faster? How do

we accelerate our delivery by automating

things? Because the best way to do

things is to automate our way into a

job. But then we want to do that

securely. So to get started, I want to

talk about more than CI/CD. But before I

go to slides, I think we're all here for

some demos. Can we agree to that?

So this is my repository. Um I'm going

to encourage everyone as this is a

public repository to go to this and join

as a contributor as I'm talking to to

you all right now. Why are we going to

do that? Because I want you all to see

what automation I have as a news

contributor when you join a repository.

Now how many of you when you get started

on a project don't know where to start?

There's maybe no read me. Don't know

where to go. Another really good use

case is maybe you're joining an open

source project. A lot of people go, I

want to contribute. I want to do cool

things, but I'm really scared because

putting yourself out there is hard. So,

in this repository, I have a workflow

that's going to run as you all join as

contributors. I have quite a few

workflows, but the first one I want to

show you is called community management.

This is one that I've built where it

goes anytime um it's created on a new

pull request or new issue or someone

coming in, it's welcoming you as a new

contributor to my environment. So, not

only is it going to welcome you, it's

going to check, are you a first-time

contributor, are you opening that pull

request, are you opening an issue? So,

if you're there on your mobile device

right now on the GitHub app, open an

issue. Let's see what happens. Okay, so

with this issue, it runs a little script

that adds a person. It welcomes a new

issue contributor

and it welcomes a new PR contributor.

So, no matter how you're contributing to

this repository, we welcome you in. But

it doesn't just stop there. We can also

autotag our issues and pull requests

because as I open up that pull request

or that issue, I want to look at ways

that uh I can tag it for organization

because issues can get really messy and

a repositories can get really messy. We

can add priority in different components

to it. The other thing we can do is look

at metrics. Now, why would I want to

look at metrics? because I want to look

at issues and pull requests in the in

the last 30 days because sometimes when

we're contributing to projects whether

it's open source or inner enterprises,

we open that issue or we open that pull

request but it goes stale. So this

actions workflow is going to look at

that and generate a report. Now this is

all text but look at let's look at how

it actually looks in real life. So if I

go back to my actions

and this is my I'm just going to go to

the prettier screen here.

go to my community and I see someone's

already ran a ran an issue here. Let's

see what we've done. All right, we

already have a contributor. So, thank

you to the person that's already live

contributed for us. Thank you from your

top of your game. So, we've welcomed

this new contributor. It's auto tagged

some issues and PRs in it

and it's ran successfully and we got a

couple more coming in. So, I love this.

I love that people are contributing now.

So, those of you that are out there

doing this, do you see the welcome

messages? Do you see what's happening

when this is running? So, I want to see

what you all have done. I see new issues

being open and let's see what's

happened. So the one that's been

universe with an exclamation not

assigned to anyone. It's been open. I

don't see any labels maybe because there

isn't a description. So we can't always

fix everything but we have good ways

that we can look at this. So we've

welcomed everyone into the repository

today. We've done some cool stuff. Now

this is a public repository. If you want

to take these workflows with you after

today, please do. This is for you.

But the other thing I want to look at is

stale management. we often forget about

doing things. I was working on a

community project recently um and

actually it's a a Microsoft open source

project and I completely forgot about

it. So maybe every day at midnight I

want to run this schedule to see what

stale issues do I have. So in this case

I'm taking a different approach and I'm

managing stale issues and pull requests

within that repository. So I can ma mark

those as stale. I can do 90 days for PR

excuse me 30 days for PRs and seven days

before they're closed again. So again

this has all this and then we also put

some management metrics in here. So, if

I go back to the workflows that have

been running, what does this look like?

I'm going to go to our stale issue

management,

click on one that's already ran today,

and it's going to give me a report. So,

not only did I have some ability to look

at stale issues and clean it out, but I

know exactly how this cleanout report

is. How many of you have used any kind

of uh build summaries in the past?

A few of you. So in each of these

actions workflows that we see today,

there's going to be a build summary and

we can customize those build summaries.

So very much in this one, I want some

metrics. So it's not only just that

we've done some things, but how do we

know it's been done? So this is a a

management report from earlier today.

There's obviously not going to be any

stale PRs just yet or any issues, but we

can use this in other ways. And I'll

show it to you how I use it in my other

um actions workflows as well. And

another cool thing you can do with this

actions workflow, you can get this

report, you can send it to yourself,

whether that's going to be in teams or

slack, you can automate getting a report

every day or quite regularly as well.

So the next thing I want to talk about

that stale issue management. I'm I don't

want to jump ahead here. Um I want to go

ahead and look at ah we are in the right

place. So we've welcomed you into our

repository. We've done some build

reports, but I want to talk about some

enterprise use cases. Now, I want to

talk about scaling our actions. How many

of you have used repetitive actions a

lot? Or maybe you have a lot of actions

and it's quite busy in your

environments. So, in this case, we're

going to take a reusable CI/CD pipeline,

but we're calling our other workflows.

We're using reusable workflows. How many

of you have used those before? Quite a

few. Great. This is a great way to

organize when you have a lot going on.

So, we can see here in this job that's

ran, I have the backend that's ran and I

have a front-end job. I'm just keeping

it really simple. Um, you can have more

jobs running if you need to and more

workflows. So, when I go to the workflow

file of the we're going to go to the

front-end build,

I've triggered these automatically, but

we go ahead check out a repository, do a

front-end build, run everything through,

and then output it. Now in this

front-end build that I've ran earlier, I

am again using our friend the build

summary.

So this I ran a little bit earlier just

for the sake of time and I have a build

summary of how I went. Now this is a

really simple build, but I can customize

that build sum that build summary. I can

know exactly what completed

successfully, how long it took. It took

about 2 seconds. Now I did really short

builds because I was thinking maybe

we'll run these today, maybe we won't.

But if they get really long, these

builds. And I'm going to go to the

backend build because our back end is

actually a little bit beefier in this

project

from one I ran earlier. And I can pull

up the metrics down here.

I can see that this one ran for 23

seconds where the other one ran for a

couple seconds. So 23 seconds is quite

minimal. The reality is our backend

builds are probably going to take

anywhere from 15 minutes, an hour, maybe

six hours. So to make these builds go

faster, we can look at caching our

builds as well. So while we're using

those reusable workflows or those long

running workflows, we can cache them.

Bring the cache in, use some of the

pre-builds, maybe using some kind of um

Python versioning or npm packages, etc.

You can cache those in so the builds

take a lot less time. So if you do have

running workflows that are quite long

and pretty heavy, look at caching and

how you can minimize that as well.

So also on this uh reusable CI/CD

pipeline did notice here that the

backend build and the front end are

running in parallel. So this is another

good trick. We can cache our workflows

when they're needed when we have big

packages. But then also running them in

parallel saves a lot of time. Sometimes

we want to look at different steps or we

want to gate something. In this case I'm

running them in parallel so that they

run at the same time using different

runners consuming a bit more of my

actions workflows minutes but it means

that they run consistently. Now, this

could be something where you could run a

lot of your testing at the same time as

one of your other workflows. You could

be doing other tasks, maybe

documentation, hint, documentation with

actions is a really way to go for a

really good way to go forward. Um, so

not only taking a backend build, excuse

me, the full build summary, but I also

generate readmes and do lots of other

things with this. So, I've given a very

simple output of what's happening. I can

look at the tests that have ran. I can

customize this. And I like using pretty

pictures because sometimes always the

green check marks and the red X's aren't

my favorite.

So I want to go ahead. I'm gonna go back

into slides for just a moment. So bear

with me.

So I said we were a little bit more of

just more than just CI/CD. So what are

some other use cases? Um maybe resizing

images, looking at the UI of interfaces.

Um, again, these are all things that we

could do with uh with actions that's

just more than just CI/CD. For me,

documentation is a big one as well. So,

I did mention creating readmes before.

And I did say we're going to go faster.

So, again, those are your parallel jobs,

caching your dependencies, and then

using reusable jobs, especially if

you're going environment to environment.

So a really another another great

example of reusable jobs is if you're in

quite a big repo with a lot of tasks

going on instead of carving it out into

multiple repos. We see a lot of it

especially in mono repositories um or

even just legacy code bases. But more

importantly I want to talk about doing

it securely. Now do I have any security

experts in the room? A couple of you.

I'm going to give you a little bit of a

hint. We're all security experts because

we're pushing code and I've done it.

I've pushed a password.

We don't want to do that. So, we've

spent a lot of time at GitHub securing

our full SDLC's and our our workflows by

doing quite a few different things, but

we need to prove that it happened. We

need to prove that it happened

correctly. And we need to prove that it

happened correctly and the process and

the people who were involved in it were

supposed to make it happen in the first

place. How many of you have had a build

that's been tampered with? It's

happened. Um, and and unfortunately,

it's quite a bad interaction when that

happens and our jobs are on the line.

So, I want to talk about artifact

addations. when we can attest to build.

Now, there's lots of big words when you

talk about artifact addistations, but we

want to provide evidence that the

artifact that is being ran is the same

thing that we originally built because

getting things tampered with isn't very

good. So, we spent a lot of time and

effort in artifact data stations. Um,

we've also done a lot in controlling our

releases as well at GitHub. We've had

immutable releases that went G very very

recently. Um, I believe it was announced

yesterday uh on day one. So in that

we're trying to get that whole SDLC life

cycle that um a lot of our customers are

requesting. So we do have Salsa level

three compliance with this but with this

uh whether you're using a public

repository or private repository they do

work a little bit different. So with

using the GitHub manage workflow and

this is GitHub managed not on a uh

self-hosted runner. Uh if you're in a

public repository, you're attested with

the public good SIG store. And from

there, it will then go into the um add a

station, sign out a station, and gives

you a public transparency log. This is

great for open source projects. The open

source community has been screaming for

this. And here at GitHub, we've been

making sure that it got delivered. Now,

if you're running in a private

repository, which a lot of our customers

are, you attest with a GitHub SIG store,

you get your signed data station, and

then you get your output into a private

at astation store. So being able to show

a bill of materials and provenence is

absolutely critical.

So I good news have a workflow that I've

already ran today, but we're going to go

ahead and uh look at what it does. So

this is going to build a container image

for us. And I'll pull up the repository.

This is a really simple workflow because

as we know with addations, they can get

really long and quite heavy-handed. So

in here I'm it's very simple. I'm going

to push to our GitHub uh registry. I'm

going to package up our um our build.

It's going to go to the GitHub container

registry. I'm going to go ahead and

build and push that image. And then I'm

going to attest it. And I'm doing that

with several actions built into this

workflow.

And then I'm also going to give myself

an output summary. So what does this

look like when it actually runs?

So again, I just did a very very simple

build and then I give an output summary

because again, I like using these build

summaries. So as soon as I go down, I

can see the build summary. I can see

exactly the container image and the

image digest. And then I can double down

on the add a station created.

I can download this add a station. Uh I

can secure it. I can look at when it was

created. I can look at the commit

history. I can compare the shaw codes. I

can look at the build summary. I can

look at the actual workflow file that it

originated from. All this data is going

to be packaged up and something that you

can verify within yourselves. Now you

can also verify it in the CLI.

And you can get all this details in the

package that is um that is downloaded.

So on top of that, you can also compare

your add astations to your releases in

your build. So I'm going to go ahead

into our repository. Um I created a

release the other day and I can see the

this is my latest release. I can go

ahead and look at the source code. I can

look at the add astation tied to it. So

the add astations and the immutable

releases are now a very happy married

couple giving you an even further step

to secure those workflows. So, if you're

out there and you're thinking you're not

a security expert, what are ways that

you can help yourself be more secure?

And the endto-end SDLC capability with

addistations and mutable releases is

really cool. Um, and it's something that

our enterprise customers have been

really excited about and really wanting

to hear for quite some time. So, I'm

going to go back and look at our

workflow runs from earlier. Let's see.

Let's go to our issues and see how many

more issues we have going on. All right,

we've got a new contributor message. We

Oh, well, I fixed a spelling typo.

That's cuz I didn't review my own code.

Fantastic. Thank you. So, now we have a

description in this issue. And we can

see the GitHub actions bot has come in

and said, "Welcome to the project." It's

tagged your name. It feels happy and

welcoming because they said my name. It

says, "We'll review your issue. We have

a contributing guide." And that's the

output that your contri that your

contributors get. You welcome them into

the community and you can add a lot more

to that.

I want to thank everyone today for

coming in and contributing to the

codebase. Again, this is a public

repository for you to take with you. Um,

please feel free to look at any of these

actions workflows. Open up issues,

comment, break my code, whatever you

want to do. But I thank you all for

attending. Uh, my name is April. I'll be

uh here in GitHub central if you have

any questions about this. And thank you

everyone. Enjoy the rest of your

universe.

[Music]