►
From YouTube: Jenkins Pipeline-Authoring SIG Meeting for 20200417
Description
Jenkins Pipeline-Authoring SIG Meeting for 20200417
A
A
Devon
is
bum
and
ass
Foster.
This
meeting
is
being
recorded.
If
you
don't
want
to
be
recorded,
please
feel
free
to
drop
off,
and
this
we
are
also,
of
course,
following
the
code
of
conduct,
the
Jenkins
code
of
conduct,
which,
basically
just
is
everyone,
be
excellent
to
each
other,
and
let's
get
going
let's
here,
we
have
actually
two
open
items:
Marky,
let's
go
with
yours.
First,
we.
C
C
So
if
there
is
no
negative
feedback,
what
I
would
like
to
move
forward
in
the
next
action
item,
which
would
be
for
me,
is
to
update
our
sig
landing
page.
That
says
the
you
know.
Fourth,
Friday
of
every
month
we
do
a
road
map
walkthrough,
just
you
know,
and
I'll
I'll
put
verbage
in
there
that
essentially
states.
This
is
what
we're
doing
on
the
fourth
Friday
of
every
month
and
then
I
will
go
and
update
the
calendar.
The
events
calendar,
so
everybody
will
know
what
we're
doing
on
the
fourth
Friday
of
every
month.
C
C
What
tell
me
more
so
if
you
look
down
when
we
discuss
the
road
there,
the
road
map
focus
areas
ideal.
What
will
come
out
of
that
will
be
a
story.
There
will
be
a
story
that
you'll
be
working
on.
So
common
is
an
example.
One
of
the
stories
that
I
find
very
interesting
is
better
pipeline
development
in
an
IDE.
A
great
example
would
be
the
G
DSL
in
IntelliJ.
C
That's
something
I
would
like
to
work
on
so
in
this
monthly
cadence
I
would
come
and
say
for
the
last
month,
I
had
these
tickets
or
odd
years
that
I've
created
for
tasks,
and
this
is
what
I've
got
done
and
you're
basically
just
giving
an
update.
We
don't
go
and
I
spec
them
in
detail
and
and
code
reviews,
we're
not
doing
that.
It's
just
giving
sort
of
a
a
sig
state-of-the-union
if
you
got
it.
Thank
you.
Okay.
Thanks
for
the
clarity.
A
D
C
And
that's
what
we
don't
want
it
to
be
right
right.
You
just
want
to
keep
it
sort
of
on
the
fence
or
we're
focused
more
on
the
roadmap,
but
at
the
same
time
we're
not
turning
a
blind
eye
to
people
that
are
opening
issues
for
things
that
are
pipeline
authoring
centric.
So
that
may
be
the
time
where
somebody
raises
an
issue
and
says
I
feel
this
belongs
in
this
sig.
We
can
then
say
it
doesn't
fall
into
these
focus
areas,
but
it
would
in
this
sea.
Could
you
address
it
there?
C
I'll
wait
24
hours
to
see
if
I
get
any
feedback
from
that
and
then
by
the
end
of
the
weekend,
or
maybe
even
I'll,
wait
till
Monday
I'll
then
go
ahead
and
put
a
PR
in
to
update
the
sig
landing
page
and
I
will
tag
not
only
the
copy
editors
but
everybody
in
this
sig,
so
they
have
a
chance
to
say
that
they
were
a
part
of
that
review
process.
Oh.
A
B
A
A
What
the
that's
that's,
the
point
at
which
what
we're
doing
sort
of
the
students
did
the
sake
and
if
new
things
come
in,
that's
where
we'll
start
them
up
right,
that's
correct!
Okay,
from
last
time,
my
task
was
to
create
JIRA,
create
queries
which
I
did
not
get
to
a
issue.
Come
in
that
I
have
been
wrangling
for
this
past
couple
days.
I
wasn't
sure
that
I
was
clear
last
time
and
at
least
I
want
to
clarify
here,
I.
A
A
C
So,
as
we
were
talking
about
the
roadmap,
we
were,
one
of
the
things
we
were
trying
to
do
is
really
highlight
the
focus
areas
that
pertain
to
pipeline
authoring,
and
we
really
wanted
to
start
to
now
drill
down
and
did
our
persona.
We've
talked
about
the
maturity
model.
Now
we
want
to
start
drilling
down
into
what
those
focus
areas
are
so
a
couple
of
the
ideas
that
we've
put
forth.
C
There
are
things
like
pipeline
development
and
IDE
that
could
be
a
focus
area,
syntax
improvements,
pipeline
testing
there
there
were
there,
maybe
even
could
be
one
or
two
more
that
we
could
do,
but
what
I
wanted
to
start
when
we
address
these
focus
areas
is
start
to
say,
okay,
what
is
it
that
you
may
want
to
do
in
that
focus
area,
because
that
becomes
part
of
what
the
roadmap
is?
For
example,
the
pipeline
development
I
know
that
one
of
the
one
of
the
deficiencies
that
currently
exists
is
in
the
G
DSL
there.
C
So
in
doing
that,
I
saw
that
that
would
be
a
good
focus
area
to
put
forth
to
the
community,
and
everybody
say:
yep
I
would
love
that
I
feel
that
that's
beneficial
to
the
authoring
of
a
pipeline
and
then,
as
we
go
down
to
some
of
these
other
areas,
syntax
improvements,
pipeline
testing,
unit
testing
and
things
such
as
that
and
then
overall
documentation.
What
I
wanted
to
do
was
put
these
forth
to
the
community
and
get
a
consensus
of
a
is
this
beneficial
that
we've
highlighted
here?
B?
C
A
I
will
say
these
are
basically
like
these
are
so
far
just
following
along
the
for
the
you
know,
focus
areas
that
are
listed
on
the
cig,
landing
page,
so
I
mean
there's
I,
think
there's
at
least
two
or
three
more
there,
but
the
if
anyone
wants
to
sort
of
throw
things
out
here,
I'm
looking
at
you
mark
in
terms
of
the
documentation
of
course,
but
you
know
just
I,
guess:
I'll
start
there,
there's
at
least
two
or
three
syntax
improvements
that
I
can.
Think
of.
A
That
would
be
that
people
have
asked
for
that,
that
we
can
make
two
declarative
pipeline.
That
will
that
are
that'll,
be
a
big
boon
for
people
and
I.
I
know
if
at
least
one
that
was
an
improvement
for
matrix,
that
I
filed
just
the
other
day
and
there's
a
couple
others
in
terms
of
execution
or
during
execution,
doing
a
case
where
you
call
it
switch
case,
basically
for
a
set
of
stages.
A
D
So
the
the
challenge
there
is
authoring.
Those
examples
usually
means
writing
an
HTML
page
in
plugin
document
in
plugin
source
code
and
we're
already
struggling
to
get
people
to
write
without
making
them
also
do
HTML
markup
on
this
documentation.
They're
creating
so
examples
are
a
challenge
and
better
documentation.
D
B
That
there's
common
scenarios
that
exist
that
I
and
this
might
exist
already,
but
I
could
imagine
going
to
the
doc
site
and
being
like
I,
can't
even
think
of
a
good
example,
but
like
here's,
a
common
task
I
would
want
to
do.
You
know
it
requires
two
or
three
plugins.
Where
do
you
store
that
sort
of
you
skate
example?
Those.
D
Are
those
are
great
because
we
put
those
in
as
as
how-to
or
as
as
we
give
them
a
page
on
Jenkins
at
I/o?
We
offer
them
an
ASCII
doc.
We
can
put
pictures
in
it's
it's
a
much
easier
authoring
experience.
Actually
if
we
can
get
outside
of
the
single
single
keyword
case,
so
Stephen
I
think
your
your
point
is
very
good
and,
and
those
cases
are
very,
very
much
suited
to
put
them
on
Jenkins
that
I/o
post
them
there.
B
Do
we
have
a
backlog
of
how
to's
that
we
know
come
up
a
lot
that
we
would
like
to
write,
but
haven't
gotten
around
to
yet
like
I
could
see
that
being
maybe
a
good
first
use
case
for
someone
to
get
involved
with
contributions
like
if
I
knew
that
there
was
a
backlog
of
articles
that
could
be
written.
I
could
take
like
45
minutes
to
write
one
up
and
do
it
pretty
quickly
or
something
like
that.
Let
me
know
it's
good.
D
Very
good
suggestion
there
is
not
such
a
backlog
currently
I
think
what
we
ought
to
do
is:
let's
create
ourselves
an
epoch
for
in
JIRA
for
pipeline
authoring
or
for
documentation
improvements,
and
then
we
can
start
inserting
them
into
that
epoch.
That,
then,
is
an
easy
place
to
hook
into
the
roadmap
and
display
it
on
the
roadmap
that
hey
authoring
improvements
are
coming
here.
People
then
click
through
the
roadmap
link
and
see
yes,
here's
the
current
progress
on
those
on
those
that
epic.
B
D
A
A
Be
nice
if
we
had
a
little
boilerplate
for
this,
but
basically
every
time
someone
asks
a
question
on
a
question
on
Gator
or
these
things
that
we
can
have
if
we
had
a
boilerplate
which
you
just
you
know,
drop.
Okay,
hey,
can
you
add
a
JIRA
for
this
so
that
we
or
because
it
basically
if
it
becomes
something
that
we
have
to
do
or
that
we've
have
to
follow
to
make
happen?
It
that's
difficult
when
you
see.
C
B
Was
gonna
say
that
I
think
that
this
would
be
a
great
opportunity
to
add
new
contributors
right
if
someone
asks
a
question
and
get
her
or
through
the
feedback,
and
we
take
time
to
give
them
a
really
detailed
answer
and
help
them
get
to
a
solution
and
then
be
able
to
say.
Like
you
know,
this
is
a
great
opportunity
to
become
a
Jenkins
contributor.
Here's
the
the
ticket
that
corresponds
to
like
how
to
how
to
actually
write
a
how-to
page.
Take
the
information
that
we
provided
in
this
Gator
channel
or
whatever
form.
B
This
is
and
then
format
it
as
a
how-to
article
right,
because
you
constantly
have
this
funnel
of
trying
to
lead
people
to
become
contributors
to
help
collectively,
maintain,
write
and
a
lot
of
people
don't
know
how
to
get
started.
So
I
could
see
a
common
entry
point
to
becoming
a
contributor
you
getting
a
lot
of
help
from
the
community
us
having
a
how-to
page
for,
like
literally
how
to
write
a
how-to
page.
We
pasted
that
to
them
after
we're
done,
helping
them
answer
their
question
and
then
say,
like
here's,
a
great
opportunity
to
get
started.
C
C
Let's
say
with
a
pair
of
socks
from
you,
know,
jinkin
socks
or
something
like
that,
and
we
have
that
ability
in
the
advocacy
group
to
reward
people
and
when
you
post
about
stuff,
like
that
on
social
media
and
others,
see
it
they're
like
oh
man,
that
was
that
easy
for
them
to
do
I
want
to
get
involved.
Then
we
start
really
filling
that
pipeline
see
how
I
did
the
whole
pipeline
thing.
I'm,
wrapping
that
all
up
here,
I.
B
Love
it
okay,
I
think,
visibility
on
social
media
is
a
huge
incentive.
The
Dacian
for
people
like
it's
just
sort
of
human
nature
that
there
needs
to
be
something
in
it
for
them
to
get
some
involvement.
Sometimes
right
invisibility
through,
like
the
Jenkins
CI
Twitter
account
retweeting,
something
you
did
might
be
enough
to
get
people
over
that
initial
starting
hesitation.
B
C
C
B
I've
used
I've
used
the
Jenkins
Spock
library
with
some
success,
so
the
framework
developed
I
think
goes
Austin,
whit
back
when
the
Stig
actually
got
initiated
that
that
does
some
really
clever
stuff.
Under
the
covers
lets.
You
do
right
Spock
tests
for
your
Jenkins
pipelines.
Then
you
can
test
shared
libraries
and
I've
used
that
pretty
extensively
and
it
works
pretty
well.
Okay,.
B
So
real
quick
on
testing
they're
sort
of
all
right.
We
want
to
apply
the
same
kinds
of
testing
we
do
during
software
development,
pipeline
development.
Theoretically,
so
Jenkins
Spock
is
like
unit
testing.
You
don't
have
to
run
the
Jenkins
test,
harness
or
anything.
It's
just
mocks
everything
and
you
can
do
like
interaction-based
testing
I
think
the
next
level
up,
for
that
would
be
real
integration
testing,
where
we
create
some.
Some
helpers
inside
that
Jenkins
test
harness
to
do
integration,
testing
right
so
Jenkins
Spock.
B
B
Made
the
mistake
once
of
writing
so
I'm,
a
plug-in
maintainer
I
wrote
way
too
much
code
before
executing
it
in
a
Jenkins
pipeline
and
I
got
one
of
those,
not
serializable
exceptions
and
there's
opportunities
for
improvement
in
the
the
logs
that
are
output.
To
tell
you
exactly
what
thing
causes
exception,
so
I
had
to
crawl
through
a
way
more
code
than
I
should
have
to
find
the
root
cause
of
that
I.
Don't.
C
B
Yeah,
like
I,
could
imagine
a
scenario
where,
like
instead
of
you,
know,
usually
people
that
are
using
that
test,
harness
or
plugin
developers
that
are
trying
to
test
the
classes
within
their
plugin.
But
I
could
see
us
creating
the
facade
that
leverages
the
same
thing
to
create
actual
pipelines
that
you're
running
so
some
helpers
to
load,
shared
libraries
and
then,
like
you,
the
test
harness
to
actually
execute
a
pipeline,
a
test
pipeline
to
see.
If
it's
going
to
work.
As
you
expected,
you.
A
B
I
think
you
can
do
everything
you
need
to
with
the
test
harness
today.
I
think
my
suggestion
might
be
more
around
exposing
a
user-friendly
facade
or
having
some
tutorials
for
people
to
understand
how
they
would
use
the
test
harness
to
test
their
pipelines
and
because,
if
you
go
to
look
up
how
to
use
it,
you're
you're
probably
going
to
find
yourself
looking
at
unit
tests
for
plugins.
So
this
is
sort
of
a
different
use
case
of
a
framework
that
already
enables
you
to
do
these
things.
B
E
No
difference
on
you:
what's
your
like
something
more
like
jackets
found
runner,
that's
built
almost
the
same
way
as
a
test
harness,
but
has
some
special
methods
or
something
I,
don't
know,
I,
don't
know.
If
you'd
want
to
build
this
into
the
test
harness
itself
or
maybe
you
could
have
some
library
that
depends
on
the
test,
harness
that
adds
additional
stuff
right.
B
A
B
Think
either
it's
a
good
idea.
I
think
we
could
create
an
extension
of
the
test
harness,
so
it's
maybe
packaged
outside
of
it
and
consumes
it,
but
Jenkins
Hall
runner
would
work
too
it
might.
It
might
be
less
performant,
because
you'd
have
to
like
spin
up
a
new
master
for
each
each
pipeline.
You
want
to
test
I'm.
Definitely
not
an
expert
at
this,
so
I
defer
to
you
to
tell
me
which,
which
is
a
better
idea.
I'm
just
thinking
there.
E
E
B
A
B
C
A
A
A
A
B
A
Yes,
that's
that's
sinning
I
thought
of
I've
got
some
notes
somewhere
around
for
this.
The
thing
the
yeah
I
do
a
dry
run.
Now
what
what
declarative
does?
Is
it
actually
says
it,
because
you're
doing
it
actually
can
analyze
the
whole
pipeline
as
it
starts,
it
says,
hey
I
noticed,
there's
a
new
parameter
if
there's
a
default
for
that
parameter,
it'll
use
it.
A
A
B
Wonder
if
you
could
augment
the
input
step
two,
because
right
through
input,
you
can
provide
information
to
a
running
pipeline.
I,
wonder
if
you
could
like
I
know.
The
better
solution
would
be
to
figure
out
how
to
figure
out
parameters
before
you
run
the
pipeline.
But
if
that's
a
huge
refactoring,
maybe
you
could
augment
the
input
step
to
pop
up
when
that
properties
block
is
found
to
take
some
to
figure
out
what
those
parameters
were.
B
A
E
I
think
they're,
like
fixing
this
is
probably
actually
going
to
be
extremely
difficult
right,
just
because
it's
like
not
the
way
Jenkins
it's
designed
to
work,
but
one
thing
that
I
think.
If
so
many
people
are
hitting
this
enter
confused
by
it.
Maybe
we
could
change,
we
could
try
and
like
intercept
errors
that
are
thrown
when
these
parameters
are
missing
and
declarative
and
try
and
check
and
say,
like
oh
well,
the
property
step
was
used,
but
this
parameter
isn't
here.
E
B
And
I
also
give
a
take
of
what,
if
we
just
remove
that
functionality
like
if
it's,
if
it's
causing
more
confusion
than
it's
causing
value,
why
don't
we
advise
that
you
use
Jenkins
configuration
as
code
or
job
DSL
to
configure
your
your
job
parameters
and
just
take
it
out
of
pipeline,
because
it
has
so
many
issues
associated
with
it.
I
don't
know
if
I'm
advocating
for
that
I'm
just
throwing
it
out
that
like
if
we
zoom
out
there
is
another
alternative
here
which
is
stop
supporting
that
I.
A
Not
properties
here,
but
I
want
to
just
sort
of
bring
this
up
as
one
as
another
item
that
that
would
be
on
the
list
of
things
to
sort
of
figure
out
or
do
something
that
you
know
improve
in
some
way,
because
it's
a
it's
a
pain
point
for
people
off
when
they're
authoring
their
pipelines,
even
if
and
I
think,
even
if
it's
just
a
message,
like
you
said,
intercepting
the
errors
and
and
giving
a
clear
message.
That
would
also
be
a
huge
improvement
because
then
people
know
what
happened
right
so.
B
C
A
F
A
Can't
they're
not
particularly
dynamic,
and
thank
you
for
mentioning
that
I
we
keep
thinking
of
this
in
terms
of
okay
within
this
one
job,
but
a
lot
of
people
run
these
most
the
the
way
that
we
actually
suggest
people
run
run
pipelines
as
via
a
multi
branch.
So
that
would
let
that
would
let
us
have
a
job
that
runs
both
how
they
have
something
that
rut
is
running
and
doing
things
before
that
pipeline
launches
and
if
they're,
if
you're,
using
declarative
than
you
could
actually
be
able
to
know
beforehand.
A
C
C
B
The
only
static
code
analysis
might
be
an
interesting
one,
a
challenging
but
interesting
one,
because
I
I
see
a
lot
common
mistakes
that
are
seen
formulaic
enough,
that
you
should
be
able
to
catch
them
through
linting.
The
the
first
example
that
always
comes
to
mind
for
me,
for
this
is
like
someone
calls
a
node
block
and
then
they
call
like
file
exists
or
they
try
to
read
a
file
in
the
workspace
and
they
never
like
checked
out
a
SCM
or
they
unstaffed
anything,
and
they
have
a
distributed,
build
architecture
right.
B
So
there's
no
guarantee
that
the
file
you're
expecting
to
be
there
is
actually
going
to
be
there
on
the
same
node.
Alright.
So,
first
of
all
does
that
example.
It
make
sense
like
if
I've
got
three
build
agents
and
I
like
checked
out
my
code
in
one
node
block
I
called
another
node
block
and
tried
to
do
something
with
that
code.
B
There's
no
guarantee
that
that
those
files
are
still
there
so
that
I
see
that
issue
all
the
time
and
it
causes
a
really
tricky
problem
for
people
to
solve,
because
it'll
work,
sometimes,
but
not
all
the
times.
If
you
get
lucky
in
the
next,
node
block
uses
the
same
agent
as
the
first
one
everything's
your
pipelines
going
to
work,
but
if
it
uses
a
different
one,
it's
going
to
fail
so
from
a
static
code.
Analysis
being
like
you
called
a
node
block
and
then
you
call
it
a
step.
A
B
B
B
Don't
know
if
I
have
enough
examples
of
that
to
be
worth
doing
it,
so
maybe
maybe
the
first
step
there
would
be
thinking
through
what
those
rules
would
even
look
like
to
see.
If
there's
enough
of
them
to
justify
it
like,
we
would
have
to
have
an
opinionated
quality
profile
or
set
of
rules
that
we
declare
best
practices
that
we'd
want
to
warn
people
about
I.
Think.
C
That
the
person
that
takes
up
this
work,
at
least
for
this
particular
thing,
I,
think
they
started
at
an
opinionated
level
and
then,
as
they
put
forth
to
the
community,
what
their
opinion
is
is
where
people
will
all
of
a
sudden.
Oh
no
I've
got
feels
about
that.
I
want
to
do
it
this
way.
That's
what
generates
the
conversation.
F
Through
plugins
I
looked
into
it
a
while
ago,
I
didn't
actually
end
up
going
with
it,
but
you
can
extend
some
of
the
declarative
model
validators.
So
you
could
do
something
crude
like.
Oh,
you
don't
have
a
post,
cleanup
step.
I
think
the
only
option
you
have
is
to
heart
fail
the
build,
but
it
will
come
up.
You
need
a
cleanup
step
and
they
go.
Oh
I'll
add
one
of
those.
Then
I.
B
A
A
Are
there
any
places
where
someone
is
using
a
death
variable,
if
so,
I'm
not
safe
to
do
the
sort
of
the
closure
construction
to
make
this
happen
to
fix
the
code
to
large
error,
but
if
they
aren't
then
great
and
I
go
into
a
bunch
of.
I
generate
completely
different
code
with
classes
and
closures
to
work
around
that
code
to
large
limitation
in
the
java
class
binary
file
structure.
So,
but
if,
as
long
as
we're
in
declarative,
we
can
do
some
of
that
at
least.
B
E
If
you
don't
really
care
about
groovy
code,
only
pipeline
steps
and
things
like
that
and
you're
okay,
with
only
trying
to
catch
errors
after
the
build
happens,
you
can
always
look
at
the
flow
graph
to
understand
like
what
happened
in
terms
of
pipeline
steps,
and
maybe
that's
like
a
good
enough.
We're
figuring
out
some
kind
of
lengths
that
are
specifically
around
step
usage.
B
That's
interesting,
I
feel
like
people
get
in
trouble
when
they
write
a
lot
of
groovy
code.
So
there's
a
lot
of
places
where
that
would
be
helpful.
I
do
think
that
there's
a
lot
of
opportunities
for
people
that
are
going
and
doing
some
more.
Let's
call
them
creative
pipelines
to
identify
some
some
best
practice,
I
alation
I'm,
definitely
guilty
of
creating
creative
pipeline.
We.
C
B
Here's
all
the
methods
that
got
called
and
stuff
like
that,
so
it'd
have
to
be
a
little
bit
of
a
mature
dry
run
right
like
if
it's
a
closures,
you're
gonna
have
to
have
to
keep
that
closure.
Instead
of
just
seeing
that
there
was
an
invocation
of
something
that
takes
a
closure
parameter,
but
I,
don't
know,
that's
right
run.
Might
give
you
an
opportunity
to
do
the
same
thing
for
scripted.
So.
A
And
as
I
think,
I
was
saying,
and
if
you
were
here
last
nona
saying
where
the
gaps
are
for
declarative
is,
where
is
also
what's
interesting,
is
like
there's
something
that
that
you
can't
do
in
declarative.
That
should
be
that's!
That's
definitely
where
that
syntax
improvements
comes
in,
so
so
we're
at
about
10
minutes
to
the
end.
I
think
we've
got
a
good
list.
Was
there
anything
else
that
we
wanted
thanks
for
bringing
up
static
code
analysis
cuz?
A
A
F
A
If
you
can
drop
a
link-
and
that
was
an
interesting
point
like
that-
we
have
this
whole
system
for
running
things
in
Jenkins
that
was
based
around
when,
when
it
was
freestyle
jobs,
you
had
trees
or
jobs.
So
why
are
we
not
doing
more?
You
know
leveraging
that
that
facility
right
is
that
that
that
what
you
were
sort
of
pointing
at
yeah.
F
A
B
B
F
A
And
did
I
I
would
like
to
discuss
this
further,
but
I
think
we
should,
when
we
put
this
on
the
agenda
for
next
time,
people
can
read
over
it
and
kind
of
delve
into
it,
and
we
can
do
a
little
bit
of
emailing
back
and
forth
and
sounds
good
yeah
I
mean
it
definitely
sounds
interesting.
I'm,
not
an
off-the-cuff
I'm,
not
opposed
it's
more.
Just
like
okay.
What
is
what
falls
out
of
this
and
I?
Don't
know
what
that
is
yet
I
added
a.