►
From YouTube: Reuse CI/CD configuration using YAML functions
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone-
this
is
dave
hershkovis
from
the
pipeline
authoring
team.
Today,
I'm
going
to
walk
you
through
a
quite
popular
issue
that
we've
implemented
in
13.9,
which
is
a
way
to
select
any
ci
cd
configuration
section
from
any
job
or
any
file
and
reuse
it
within
your
own
job.
So
the
concept
of
reusing
and
sharing
subset
of
your
pipeline
configuration
is
something
that
we
have
always
working
toward
improving.
A
So,
for
instance,
with
a
with
include,
you
can
take
a
very
long
pipeline
file,
break
it
into
multiple
file
and
then
include
it
as
a
part
of
your
pipeline
configuration
and
with
the
extent
you
can
take
a
job
that
you
already
created
and
extend
it
with
some
other
scripts
or
some
other
commands
that
you've
included
from
a
different
file.
And
the
thing
about
this
issue
is
that
you
cannot
only
use
the
use
it
you.
You
cannot
only
reference
to
a
specific
section
in
your
pipeline
configuration.
A
It
is
merging
those
keys
alongside
your
own
configuration
and
I'll
explain,
because
previously,
what
we've
done,
we've
override
with
other
idols
keys
and
this
issue
actually
originated
or
came
in
different
variations.
Mainly
around
yaml
configuration
yaml
ankles.
The
idea
is
that
we
will
keep
getting
asked.
A
So,
for
instance,
if
I
have
this
simple
setup,
a
simple
pipeline
configuration
I'm
declaring
the
yamal
ankle
setup
script
as
a
set
of
those
scripts
and
the
teardown
script
as
a
set
of
those
scripts
as
a
part
of
those
two
jobs,
and
when
I'm
writing
a
new
job,
I
can
reference
to
a
specific
sections
or
reference
to
the
ml
anchors,
and
it
will
result
like
this.
The
script
of
the
test
job
will
first
run
the
the
setup
script,
because
I've
referenced
to
the
yama
lancome
setup
setup
script.
A
Then
it
will
run
this
command
and
then
the
till
downscript,
so
it
is
merging
those
two
together.
This
is
nice,
but
actually
what
users
would
like
to
do
is
to
have
those
two
jobs
in
a
different
file
and
then
include
those
files
as
a
part
of
your
pipeline
configuration
and
with
the
aml
anchors.
We
do
not
support
it
because
when
we
merge
the
file,
the
python
configuration
that,
after
we're
doing
the
include
when
we
are
processing
the
the
pipeline,
we
are
merging
it
into
one
big
one,
big
merch
file.
A
We
are
dropping
those
those
ammo
ankles,
so
for
us
we
cannot,
we
cannot
use
it.
This
is.
This
is
how
it
works
today.
So
when
we
came
to
implement
this
requirement,
we've
decided
that
we'll
use
a
different
method
which
is
yaml
functions
and,
let's
just
remove
this
part
for
a
second.
Let's
continue
with
with
the
example
that
I
just
show
you
so
I
have.
What
I've
done
is
that
I
took
those
two
files
and
so
those
two,
those
two
scripts
or
jobs
and
put
it
in
different
different
files
and
simply
include
them.
A
Okay
and
I
can
reference
reference
to
a
key,
so
the
setup
job
within
the
setup
and
the
script
key
and-
and
this
is
the
till
down
and
the
scale,
because
if
I
look
at
the
setup,
I
can
see
that
we
have
a
simple
script
and
the
tilde.
We
have
a
simple,
a
simple
script
and
it
will
result
in
exactly
what
I
just
explained
is
that
we
will
run
first,
the
setup
script,
then
my
own
script
and
then
the
till
down
script.
A
I
can
hit
the
commit
wait
for
the
pipeline
to
run
and
look
for
the
look
at
the
output,
but
I
can
also
look
at
this
cool
feature
that
we
also
released,
which
is
the
view,
merge,
yaml,
and
I
can
see
this
is.
This-
is
how
I'm
seeing
the
extended
the
fully
extended
yaml
configuration,
as
I
mentioned,
when
we
merge
it
together
into
one
big
file.
This
is
what
it
resolved.
A
So
you
can
see
that
the
this,
the
include
of
the
setup,
wrote
me
this
script
and
the
include
of
the
teardown.
I
can
see
this
script,
but
what
I'm
really
looking
for
is
the
actual
test
job
which
is
running,
which
should
run
when
I
will
click
on
the
commit
change,
and
you
will
see
that
it
will
run
first
of
all
the
scripts
form
from
the
setup
job,
then
my
own
command
and
then
escape
from
the
tilde.
A
Okay,
exactly
what
I
wanted
and,
as
I
mentioned,
one
of
the
benefits
for
using
the
yama
the
yaml
functions
is
that
we
can
reference
any
key,
so
it
doesn't
have
to
be
escaped,
doesn't
have
to
be
only
it
can
be
like
before
escape
after
script
rules
variables,
and
it
can
also
go
to
as
many
depth
as
I
want.
So,
for
instance,
if
I
have
a
job-
and
of
course
I
can
include
this
job
in
a
different
file-
then
include
it
here.
A
As
a
part
of
my
pipeline
configuration
and
it's
this
job,
I
have
two
variables,
the
url
and
the
important
vowel
variable,
and
in
this
job
the
test
var
was
one.
I
can
reference
the
entire
a
variable
section,
and
basically,
what
this
job
will
do
is
that
it
will
pre-populate
those
two
variables
into
here.
So
if
I'll
look
at
the
view,
melchio
I
can
see
this-
is
it
sees
exactly
this.
So
this
is
the
job
that
I've
looked
at
and
you
can
see
that
it
is
just
reference
or
import
those
two
variable
variables
into
this
script.
A
But,
as
I
mentioned,
I
can
go
to
as
many
depth
as
I
want.
So
I
can
reference
not
only
the
entire
field.
I
can
reference
a
specific
key
so
here
in
the
test
valve
2
job,
I'm
referencing,
the
vowel
job,
the
variable
field
and
the
url
variable
and
declare
it
as
a
part
of
my
vowel
myvar
one,
I'm
referencing
this
variable
and
my
valk3
is
a
variable
that
I
just
configured
and
the
result,
as
I
mentioned,
will
be
like
a
merged
configuration.
A
A
So
obviously,
this
is
very
helpful
for
teams
that
would
like
to
collaborate
and
create
a
set
of
scripts
or
configuration
in
in
one
shared
repository
and
then
ask
other
teams
to
reuse
that
same
pipeline
configuration
as
the
as
a
part
of
their
own
jobs
and
and
pipelines,
and
just
so
this
is
it,
and
as
always,
if
you
have
any
thoughts,
questions
and
feel
free
to
reach
out
to
me,
or
at
mention
me
on
an
issue.
Thank
you.