►
From YouTube: OpenShift Coffee Break: Pipelines as Code
Description
Get your espresso ready for the EMEA OpenShift Coffee Break together with Natale Vinto and Jaafar Chraibi as we go into another episode of the Tekton in action series: Pipelines as Code! Together with Savita Ashture and Khurram Baig from Tekton engineering team, we will discuss how start using pipelines from your git repositories that can be executed when triggered by a Pull Request or a Push.
A
A
B
A
A
So
basically,
whenever
you
make
a
code
change
you
you,
may
you
do
a
git
commit
or
you
create
a
pull
request,
or
something
like
that.
You
want
to
have
some
automated
pipelines
within
your
workflow
and
basically
that's
what
we
are
going
to
uncover
today,
so
savita
and
puram.
If
you
want
to
please
introduce
yourselves
and
of
course,
natalie
also,
but
he's
very
famous
already.
B
C
D
You
thank
you.
Everyone
welcome
good
morning.
I
hope
you
had
your
coffee
shot
here.
I
openshift
coffee
break.
My
name
is
nadal.
I'm
a
product
marketing
manager
with
openshift.
We
are
hosting
this
show
together
with
jafar,
and
we
are
very
happy
to
have
again
savita
in
in
the
stream
and
also
to
have
a
cool
run
for
today's
talk.
Jafar,
I'm
really
excited
to
see
pipeline
as
code.
So
I'm
I'm
looking
forward
to
see
what
it
is
and
how
it
can
be
implemented
on
top
of
openshift.
A
Okay,
and
so
just
one
one
clarification
for
our
viewers
we
are
making
so,
as
you
saw,
savita
was
already
on
a
previous
episode,
so
our
goal
is
to
have
a
series,
so
we
will
be
having
several
episodes
about
tecton
and
openshift
pipelines
and
as
we
go
along,
we
are
going
to
explore
more
advanced
concepts
so
yeah
today
we
will
be
speaking
about.
You
know
how
to
trigger
pipelines
from
from
git
events
and
especially
explain
what
happens
in
the
background,
which
is
basically
what
you
guys
have
implemented
to
make
it
work.
A
A
A
A
A
D
B
B
B
B
C
C
A
A
Okay,
yeah
yeah,
so
so,
let's
pause
for
four
seconds
on
these
concepts
and
try
to
to
explain
why
we
are
talking
about
this.
Okay.
So
usually,
when
we
are,
you
know
as
a
developer
or
even
you
know,
if
you
are
implementing
continuous
delivery,
you
want
to
trigger
your
pipelines
from
a
git
event.
Like
you
make
a
comment
or
you
merge
a
pull
request
or
something
like
that.
Then
you
want
some
some
pipelines
to
to
automatically
get
executed.
A
So
if
we
rema
remember
the
the
how
tekton
works,
you
have
this
notion
of
pipeline.
So
basically
the
pipeline
is
the
definition
of
everything
that
is
going
to
run
like
the
the
tasks
and
the
steps
etc,
but
the
python
itself
doesn't
run
it's
not
an
instance
of
of
of
something
that
is
running.
It's
just
a
static
definition
like
if
you
were
in
java.
You
have
your
your
class
and
then
you
have
the
instances
of
your
class,
so
the
class
doesn't
exist
in
itself.
A
A
What
branch
is
it?
What
is
my
working
context,
etc,
etc?
So
it
needs
some
dynamic
information
because
we
don't
want
to
have
static
information
in
the
pipeline
static
definition,
so
we
have
what
we
call
placeholders
or
variables
that
we
define
in
the
pipeline.
We
say,
for
example,
this
is
dollar
git
url.
A
This
is
dollar
git
branch,
etc,
etc.
So
this
is
all
going
to
be
variables
and
at
runtime,
when
we
want
to
trigger
the
pipeline
run,
we
want
these
things
to
be
filled
right.
We
want
to
to
get
the
proper
values
and
that's,
I
believe,
where
the
those
triggers
come
in
play
come
into
play,
so
they
we
have
the
pipeline.
We
have
the
pipeline
run
and
those
triggers
are
going
to
say
okay.
So
when
I
have
this
git
event,
please
take
this
variable.
A
This
variable
and
this
variable
and
fill
that
in
the
pipeline
run
or
to
create
a
pipeline
run.
Okay.
So
that's
what
I'm
saying
here
is
a
shortcut
I
have
pipeline
on
the
left.
I
have
a
pipeline
run
with
all
the
data
that
is
already
filled,
and
now
we
are
trying
to
explain
what
happens
in
between
all
right
so
and
yeah
yo.
So
please
go
ahead
again
gram
and
explain.
B
Yeah
so
so,
if
you
have
I'm
say,
if
we
have
a
web
of
events
from
github
generally,
it
will
be
there
in
the
payload
or
maybe
some
information
might
be
there
in
header.
But
generally
we
use
payload
field.
Also
a
payload
fields
and
and
those
payload
fields
are
extracted
to
the
parameter,
define
and
trigger
binding.
B
B
A
B
A
Okay,
okay,
so
I'm
from
I'm
not
sure
everyone
can
hear
fine,
because
we
have
some
audio
issues.
So
that's
why
I
I'm
rephrasing
so
so,
basically,
what
you
just
explained
is
we
have
something
that
says
here
are
the
variables
that
are
interesting
to
me.
I
want
to
get
the
url,
the
git
url,
the
branch,
the
et
cetera,
et
cetera,
the
committer
id,
maybe
or
something
like
that
and
those
things
we
define
them
in
the
trigger
binding,
correct.
A
C
B
A
D
B
B
Okay,
then,
we
have
an
even
listener
crt,
which
provides
an
invention.
Basically,
all
these
operations
like
trigger,
binding
and
trigger
template
operations
are
done
by
human
listeners.
It
extract
parameters
from
trigger
binding
and
create
resources
for
the
corresponding
trigger
template
and
okay
yeah
for
it,
and
you
can
also
provide
interceptor
in
the
indirect
email
listener
to
pre-process
the
event
payload,
and
then
we
also
have
some
advanced
concept
called
block
cluster
interceptor
cluster
interceptor
provide
a
clustered
scope
and
style
interceptor,
meaning
you
can
have
a
k
native
service
which
basically.
C
A
B
A
A
Robot
was
basically
this
type
of
framework
where
you
can
define
these
things.
You
say
if
I
have
a
push
event
then
do
this,
but
the
do
this
thing.
Is
you
basically
have
to
write
your
own
code
to
extract
the
information
from
the
the
payload
to
do
your
own
custom
logic,
and
then
it
can
interact
with
with
something
else.
So
basically,
I
was
implementing
some
node.js.
A
Backend
that
waits
for
something
to
happen
on
on
github
part,
and
that
does
something
like,
for
instance,
it
can
create
a
project
in
openshift
it
can
deploy
an
application,
automatically
etc.
But
all
of
that
you
have
to
do
it
by
coding
things
yourself.
It
was
just
an
empty
shell
and
what
you
guys
did
here,
I
think,
with
the
event
listener
is
you
have
implemented
this
feature
out
of
the
box.
A
So
basically,
when
you
create
your
pipeline
and
you
create
your
whatever
you
need
to
interact
with
the
git
or
github,
etc,
you
do
instantiate
your
own
backend
that
listens
to
these
events,
and
that
already
has
all
the
logic
to
extract
the
correct
information
and
to
create
whatever
it
needs
to
run
the
pipelines
in
in
openshift.
Is
that
a
correct
way
to
to
yeah
yeah
to
phrase
it.
B
A
B
C
Yes,
basically,
one
more
point,
I
just
want
to
add
here
like
when
we
have
trigger
installed
right.
So
by
default
we
will
have
some
three
for
a
core
interceptor
like
git,
gita,
sorry,
github,
bitbucket,
gitlab
and
cl
along
with,
like
as
this
cluster
interceptor
introduced.
The
main
motive
is
to
earlier
with
having
this.
Only
like
fixed
interceptor
was
blocking
the
triggers
to
grow.
I
mean
it
was
not
able
to
make
use
of
the
triggers
in
a
dynamical
way.
A
A
B
Yeah
yeah,
this
summarizes
what
I've
said.
Let's
say
an
event
is
coming
to
the
evidence.
The
part
of
sync
and
then
regular
binding,
is
extracting
those
parameters
and
providing
a
closed
record
template
and
we
have
some.
This
is
a
combination
of
trigger
and
and
then
in
turn,
it
will
create
a
resource.
D
B
A
A
B
A
So
is
that
correct
to
say
that
the
event
listener
is
a
an
application
itself
that
runs
in
a
pod
like
it's
something
that
is
it's
it's
yeah,
it's
it's
an
even
based
architecture
where
you
have
a
pod
that
listens
for
something
to
happen,
and
when
it
intercepts
that
event,
it
does
something.
Is
that
correct.
A
A
A
A
C
C
A
A
D
Just
as
sorry
just
as
confirmation,
the
event
is
an
http
post
from
a
web
book
right.
It's
always
http
https,
it's
a
post
with
a
json
content
or
any
other
form.
So
this
is
the
kind
of
event
which
is
that
this
component
is
listening
to,
and-
and
I
have
a
question-
I
don't
know
if
you
are
aware
for
the
next
version
of
openshift-
if
there
will
be
an
improvement
in
the
pipeline
ui,
you
know
now
pipeline
unite.
Ui
helps
you
creating
at
is
a
pipeline
in
openshift
web
console.
D
C
Yeah,
so
maybe
like
more
thing,
we
will
see
in
the
demo
section
so
right
now,
like
open
shift,
yeah
open
shift,
ui
have
basic
template
for
the
triggers
and
which
will
just
give
us
the
end-to-end
flow,
but
coming
to
the
advanced
use
cases.
So
right
now,
it's
under
still
implementation
but
yeah
to
answer
the
questions
right
now.
Ui
supports
the
trigger
adding
part
along
with
the
pipeline.
A
Yeah
yeah
so
yeah.
So
if
I'm,
if
I'm,
if
I'm
not
mistaken,
that's
what
you
mentioned
about
like
the
pre-existing
stuff
for
github
and
gitlab
etc,
because
you
can
already
say
I
want
to
intercept
this
event
from
github
or
whatever,
and
it
will
create
those
event,
listeners
etc
with
the
correct
information
yeah
because
because
if
you
have
to
create
everything
via
ammo,
it's
a
bit
complex.
A
So
so,
since
we
are
speaking
about
both
techton
and
openshift
pipelines-
and
we
are
rightfully
you
know-
we
have
a
foot
in
community
and
we
have
a
foot
in
products.
So
does
these
things?
Okay?
Can
they
also
be
done
from
the
upstream
ui,
or
is
it
something
that
we
add
in
the
openshift
console
as
an
added
value
like
I,
I
haven't
played
with
detector
dashboard?
I
don't
know
what
the
ui
does.
A
B
A
B
B
C
A
B
A
A
Okay,
okay,
cool,
so
yeah,
so
that's
part,
I
would
say
so
that
that
was
a
very
you
know,
genuine
question.
I
I
didn't
know
what
the
answer
was,
but
so
this
is
basically
something
that
we
do
as
part
of
the
added
value
of
the
openshift
console
where
we
we
make
it
even
easier
to
use
upstream
features,
but
in
a
more
productized
way.
So
I
think
we
have
things
like
also
designing
the
pipeline.
A
A
Yeah,
so
sorry,
just
to
to
make
sure
I
understand
it
correctly
in
your
payload,
when
you
have
your
git
event,
it
has
something
called
commit
id
and
it
has
something
called
repository.url:
okay
in
your
json
payload,
and
basically
what
this
says.
This
figure
by
link
says
extract
this
thing
that
you
have
in
value
yeah
and
store
it
as
git
revision.
Is
that
correct,
like
this
is
going
to
be
the
parameter
name,
revision
that
would
be
used
somewhere
somewhere
else.
B
D
And
I
guess
this:
this
json,
you
are
kind
of
navigating
the
dom
of
the
json,
not
from
the
web
book
post,
academic,
http
request
and-
and
I
guess
this
this-
those
those
fields
here-
change.
No,
if
you
are
using
github
or
gt
or
cox
or
a
git
lab
so
yeah
from
the
experience
I
think
they're
pretty
they
say,
but
sometimes
they
change.
So,
if
you
wanna.
B
C
A
And
so
so
a
funny
thing
that
you
mentioned
this
natalie,
because
for
many
many
reasons
so
at
some
point
many
years
ago,
I
think
it
was
eight
years
ago
or
maybe
10
years
ago
there
was
a
group
of
software
vendors
that
said,
okay.
So
whenever
I
have
an
issue
like
a
jira
issue,
if
it's
in
in
jira
it's
something
if
it's
in
github
it's
something
else.
If
it's
in
gitlab
it's
something
else,
can
we
come
up
with
some
sort
of
standard
to
make
things
to
to
be
able
to
integrate?
Like?
A
A
So
thus
you
you
are,
you
have
a
specific
implementation
for
every
tool
and
the
goal
of
this
thing
was
to
have
one
standard
pivot
format
that
you
integrate
with.
So
it's
always
going
to
be
head
underscore,
commit
under
underscore
id
and
whatever
you
have
on
the
other
front
like
if
it's
git
it's
going
to
be
transformed
to
fit
in
that
field,
so
you
don't
have
to
implement
it
for
every
different
tool.
A
A
A
We
don't
have
any
more,
each
one
with
his
own
definition
or
his
own
dsl,
to
define
a
pipeline
like
the
groovy
for
jenkins
and
the
yamo
for
guitar
runners,
etc.
So
now,
if
we
are
using
the
tekton
part
of
it,
it's
going
to
be
the
same
yaml
it's
going
to
be
standard
of
things,
so
maybe
it
can
make
sense
to
go
even
further
and
say:
okay,
now,
let's
standardize
on
those
bits
as
well.
B
C
A
B
D
A
D
Right-
and
you
see
you
have
it
here
as
open
source
upstream
project,
we
have
today
awesome
engineer
talking
about
it,
which
is
very,
very
cool,
and
you
know
what
this
is.
Another
example
of
kubernetes,
which
is
a
standardization,
also
platform,
we're
going
all
everyone
into
the
same
standard,
same
open,
source,
same
project,
same
standard,
so
this
kind
of
you
know
converging
on
on
the
same
thing,
which
is
very
cool.
I
think
we
can
go
in
the
next
step
because
we're
we're
going
otherwise
out
of
time
there
there.
D
B
B
But
just
what
it
does
is
it's
modify
the
payload.
That's
what
already
said-
and
this
is
how
we
define
the
landfill.
You
have
a
service,
it
creates
service
deployment
for
running
which
modifies
it
and
give
it
200
response.
So
what
you
have
is
name
of
the
deployment
name,
space
and
path
we'll
have
soon.
B
B
A
We
have
audio
issues,
it's
dropping
a
lot.
So
please
excuse
me
if
I,
if
I
rephrase
what
you
what
you
said
well,
basically
people
who
are
watching
can
can
read
this.
The
file,
the
the
most
important
or
interesting
thing
I
see
here
is
the
server
listing.
Is
it
correct
to
say
so?
Savita,
please
confirm
yeah.
So
when
we
spoke
about
the
even
listener
we
said,
there's
a
pod
that
is
always
running
to
intercept
whatever
things.
A
A
C
A
C
Basically,
like
till
no
event
listener,
whenever
we
create
you,
it
is
to
create
ka
test
spot
right.
So
now,
like
we
integrated
with
k
native
service,
so
with
the
help
of
k
native
service,
we
could
able
to
achieve
this
serverless
thing.
So
so
there
is
another
we
have.
We
have
a
custom
resources
in
event,
listener
like
we
can
specify
kubernetes
resource
or
custom
resource.
A
A
A
A
A
C
C
C
It's
fine
yeah
yeah,
it's
fine,
now:
okay,
yeah,
so
yeah
for
okay,
so
everything
is
installed
in
this
cluster,
so
all
the
openshift
pipelines
and
all
so
the
one
thing
to
make
sure
that
the
openshift
pipeline
is
installed
or
not.
So
we
can
see
a
pipeline
column
here
so
pipeline
triggers.
So
it
shows
like
okay.
C
Okay,
so,
okay,
let
me
create
a
new
namespace
called
demo
so
project,
so
yep
yeah,
so
project
got
created,
so
I'm
going
to
use
this
form
git
so
that
I
can
specify
my
own
github
repo.
So
this
is
the
one
which
I
have
created
for
this
demo.
So
by
default
it
selects
the
builder
as
go,
and
I
am
not
going
to
touch
any
of
the
things
so
just
I
will
add
a
pipeline
so
what
it
will
do
when,
while
creating
this
form.
C
A
C
C
Okay,
so,
okay,
before
that,
I
just
want
to
show
like
pipeline
run,
is
triggered
already
and
just
for
the
refresh
purpose
like
this
pipeline
run,
contains
three
tasks:
fetch
repository
building
and
deploying,
and
all
these
three
tasks
have
several
steps,
so
those
steps
will
actually
run
the
containers
and
do
the
operation
so
now
like
how
to
move
this
one.
I
want
to
edit.
C
Yeah,
okay,
so
here
like,
if
I
go
to
pipeline,
I
will
have
a
edit
option
right,
so
here
edit
pipeline
is
there.
So
if
I
do
some
edit
operation,
I
mean
I
can
add
some
task
or
edit
something
so
once
I
do
this
edit
operation
after
that
to
get
changes
of
those
edit
things
I
need
to
rerun
here
I
mean
I
need
to
start
it
again.
B
C
Don't
want
to
do
that
start
manually
right,
so,
as
you
explain
as
we
discussed
in
the
present
while
presenting
like
we,
we
don't
want
to
start
any
of
the
pipeline
manually.
Instead,
whenever
an
event
occurs,
it
should
rerun
right
so
based
on
the
events.
So
to
do
that,
like
we
have
a
trigger
concept,
as
we
discussed
so
till
now,
we
just
created
a
sample
pipeline
and
pipeline
run
automatically,
but
later
on,
whenever
there
is
some
changes
to
my
repo.
So
basically
my
repo
is
this
one.
C
A
A
C
We
have
added
this
add
trigger,
and
here
we
have
the
option
to
select
like
which
pro
provider
we
want
like
whether
it
is
a
bit
bucket,
github
or
gitlab.
So
basically,
we
have
supported
all
these
things
and
it
will
be
inbuilt
added
to
this
operator
so
that
by
default,
all
these
things
will
be
created
already,
so
that
we
can
make
use
of
them
directly.
A
C
B
C
A
C
A
C
I
can
choose
trigger
tab,
so
you
can
see
a
event.
Listener
got
created
just
now.
You
can
see
time
also,
and
one
thing
I
want
to
show
like
I
have
not
created
it.
I
have
not
created
any
trigger
bindings
but
openshift
pipeline
operator
in
by
default.
It
it
have
all
these
cluster
trigger
binding,
so
it's
available
at
the
cluster
level,
so
that
so
so,
basically
in
triggers,
we
have
two
crd
called
trigger
binding
and
cluster
trigger
binding.
C
So
all
these
things
are
shipped
as
a
cluster
trigger
bonding
because
everyone
can
use
it
across
the
cluster
and
if
someone
want
at
the
name
space
level,
they
can
directly
come
and
create
in
the
trigger
binding,
using
this
like
ammon
way
and
also
we
can
see
a
trigger
template
so
before
that
in
the
cluster
trigger
binding.
I
just
want
to
show
how
this
get
github,
pull
request.
Look
like
so,
if
you
see
yaml
here
yeah,
so
we
can
see-
or
these
are
the
different
different
parameters.
It's
actually
watching.
A
B
C
Revision
action,
full
request,
number
and
full
name
and
everything
like
whichever
the
required
information
and
same
thing
will
be
used
inside
trigger
template,
so
I'll
go
back
to
trigger
template
now.
So
we
can
see
here
in
the
yaml
section
c.
We
use
all
those
parameters
from
the
trigger
binding
and
in
the
spec
like
we,
we
are
making
use
of
the
from
which
repo
and
what
is
the
name
and
all,
and
we
are
finally
using
the
pipeline
which
we
created.
Initially,
we
are
not
creating
any
new
pipeline
here.
A
C
C
C
I
mean
these
things
club
together,
so
that
information
can
be
shared
so
now,
like,
as
I
have
created
everything
so
this
event,
listener
internally,
creates
a
k
test
pod,
as
we
discussed
so
it
it
will
create
a
kubernetes
part
so,
and
it
keep
on
running
as
it's
a
kubernetes
based,
so
it
it
keep
on
watching
on
the
event.
So
it's
like
continuously
running
and
it
it
just
watches
on
the
spot
port
and
another
thing
is
like
when
we
create
this
one.
It
automatically
creates
a
route.
Also,
oh
okay.
C
C
C
Why
it
gave
the
error?
No,
I
will
make
use
of
this
url
and
I'll
go
back
to
my
repo
right.
So
this
is
the
simple
go
up
which
I
use
for
the
creating
pipeline.
I
will
go
to
settings
and
add
it
to
the
webhook.
So
here
is
the
webhook,
so
I
have
already
set
it
up
for
testing
purpose.
So
I
will
just
straight
away
clear
everything.
C
So
here
we
will
specify
the
payload
url
of
our
event
listener.
One
right
and
content
type
always
should
be
application
json.
This
is
the
one
which
it
will
expect
and
then
we
can
select
anything
which
we
want
so
right
now.
I
am
interested
in
pull
request
right,
so
I
just
click
on
this
one.
Let
me
individually
select,
so
I
I
just
selected
the
pull
request.
So
in
pull
request,
we
have
these
many
events.
C
C
So
I
will
just
update
this
web
book,
so
the
book
is
updated.
So
I
have
already
created
few
pr's
for
the
testing
purpose.
So
what
I
will
do
this
is
the
existing
pr
right.
So
I
can
do
any
action
on
this
pull
request.
So
if
I
do
some
action,
it
should
automatically
re-trigger
for
me.
So
before
doing
any
things,
I
will
just
go
back
here
and
show
like.
Currently
we
have
only
one
pipeline
run
running
in
this
demo
name
space
you
can
see
so
now.
I
will
just
close
this
pull
request
right
after
this.
C
If
I
go
and
see,
a
new
pipeline
run
is
up
and
running
because
a
event
comes
to
this
event,
listener
event
listener,
and
then
it
it
it
it.
It
recognizes
that
pull
request
and
it
fetches
all
the
information
from
the
trigger
information
to
trigger
binding
and
given
to
the
trigger
template,
and
finally,
it
created
the
power.
For
me
I
mean
this
pipeline
run
from
the
trigger
templates.
A
A
C
C
D
A
Yeah,
so
maybe
that's
something
we
can
talk
about
offline,
but
what
would
be
very,
very
cool
is,
is
to
be
able
to
trace
from
the
pipeline
execution
what
has
started
from
the
git
repo
so
like.
If
it's
a
pr,
I
click
on
the
pipeline
learn,
and
I
have
a
direct
link
to
the
pr
to
to
understand
what
code
has
been
merged,
and
you
know
these
things
that.
A
C
A
A
C
D
D
Then,
if
you
like
to,
we
have
the
tech
tone
deep,
dives,
a
series
of
online
event
when
an
instructor
will
do
a
deep
dive
on
tecton
and
the
material
for
learning
tecton
is
a
is
the
other
one
I
put
in
also
in
the
chat,
so
those
are
two
valuable
assets
that
red
dot
developers
offer
to
start
learning
openshift
pipeline
and
checked
on
on
top
of
openshift
and
kubernetes
and
yeah.
I
just
wanted
to
to
share
our
resources.
A
Yeah
very
good
yeah,
very
good
okay,
so
thank
you
very
much
again
to
everyone
savita
crab.
It
was
a
great
session
thanks
natalie,
for
being
always
such
an
awesome
host
and
asking
great
questions
so
in
the
next
sessions.
I
hope
you
know
we
will
be
able
to
cover
these
things
that
we
discussed.
Like
you
know,
maybe
this
suggestion
how
to
trace
back
to
to
code.
If
it
comes
in
one
of
the
upcoming
screens,
I
will
speak
about
it
also
with
with
samara.
Well.
D
B
D
A
Yeah,
perfect
and
so
yeah,
so
I
was
going
to
say
so
again
as
a
you
know,
wrap
up
thanks
a
lot.
We
already
have
good
topics
to
cover
for
the
upcoming
sessions
we
will
see
for
august
11.
Maybe
we
can
speak
about
the
new
feature
called
pipeline
as
code
really
like
we
can,
where
we
embed
a
text
on
in
the
git
repository,
and
then
we
automatically
trigger
that
based
on
those
events.
So
that's
another
further
step,
but
we
first
wanted
to
show
this
thing
before,
because
this
thing
runs
now.
A
The
pipeline
s
code
is
in
depth
preview,
but
we
will
speak
about
it.
Definitely
and
we
will
I'm
very
interested
in
the
custom
interceptor
thing,
because
I
I
like
to
tweak
things-
and
I
have
some
some
very
good
ids.
You
know
the
custom
interceptor
can
do
what
we
said.
It
can
pull
the
data
from
the
pull
requests
and
it
can
add
a
label
to
the
pipeline
run
to
have
the
url.
So
that's
very
simple
use
case
we
can
do
already
and
then
we
can
see
integration
with
servicenow
or
whatever.
A
So
thanks
a
lot
thanks
again.
Thank
you
very
much.
Thanks
for
everyone
who
connected
on
the
stream,
thank
you
very
much
natalie
for
setting
this
up
and
making
sure
that
everything
runs
smoothly,
and
thank
you,
of
course,
avita
and
karam,
and
we
hope
to
have
you
next
in
other
episodes,
and
I
wish
everyone
a
great
day
and
we
are
going
to
to
to
end
the
session
now
thanks
and
see
you
on
august
11,
then
thank
you.