►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Going Beyond CI/CD with Prow - Leonardo Di Donato, Sysdig
One of the most untold secrets is how hard and important is to automate the whole set of workflows around the code, not only the testing phase. We were able to use the native Kubernetes CI/CD system - Prow - to solve CI/CD for Falco. Furthermore we discovered that Prow does much more than CI/CD! Join us to find out what! You will walk away with a deep technical knowledge of Prow and how we were able to implement internally so you can too. We’ll see how to correctly setup and deploy Prow on a Kubernetes instance. How to link it to a bot account. How to hook Prow to GitHub organizations and repositories, how to establish an automated governance process for the Open Source by configuring multiple Prow plugins. Finally the audience will learn how to create its own custom plugins in order to lint commit messages and code.
https://sched.co/ZenU
A
Hello,
everybody
this
is
leo
today.
We've
got
a
story
for
you,
folks,
guess
what
it's
a
tale
about:
falco,
but
not
that
kind
of
tale
about
bpf,
cisco's,
runtime
security,
and
so
on
that
I
usually
stress
people
about.
Sorry.
Not
sorry
today
is
different.
I
promise
today
I
will
talk
about
an
important
pose
for
falco
to
adopt
pro
the
same
cicd
system.
Kubernetes
uses
to
automate
the
whole
set
of
workflows
and
policies
that
the
governance
of
an
open
source
project
requires.
A
Anyways,
my
name
is
leonardo
di
donato.
I'm
an
open
source
software
engineer
assistant,
where
my
daily
job
is
to
go
to
falco,
evolve
it
and
maintain
it
as
I'm
maintenance
farco.
I
also
have
to
advocate
and
present
its
technology
and
all
the
artwork.
We
do
to
continuously
improve
it
as
a
software
and
as
an
open
source
project.
A
So
here
I
am,
if
there's
a
thought
of
me,
moving
ends
like
a
real
italian
falco,
swag,
the
first
one
guessing
the
exact
meaning
and
since
it's
very
very
likely
that
they
will
do
other
italian
gestures,
while
speaking,
please
don't
give
up.
If
you
don't
get
this
one,
there
will
be
other
opportunities.
A
You
can
usually
find
me
on
twitter,
github
and
generally,
the
webverse,
with
the
nickname,
ludido
feel
free
to
drop
me
a
line.
Ask
me
questions
about
falco
ebpf
kernel,
whatever
no
problem
at
all,
I
like
to
socialize
when
I
first
joined
sysdig
to
work
full
time
on
falco,
which
is
now
the
first
runtime
security
project
incubated
by
cncf.
A
Honestly,
the
contributor
experience
was
not
that
good
falco
created
in
2016
to
pass
kernel
and
container
events
and
the
tech
security
threat
from
them
was
just
donated
to
the
cncf.
At
that
time,
initial
efforts
to
provide
healthy,
open
source
governance
were
already
being
put
in
place,
but
they
were
not
structured.
At
that
time.
A
Yeah
we
had
an
initial
continuous
integration
system
built
on
top
of
travis
ci,
but
it
was
honestly
causing
more
troubles
than
benefits.
We
still
had
the
building
and
testing
infrastructure
for
falco
drivers,
kernel
modules
and
the
bpf
probes
internally
at
sysdig,
and
we
needed
to
bring
it
in
the
open.
A
The
repositories
in
the
falco
security
github
organization
had
zero
or
near
zero
automation.
There
were
policies,
but
no
one
or
nothing
enforcing
them,
nor
they
were
easy
to
discover
from
the
community
prerequisites
were
often
merged
in
by
the
same
outdoor.
Without
reviews,
there
was
not
a
clear,
transparent,
auditable
path
for
maintainers
to
not
mention
external
contributors.
A
Lists
could
continue,
but
you
got
the
pint.
So
hey
no
blame.
We
are
earlier
to
learn
and
improve,
and
do
things
better
and
better
open
source
is
about
culture.
First
of
all,
the
only
problem
was,
I
didn't
have
enough
time
to
build
a
custom
cicd
system
for
falco.
We
all
know
that
testing
and
automatically
verifying
the
code
we
merge
into
our
repository
is
a
crucial
step
towards
the
creation
of
good
mindable
and
successful
software
right.
A
But
that's
just
one
of
the
things
that
revolve
around
the
code,
especially
around
open
source
code,
but
neither
I
did
have
spare
time
to
create
an
automatic,
easily
configurable
and
outable
policy
enforcer
system
and
for
the
same
reason,
spending
hours
by
reviewing
and
double
checking
every
single
action
performing
on
github
from
other
contributors
where
they
were
following
the
policies
or
not
whether
they
were
expecting
contributor,
workflow
or
not
on
various
repositories
in
the
falco
github
organization
has
never
been
an
option.
I
mean
for
evident
reasons.
A
A
However,
we
couldn't
leave
out
or
ignore
this
topic
at
all.
So
how
did
I
solve
this
problem?
I
started
thinking
of
other
successful,
open
source
projects
from
which
to
borrow
ideas
and
best
practice.
I
asked
myself
to
look
for
something
already
implementing
must,
if
not
all
our
needs,
to
create
a
healthier
open
source
environment
and
better
open
source.
A
A
typical
example
of
a
successful
problem.
Solving
I
mean
coping.
I
still
look
at
the
kubernetes
and
here
came
into
play
pro.
You
might
not
know
it's
pro,
but
if
you
contributed
to
kubernetes
or
interacted
with
some
of
the
issues
or
its
prerequisites
for
sure
you
somehow
already
interacted
with
it,
have
you
ever
met
kubernetes
ci
robot,
that's
just
one
of
the
faces
of
pro
pro
is
advertised
as
a
continuous
integration
system
based
on
kubernetes.
A
A
But
since
pods
are
just
a
bunch
of
containers,
you
can
also
check
out
your
open
source
code
by
using
init
containers.
You
can
share
volumes,
upload,
build
or
test
results,
using
sidecar
containers
and
so
on
a
lot
more
by
using
configmaps.
You
can
also
check
in
and
roll
out
configurations
in
a
declarative
way
with
secrets.
We
already
have
credentials
management
and
do
not
forget
custom
resource
definitions.
A
For
example,
you
can
write
a
controller
that
listens
for
guitar,
block,
payloads
or
github
events,
or
even
one
polling
at
the
fixed
interval,
some
other
git
platform.
You
can
schedule
custom
resources
on
different
clusters
or
in
a
different
namespace
and
so
on.
A
custom
controller
could
work
over
the
status
of
the
custom
resource
definition
and
whenever
it's
completed
can
perform
other
actions.
So
basically
they
are
very
powerful
mechanism
that
makes
scheduling
allocation,
customization
flows
easier.
A
A
Also,
pro
can
span
across
different
repositories
and
different
github
organizations.
If
you
want
this
means,
we
were
able
to
deploy
the
same
system
over
every
falcon
security
project
so
to
provide
to
the
falco
community
the
same
contributor
experience,
disregarding
the
precise
repository
or
project
they
are
contributing
to.
A
For
all
these
reasons,
it
seemed
perfect
for
me
and
in
the
end
poyana,
the
name
we
gave
to
it,
helped
us
spending
a
lot
less
time,
caring
about
cicd
and
open
source
automatic
governance,
allowing
us
to
invest
that
time
in
more
falco
coding
having
it
in
place
since
more
than
one
year.
I
also
noticed
that
having
the
same
recognized
and
mostly
automated
contributing
process
in
place
for
different
repositories
helps
people.
A
I
couldn't
task
more,
but
what's
pro,
let's
give
a
deeper
look
at
its
architecture
and
how
it's
made
it's
composed
of
various
microservices
that
take
advantage
of
the
kubernetes
functionalities,
as
said
to
provide
a
set
of
core
components,
mainly
the
one
depicted
in
this
diagram.
This
architecture,
as
you
can
see,
is
pretty
modular.
It
allows
for
extendability
and
eventually
replacement
of
components.
A
A
A
This
type
of
pro
job
runs
on
pull
frequencies
and
it
can
be
triggered
automatically
or
be
triggered
by
a
slash
command.
They
usually
run
as
kubernetes
pods
and
report
the
status
to
github
in
form
of
github
status
checks,
but
you
can
also
run
pro
jobs,
resources
on
different
execution
platforms
like
k,
native
or
jenkins.
If
you
feel
brave
enough,
I
mean
we
can
trigger
them
for
different
purposes
too.
We
can
trigger
them
for
building
testing
even
publishing
the
artifacts
of
our
project.
A
We
can
run
them
when
a
pure
request
is
merged
in
or
just
periodically.
They
give
us
a
lot
of
options,
but
what's
the
component
that
manages
the
lifecycle
and
execution
of
this
job
it
is
planned
plank?
Is
the
main
piece
responsible
for
running
the
jobs
within
pro
it
sits
there
watching
for
changes
to
the
custom
resources,
which
means
it
looks
for
jobs
created
by
pro
with
agent
kubernetes.
A
It
starts
them,
updates
their
state
and
terminates
duplicated
press
admin,
jobs,
which
is
a
useful
functionality.
When
you
push
another
change
to
your
frequency
soon
after
the
previous
one.
So
that's
a
pro
job
not
to
have
a
pod
planck
creates
it.
The
pro
job
does
have
a
part.
That's
marked
as
completed
planck
updates
the
pro
job
status
according
to
the
job
exit
status,
either
passed
or
failed.
A
It
also
stores
the
lags
of
your
job,
but
only
on
google
cloud
storage
buckets.
Last
time
I
checked
anyways.
I
know
there
are
ongoing
efforts
to
power
this
functionality
also
to
other
platforms
instead,
arola
jim,
is
the
service
responsible
for
scheduling,
periodic
jobs,
input
the
definition
of
periodic
per
job,
I'm
working
on
for
the
falcon
security
guitar
organization.
A
A
A
It
tell
us
who
generated
an
event
who
sent
it
when
what
the
content
was
and
other
related
info.
When
a
guitar
book
is
directed
towards
our
pro
cluster,
it
reaches
the
slash
shook
endpoint
exposed
by
the
deck
component,
we'll
see
in
a
bit
all
our
github
workbooks
will
go
through
this
and
the
point
that
simply
pipes
their
payloads
down
to
the
component,
which,
in
turn,
depending
on
what
workbook,
payload
content
words
will
trigger
the
relative
plugin.
A
A
As
you
have
probably
started
to
imagine
the
previous
slide
with
plugins,
you
can
do
awesome
things
like
honking
at
all.
The
prerequisites
of
your
friends
like
I
do
all
the
time.
Jokes
aside
pro
comes
with
some
cool
plugins
by
default.
You
can
find
all
of
them
in
the
link
provided
into
the
slide,
but
it
also
supports
external
ones,
and
this
is
really
a
cool
thing.
A
A
We
would
like
to
redeploy
our
controllers
every
time.
There
is
a
configuration
change
right.
This
plugin
handles
it.
It
acts
like
an
agent
that
automatically
reacts
to
events
happening
on
the
configuration
files
and
we
love
it.
Instead,
the
trigger
plugin
determines
which
job
to
run
depending
on
the
config
files
and
creates
the
corresponding
pro
job
resource,
responding
to
the
slash,
ok
to
test
or
slash
retest
commands.
A
A
Then
reviewers
can
take
a
look
at
it
and
mark
it
with
lgtm
command
to
signal
the
code
is
okay,
or
at
least
looks
okay.
In
their
opinion,
anyways,
the
poor
request
will
be
ready
to
be
merged,
in
only
when
an
approval
will
approve
it,
either
by
the
slash,
approve
command
or
by
clicking
the
approve
green
button
on
github.
A
Do
you
want
to
see
what's
going
on
on
your
pro
cluster?
The
answer
is
deck.
This
component
provides
a
dashboard
to
look
at
all
the
ongoing
the
routers,
what's
buying
them
to
be
merged
in
their
current
state
in
detail
and
recent
proof
jobs.
It
also
gives
us
a
glance
of
the
queue
of
prerequisite
schedules
for
auto
matching
by
the
tidal
service.
A
Finally,
it
also
provides
the
help
on
plugins
and
slash
commands
available
for
every
repository
you
enabled
profile.
This
works
pretty
well
to
document
your
open
source,
workflows
and
policies
when
you
want
to
onboard
new
contributors
in
an
easy
way.
I
just
mentioned
it
tida
two
times
right.
Well,
tida
is
simply
amazing,
I
don't
know
if
it's
pronounced
td
or
title,
but
forgive
me
it
lets
your
butt
automatically
merge
prerequisites
when
the
relatively
required
guitar
status
checks
are
okay,
you
don't
have
to
do
it
by
hand
anymore.
A
It
uses
the
github
search
query
to
inspect
all
the
merge
requirements,
for
example,
in
the
falco
case,
it
ensures
that
the
poor
rigas
is
not
merged
until
it
got
through
approvals
from
maintainers
comments
are
signed
off.
There
is
no
hold
from
maintaining
a
pull
request.
It's
not
a
work
in
progress
or
a
draft
per
request.
The
history
has
been
based
on
top
of
the
current
master
of
falco.
A
The
poor,
rigorous
copus
text
contains
a
release,
note
block
for
the
future
changelog
and,
finally,
all
the
contexts,
which
can
also
be
external,
continuous,
integrations
jobs,
not
tolerable
jobs
are
grey,
and
you
can
have
a
look
at
all
of
these
merge
requirements.
They
can
vary
from
repo
to
repo
to
enough
visual
form
inside
that
you
can
even
see
what
precise
label
is
blocking
a
pure
rigors
from
being
merged
in
or
if
anything
else
is
preventing
it
to
be
merged.
A
Now
suppose
we
are
pro
running
from
mums,
maybe
about
two
years
like
in
our
case
the
sinker
component
centers
the
scene.
Its
main
duty
is
to
delete,
completed
pro
jobs
and
remove
leftover
pads.
It
also
ensures
to
keep
around
the
most
recent
periodic
jobs,
because
pro
needs
them
to
calculate
when
to
trigger
the
new
ones.
So,
as
do
not
lose
the
state,
it's
kind
of
the
garbage
collector
of
pro
after
two
days,
it
deletes
completed
pro
jobs
after
30
minutes.
It
clean
ups
completed
pods,
but
you
can
also
configure
these
values.
A
If
you
want
at
this
point,
we
just
need
a
mechanism
to
get
notified
when
our
jobs
complete
right.
We
don't
want
to
stay
at
google
cloud
storage
all
day
or
other
things
like
that
here
enters
the
scene,
the
crier
component.
It
detects
changes
to
pro
job
custom
resources
and
repository
status,
changes.
It
can
report
to
github
which
will
cause
the
time
statuses
to
show
up,
or
it
can
report
to
pub
sub
services
to
garrett
or
to
slack
notice
it
overlaps
a
bit
with
blank
as
a
pro
user.
A
You
only
want
one
of
the
two
to
do
this
job,
but
no
worries
you
can
disable
the
tab,
reporting
plug,
adding
the
skip
dash
part
2
flag
to
its
deployment
red
mod.
If
you
want
in
the
provided
links
now
that
we
know
all
the
pieces
in
the
landscape,
what's
the
resulting
workflow,
they
implement,
let's
see,
for
example,
the
prerequisite
contribution
workflow.
I
implemented
the
with
proof
of
falco
for
the
sake
of
presentation.
A
I'm
gonna
simplify
it
a
bit,
but
you
will
get
the
sense.
So
we
have
two
participants
here,
a
contributor
and
that
reviewer,
when
the
contributor
sends
a
fantastic
prerequisite
from
farco,
I'm
happy.
But
what
happens
under
the
words
github
sends
our
book
to
the
pro
oak
component
containing
the
details
about
this
just
opened
pull
request
the
hook
component
dispatches
the
payload
of
the
web
book
to
the
pro
plugin,
which
analyzing
the
owner's
file
of
falcon
understands
that
no
approval
has
already
reviewed
and
approved
for
rigas.
A
So
the
approved
plugin
in
the
form
of
our
beautiful
bot
called
payana
creates
a
comment
on
the
pull
request
to
notify
that
the
purchase
is
not
yet
approved
and
needs
to
be.
At
the
same
time,
the
same
payload
gets
dispatched
to
other
pro
plugins
like
the
size
plugin
that
simply
labels
the
pull
records,
depending
on
the
number
of
line
changes.
A
In
the
meantime,
the
dco
plugin
verifies
all
the
commits
of
the
prerequisites
to
ensure
the
outer
signal
of
them,
because
our
contributing
process
requires
the
developer
certificate
of
origin.
At
this
point,
dual
component
adds
reviewers
to
the
github
request
and
the
tab
notifies
them,
either
via
mail
or
via
notifications
or
buff,
depending
on
their
github
settings.
A
Soon,
after
leo
being
a
paranoid,
maintainer
comes
to
look
at
this
new
pull
request.
Maxi
tweet
looks
good
to
me.
Common
and
eventually
triggers
some
press
admin
job
with
some
other
slash
comment
in
this
case.
The
trigger
plugin
enters
the
scene
and
contacts
the
kubernetes
api
server
to
ask
it
to
create
a
projob
custom
resource
kubernetes,
does
all
its
magic
and
runs
this
pro
job.
When
these
jobs
completes,
depending
on
its
x,
the
github
rigors
is
updated
accordingly.
A
A
It
notices
that
your
purigas
has
now
all
the
merge
labels
required
that
it
got
the
correct
number
of
approvals
from
the
maintainers
and
so
puts
it
into
the
merge
queue.
Finally,
a
minute
or
two
later,
your
prerequisites
will
be
merged
in
the
default
branch
of
falco,
and
you
will
officially
become
a
falco
country.
Builder.
Congratulations!
A
A
First
of
all
create
a
github
account
for
pro
to
use.
It
will
be
your
fantastic
bot
acting
on
the
alpha
pro
like
our
piano.
We
call
it
that
way,
because
it's
the
italian
name
for
a
kind
of
little
falcons
by
the
way
pro
will
ignore
most
github
events
generated
by
this
account.
So
it's
important
this
account
is
different
from
any
other.
A
You
wish
to
interact
with
pro
also
ensure
this
bot
account
is
a
no
remember
of
the
organizations
you
plan
on
handling
and
that
it
has
right
access
to
the
specific
repositories
it
will
operate
on
once
created
this
new
github
account
create
a
personal
access
token,
with
public
rebound
and
repo
status.
Scopes
in
case
you
plan
on
making
it
under,
like
the
tab
organizations,
also
add
the
admin,
art
or
scope
for
private
repositories.
A
It
needs
the
wall,
ripper
scope
at
this
point.
It's
time
to
deploy
pro
it
has
a
utility
called
tackle
that
guides
you
through
the
deployment
of
pro
components
in
a
couple
of
minutes.
Otherwise
you
have
to
put
on
your
high
yaml
engineer,
hut
and
manually
write
the
deployments,
the
cluster
rule
bindings
and
everything
else
by
hand.
A
This
is
how
I
did
it
and
we
are
gonna,
see
it
in
the
next
slide
and
do
not
forget
to
create
the
secrets
from
the
github
tokens
generate
an
edgemark
token
for
validating
the
guitar
box
and
the
or2
token
we
created
before,
what's
left
to
do
now.
Well,
the
usual
cube
ctl
apply.
The
last
step
is
to
add
the
workbook
to
github.
You
can
do
this
manually,
but
I
suggest
using
the
update
utility
that
comes
in
really
handy,
as
shown
in
the
slide.
A
You
now
have
a
working
procaster
welcome
to
the
club.
There
are
other
steps
and
requirements
that
can
be
done,
like
configuring,
a
google
cloud
storage
bucket
for
persisting
logs
or
exploring
the
upcoming
integration
of
pro
with
the
ks
and
s3.
But
for
my
sanity,
I'm
gonna
skip
this
and
I
left
you
as
an
exercise
anyways
in
case
you
want
to
take
inspiration
from
our
pojana.
You
can
take
a
look
at
pro
directory
of
the
farco
security,
slash
testing
for
repository
here.
You
can
find
some
little
help
to
deploy
your
pro.
A
For
example,
you
can
use
the
deployments
rule
bindings
and
rules
packs.
I
already
did
to
create
boyara
in
the
subdirectory
named
cluster
and
save
some
effort.
You
will
find
here
also
the
chrome
job
for
the
branch
protector
component.
We
can't
talk
much
about
it,
but
it's
very
useful
to
enforce
policies
on
your
git
branches.
For
example.
I
use
it
to
private
anyone
even
me
to
push
to
the
falco
master
yeah.
A
A
If
you
run
make
pro,
it
will
look
for
the
files,
token
hmac
dash
token
and
then
splash
token,
from
which
to
create
the
kubernetes
secrets
and
then
automatically
apply
all
the
previous
yum
files.
We
mentioned
remember
to
create
those
tokens
files,
especially
the
splash
one.
It
is
required
by
the
goose
plugin
to
anch
everywhere.
A
Jokes
aside,
after
make
pro,
you
can
now
run,
make
configs
command
and
then
make
plugins
one.
They
will
create
config
maps
from
the
config
xml
and
from
the
pluginsymbol
file.
We
say
that
pro
plugins
are
just
sub
components
of
the
hook,
binary
that
register
event
handlers
for
various
type
of
github
events
right.
A
These
event,
handlers
are
provided
with
clients
and
agents
that
give
them
access
to
the
configurations.
The
pro
jobs,
github
owner's
file,
secrets
and
more
anything
that
receives
github
web
books
can
be
configured
to
be
forwarded
them
and
acts
as
an
external
plugin,
and
this
makes
pro
even
more
powerful
allowing
in
cluster
or
even
out
of
the
cluster
plugins
and
integrations
with
other
bots
or
infrastructures.
A
Well,
let's
make
a
plan
together
to
create
a
simple
custom
plugin
for
pojana.
We
need
to
do
the
following
things:
write
a
little
ghost
server
that
handles
incoming
web
book,
referring
to
issue
and
pull
request
comments.
We
can
use
the
same
go
packages
pro
uses
for
its
own
internal
plugins.
So
the
task
is
not
that
difficult
as
you'll
see
in
a
second,
because
those
packages
make
our
life
easier
by
providing
us
a
lot
of
helpers
for
obtaining
the
configs,
the
secrets
and
an
already
configured,
github,
client
and
so
on.
A
Then
we
have
to
create
a
docker
image,
exposing
this
little
server
and
create
a
kubernetes
service
and
deployment
using
it.
At
this
point,
what's
left
the
usual
complexity?
I'll
apply
but
remember
we
also
need
to
add
the
external
plugin
in
the
plugins
config
map
of
our
pro
cluster.
Now,
by
creating
a
pull
request
towards
our
testing
repository
once
it
will
be
approved
and
merged,
the
config,
updated
plugin
will
take
care
of
automatically
update
the
config
maps.
A
I
wanted
to
make
boyana
aware
of
who
it
is.
For
this
reason
I
created
a
plugin
that
gives
it
the
ability
to
reply
when
slash
parana
command
is
used.
It's
called
say
my
name
pro
plugin,
it's
under
my
github.
I
put
the
link
to
it
here
in
the
slide,
so
you
can
inspect
it
later,
but
we're
gonna
see
a
bit
of
its
code
right
now.
It's
very
simple
here
we
are,
let's
briefly,
look
at
the
main
method
of
the
seminar
custom
external
pro
plugin.
A
As
you
can
see,
it's
pretty
simple.
We
instantiate
of
the
plugin
by
using
the
helpers
that
pro
provides.
As
I
mentioned
before
we
validate
those
options.
Then
we
use
utilities
to
grab
the
secrets
and
with
those
we
instantiate
a
github
client
once
done,
we
can
pass
down
this
github
client
to
the
server.
A
A
A
If
that's
the
case,
it
randomly
chooses
a
an
answer
from
an
array
from
a
slice
and
then
use
an
alpha
to
format
the
response
commenting
on
the
same
guitar
as
you
can
see.
Anyway.
In
this
repository
I
also
provided
the
docker
file
a
make
file,
build
it
and
push
and
an
example
deploy
ammo
that
you
can
use
to
deploy
this
custom
example
external
plug-in
for
pro
on
your
own
instances.
A
A
I
was
in
a
rush,
so
it
was
in
night
time
in
italy
and
my
colleagues
started.
Writing
me.
Why?
What
are
you
doing?
Well,
it's
not
me.
It's
boyana!
It's
here
to
stop
the
drama
in
case
you
do
want
to
have
some
fun
too.
Here
there
are
some
ideas
in
the
proof
topic
that
came
to
my
mind.
Well,
first
thing
we
need
to
do
is
enable
the
github
api
proxy
to
optimize
pro
against
the
github
api
limits.
A
We
can
create
together
a
custom
plugin
that
automatically
prepares
a
pull
request
to
release
falco
version
and
updates
the
changelog,
using
the
release.
Notes
in
the
prerequisites
when
it
detects
the
corresponding
milestone
has
been
completed.
There's
a
lot
more,
so
it's
just
your
call,
join
our
wednesday
community
call.
So
we
can
assist
some
tasks
to
you.
Please
also.
This
story
has
come
to
an
end
thanks,
so
much
for
coming
feel
free
to
drop
any
questions
you
have
now
or
to
contact
me
later.
A
Also,
we
welcome
a
lot
new
contributors.
Have
you
seen
the
previous
slide?
There's
always
a
lot
of
work
to
do
now.
We
have
piano
in
place
for
moon,
then,
a
year
everything
is
placed
for
a
healthy,
transparent
thing,
a
clear
path
to
participating
in
open
source.
So
it's
very
simple
to
contribute
to
one
of
the
falco
projects
even
to
point
itself
as
say
anyway.