►
From YouTube: Pipeline Authoring Sig Meeting 1/24/2020
Description
Pipeline Authoring Sig Meeting 1/24/2020
First sync in 2020 to set the cadence for the year. Meeting notes can be found at https://docs.google.com/document/d/1EhWoBplGl4M8bHz0uuP-iOynPGuONjcz4enQm8sDyUE/edit#
A
B
So
a
lot
jenkins
world
I
spoke
to
Co
sky,
about
trying
to
revitalize
this
special
interest
group,
which
is
near
and
dear
to
my
heart,
and
he
recommended
I
reached
out
to
the
two
of
you.
So
we
did
that
on
get
her,
and-
and
here
we
are
so
I
thought
that
we
should
at
least
like
revisit
focus
areas.
Try
to
identify
like
why
did
this
is
allow
in
the
first
place.
B
A
B
B
Obviously,
declarative
is
probably
the
primary
and
most
commonly
used
framework
for
developing
pipelines
at
this
point
as
a
simple,
easy
user
interface
for
developing
pipelines,
so
I
think
the
general
theme
of
this
was
really
around
developer.
Experience
for
Jenkins
pipeline
is
code
in
all
the
forms
that
that
might
involve
so,
including
things
like.
How
can
we
make
static
code
analysis
easier,
and
how
can
we
make
it
easier
for
people
to
identify
issues
in
their
pipelines
before
they
blow
up
in
production,
different
tools
that
might
make
it
easy?
It's
like.
B
C
So
here's
the
here's,
the
thing
I.
Actually
it
was
an
interesting
I,
don't
know
if
you
guys
at
you
guys,
weren't
in
Lisbon
and
I
gave
a
talk
on
pipeline
what's
going
on
with
declarative
and
was
interesting
from
because
one
of
the
more
pointed
Q&A
sessions
afterwards
of
people
asking
like
when
is
this
feature
can
happen.
When
is
that
happen,
and
and
also.
C
C
Well,
I
mean
I,
think,
there's
a
there's,
a
sort
of
a
trade-off
here
on
one
side.
We
want
this
to
be
a
vibrant
community.
You
want
it
to
be
people,
you
know
making
it
you
things
and
it's
forward,
but
at
the
same
point,
the
more
there's
a
there's,
also
a
counterbalance
that
of
do
less
in
pipeline
right
of,
like
pipelines,
should
be
the
glue,
not
the
not
the
workhorse
right
and
I
guess.
C
So
the
question
that
had
is
is
sort
of
like
is
more
developer.
Tooling
really
I
mean
it's.
What
people
are
saying
they
want?
Is
that
what
they
really
need,
and
is
that
really
where
we
want
to
go
and
they're
not
saying
like
not?
Do
it
on
mortars
like
I,
want
to
kind
of
maybe
make
sure
that
we're
working
on
the
same
assumptions
right.
B
Yes,
yeah
excellent,
all
right
so
yeah,
I
I,
think
a
charter
might
be
I
think
seems
maybe,
like
a
charter,
might
be
a
little
overkill
until
we
really
know
those
the
vision
that
we
have
like
I
I,
think
that
you're
you're
right
on
the
right
track.
Liam
we're
like
we
want
to
make
pipeline
development
simple
right,
your
pipeline
shouldn't.
If
you
can't
build
your
application
without
your
pipeline,
your
pipeline
is
probably
doing
too
much
right
from
from
a
I.
Don't
know
best
practices
perspective
purists
about
it.
B
So
it's
really
in
my
opinion,
about
how
do
we
make
the
abstractions?
You
know
the
right
way,
so
that
pipeline
development
is
simple,
so
developer
experience
doesn't
mean
that
we
make
it
more
complicated
and
we
add
a
bunch
of
tools
in
there,
so
that
people
can
do
more
advanced
things
it's
more
about.
How
do
we
make
it
easier
to
do
powerful
things
simply
like
I'm,
trying
to
break
out
of
my
life,
jte
hat
that
I
always
have
on
my
head?
B
But
thinking
of
the
Jenkins
selling
engine
is
like
it's
an
abstraction
for
making
pipeline
simple,
and
how
can
we
apply
that
with
or
without
JT
like
it
declarative
declarative
took
over
so
well,
because
it
was
a
simple
facade
on
top
of
a
complex
pipeline
DSL.
So
when
I'm
thinking
developer
experience,
I'm
thinking
like
how?
How
can
we
make
pipelines
that
scale.
A
B
C
I
kind
of
feel
the
same
way
about
debugging
right
I
mean
I
like
if
they're
to
me,
anyways,
philosophically
I,
I'm
kind
of
I've
pushed
back
against
debugging,
just
like
well,
if
you're
doing
declarative,
you
really
don't
want
to
debug
that
and
I
mean
I,
don't
know
it's
it's
it's
also
just
it's
the
kind
of
problem
that
we
could
spend
a
lot
of
time
on
and
I'm,
not
sure
that
it's
where
the
biggest
like
as
an
example
of
debugging
is
answer.
That's
where
that's
the
biggest
gain
in
experience
like
in
positive
experience
right,
one.
A
Of
the
things
that
I
think
this
is
critical
is
identifying
well
when
we
think
of
a
charter
right
I
think
we
have
to
have
a
charter.
Okay,
Charter
has
to
be
defined
that
we
know
what
the
Charter
problem
it's
trying
to
solve,
but
in
order
to
know
what
problem
we're
trying
to
solve
with
also,
we
need
to
know
the
person
we're
trying
to
solve
the
problem
for
so
I'm
wondering
if
it
makes
sense
too
before
we
do
that
start
to
create
personas.
A
So
we
kind
of
know
who
our
users
are,
because
if
we
have
a
new
user,
that's
never
really
used
Jenkins.
They
don't
know
what
you
know
what
they
don't
know,
but
we
have
somebody
that
sort
of
intermediate
they
may
have
used
somebody
else's.
They
don't
know
what
they
don't
know
and
if
there's
somebody
advanced,
you
know
they
may
have
an
opinion
but
they're
not
looking
at
it
from
the
new
user
or
an
immediate
intermediate
user
I.
B
Think
that
makes
sense,
I
think
along
along
those
veins,
there's
also
like
scale
personas,
which
is
sort
of
how
I
think
about
it.
You
know
the
needs
of
a
person
running
a
pipeline
for
an
individual
application
are
different
from
like
a
central,
dev
ops
team
that
helps
support
CI
CD
for
multiple
teams
simultaneously.
All
right.
A
B
That
make
sense
when
I'm
thinking
about
making
pipelines
easier
I,
you
know
I
love
the
pipeline
syntax
tool.
I
would
love
it
more
if
it
was
in
my
IDE
right
so
little
things
like
that
like
how
do
we?
How
do
we
make
it
easier
for
people
to
figure
out
the
right
syntax
without
having
to
go
to
the
Python
syntax
tool
and
it
slowly
or
I
know?
A
B
Yeah
I
mean
I
sorry
I'm
on
a
dev
ops
team
as
part
of
a
huge
company
and
I
see
all
the
common
problems
that
people
new
to
Jenkins
hit,
and
it's
things
like
the
static
code
analysis
could
help
with
like
you
have
a
distributed,
build
architecture
and
you
you
did
a
file
exists,
but
you
never
unstaffed
or
checked
out
any
files
right.
So
sometimes
that
codes
gonna
work.
B
If
you
got
lucky
and
it
ran
on
the
same
node
place
other
times,
it's
not
going
to
so
like
there's
some
common
patterns
that
are
detectable
from
a
code
standpoint
that
could
lead
to
unreliable
pipeline.
But
the
number
of
those
those
cases
are
probably
not
large
enough
to
justify
an
entire
like
static
code,
analysis
and
ever.
B
There's
some
interesting
stuff
to
with
like
Jenkins
file
runner
like
I
know
that
project
started
up
I,
don't
know
if
it's
still
in
development,
but
how
can
we?
How
can
we
run
mock
pipelines
locally
without
necessarily
needing
a
real
application
to
be
testing
against
just
to
make
sure
that
everything
is
going
to
work
as
expected,
like
Jenkins
Spock
got
us
to
mock
like
machina
testing?
Is
there
anything
that
can
get
us
to
integration
testing
without
a
full,
fledged
Jenkins
Vince.
C
Jacobs
pal
Runner
is
effectively
a
full-fledged
instance
right.
It
is
maintenance
right
so
yeah,
but
I,
but
what
you
mean
by
that
is
by
not
speeding
up
a
whole
new
server
or
whole
new
I.
Don't
know
what
I
don't
know
where
how
you
want
to
distinguish
that,
but
a
long-running
drinkin's
as
opposed
to
a
ephemeral
one.
B
B
So
maybe
we
just
start
with
like
our
first
couple
meetings,
our
interviews
with
the
community
like
instead
of
the
three
of
us,
trying
to
figure
out
who
are
all
probably
Jenkins
experts
sitting
down
and
trying
to
figure
out
what
the
problems
are.
It
would
be
interesting
to
get
people
together
and
talk
about
like
what
are
your
challenges
that
you're
having
and
that
the
people
you're
working
with
are
having
it's
sort
of
a
hard
problem,
because
the
people
that
are
involved
in
the
community,
or
probably
not
the
people
that
are
the
newest
at
it
all
right.
B
Quickly,
turning
the
port's
or
forum
right,
like
hey,
fill
out
this
survey
and
we
get
questions
are
like
I.
Have
this
specific
use
case
and
this
specific
problem?
How
can
Jenkins
make
my
use
case
easier,
yeah.
A
So
maybe
that's
something
you
know
that's
a
suggestion,
something
we
might
be
able
to
do
Mike
if
we
got
a
survey
together,
we
got
together
with
maybe
you
know
the
advocacy
group
and
Elissa
and
then
had
that
survey
go
out
and
then
sort
of
see
what
we
get
back,
but
we
would
need
to,
as
a
team
rarely
decide
what
the
questions
are
going
to
be.
If
we
went
that
route,
I
think
it
would
be
a
good
thing
to
do
because
it
gets
a
pulse
of
the
community,
but
I
totally
see
the
other
side
of
that.
B
B
So
maybe
we're
also
scoping
this
too
small.
Like
we're
talking
a
lot
about
the
pipeline
authors
experience.
Maybe
we
can
also
send
this
to
be
the
pipeline
consumers
experience
right.
My
role
is
frequently
I
build
a
pipeline.
The
dive
teams,
use
and
I
filled
a
lot
of
questions
from
developers
about
their
pipeline,
and
it's
always
things
like
the
pipelines
broken
I'm
like
well.
Your
unit
tests
failed
like
how
can
we
make
it
easier
as
a
consumer
of
the
pipeline
to
understand
exactly
what
went
wrong
and
why?
A
C
A
Well,
if
you've
got
it,
you
guys
are
okay
with
it.
One
of
the
I'm
gonna
take
an
action
item.
Look
I
start
drafting
up
between
now.
I
have
another
question,
but
I'll
say
between
now
and
our
next
meeting
I'm
gonna
create
a
new
doc
that
I
will
link
into
the
notes
here
at
some
points
this
weekend,
where
I'll
start
creating
the
personas
okay,
yeah.
C
C
Yeah
right
so
speaking
of
feedback
from
community,
we
had
at
least
at
least
one
and
I'm,
pretty
sure
I
got
a
link
to
another
one
from
a
year
ago
or
from
yeah
from
various
ones.
These
the
sort
of
pipeline
discussions
that
happen
at
Jenkins
world-
and
we
can
talk
about
those
some
to
those
I'll
say-
did
also
turn
into
hey.
I,
want
this
feature
or
hey.
There's
this
bug
a
lot
more
than,
but
at
least
in
in
Lisbon
the
interested
in
the
canal.
That
was
the
the
same
problem
was
actually
we
had
like.
C
It
was
a
bird
of
birds
of
a
feather
can
move
around
thing
and
the
same
thing
was
brought
up
two
or
three
times.
It
was
like
the
same
like
one
issue
and
it's
a
long-standing
issue
with
the
the
way
that
we
do
parameters
right,
anyways
point
there
was
the
thing
was
funny
about.
It
was
just
that
it
that
it
that
each
new
group
had
basically
started
with
that
same
thing,
so
you
get
I
think
we
have
some
things
that
we
can
address
that
are
like
oh
hey.
C
We
want
this
one
behavior
to
be
different,
but
usually,
though,
what
happens
with
those
like
for
in
this
case,
with
parameters
that
behaviors
is
the
reason
why
it
is
the
way
this
is
so
scent
is
buried
under
layers
that
we
dead
in
order
to
move
it
like.
It
involves
some
really
hard
thinking
about.
Okay.
What
exactly
can
we
do
right?
The
same
thing
happened
like
people
are
people
have
asked
for
hey
I,
say
not
the
second
most
common,
but
the,
but
certainly
one
of
the
top
top
ten
is
is
hey?
C
A
A
A
C
Except
for
all
right,
when
you
go
down
a
certain
distance,
for
instance,
when
you
get
two
steps,
are
the
steps
in
llamo?
Are
they
groovy
like
what
its
end
and
for
those
like,
even
discounting
the
script
block
like
when
you,
when
you
start
working
with
them,
the
the
step
itself
needs
to
be
written
sort
of
groovy
ish
like
we
could
kind
of
convert
them
to
a
certain
point
and
maybe
make
the
parameters.
But
then,
once
you
get
down
to
the
parameters
themselves,
they're
gonna
have
to
be
groovy
some
degree
of
groovy
at
some
point.
C
A
B
You
want
to
have
array
of
steps
that
run
inside
a
container
image
and
execute
some
script.
You
could
write
that
parser
and
like
a
day
right.
It's
just
iterate
over
the
yam
or
run
docker
image
that
inside
and
then
run
a
shell
script,
so
the
value
of
it
is
smaller,
but
for
those
that
don't
have
complex
pipelines
that
provide
some
value.
But
okay.
C
And
I'm
not
saying
we
shouldn't
do
this,
but,
like
as
an
example,
maven
has
supported
attributes
for
year
for
a
decade
now
right.
Nobody,
nobody
uses
it
like
everybody
wanted
it
and
nobody
uses
it.
It
would
make
it
would
make
all
your
maven
files
like
way
more
understandable
way
more
easy
to
read.
Nobody
like
it
isn't.
It
has
never
been,
never
gained
traction.
So
are
we
gonna
document
both
like
how
we're
gonna
show
are?
We
are
now
gonna
start
showing
yamo
for
our
pipeline
to
and
I'm
arguing
against
assembly.
C
B
Agree,
I
think
I
have
a
pretty
like
hard
lined
opinion
on
most
things,
and
my
take
on
this
in
general
is
like
listen.
If
you
just
learn
declarative
like
what
what
does
Jim
will
give
you
that
you
can't
do
it
declarative
right,
like
I,
don't
know
that
I
understand
the
actual
value
proposition
of
the
ml,
especially
when
you
start
to
look
at
like
how
easy
it
is
to
mess
up
indentation
in
the
ml,
and
then
we
have
a
whole.
This.
C
A
I
know
what
I'm
about
to
say
will
be
extremely
controversial.
Oh
please,
forgive
me
I.
Think
one
of
the
welcoming
facts
to
llamo
is
it
they.
Some
people
feel
the
the
bar
is
a
lot
lower
for
entry
to
newcomers.
Then
it
would
be
to
say,
learn,
you
know,
declare
to
you,
know
groovy
sort
of
syntax.
So
people
like
look
at
that
and
they
say
oh
I,
can
understand
ya
more
easier
than
I.
A
B
A
A
I'll
play
devil's
advocate
on
that.
Currently
we
have
in
in
the
Jenkins
dot
IO
site.
We
have
a
node.js
example
for
a
five
line
and
one
of
the
things
I
see
in
the
getter
channel
more
often
than
not
at
least
especially
the
last
week
or
two
is
two
people
that
cannot
get
that
running,
and
so
now
we
like
people
like
I
found
myself
and
a
few
others
are
answering
these
like
nodejs
questions
on
this
pipeline,
because
people
don't
understand
how
to
use
it.
B
Yeah
and
if
we
accompany
it
with
a
docker
file
that
spins
up
a
Jenkins
pre-configured
or
something
I
used
to
teach
programming
and
robotics
to
kids
and
over
the
summers
in
college
and
when
I
was
teaching
your
statement,
I
would
say
if
quotes,
condition,
and
you
don't
know
how
many
times
I
went
to
a
computer
and
they're
like
it's
not
running
and
that's
because
they
literally
typed
if
quotes
condition.
Oh
so
I
I.
Definitely
that
resonates
with
me
that
if
we
give
them
examples,
they're
going
to
be
our
major
source
of
support
tickets.
B
Oh
yeah,
like
okay,
so
the
docker
file
to
spin
up
an
already
integrated
sample
application
with
some
some
dummy
reference
architecture
pipelines
at
least
then
we
we
can
hope
that
as
long
as
you
have
doctor
installed
you're
going
to
get
the
properly
configured
instance,
that
has
everything
you
need
to
run.
These
examples.
B
Learning
lateral
right,
yeah,
there's
club,
there's
cloudBees
University
right
like
something
similar
on
the
open-source
side.
That's
like
here's,
a
scenario:
we're
gonna,
walk
you
through
it
in
cata
coda.
You
can
spin
up
a
jenkins
instance
as
part
of
the
environment
for
that
and
embed
it
in
the
documentation
site,
there's
overhead
there
and
there's
orchestration
and
it's
not
an
easy
lift,
but
there
might
be
another
like
learning
opportunity
for
people.
B
C
Of
the
one
of
the
first
things,
I
sort
of
was
looking
at
when
I
started,
advocating
talking
about
Jenkins
and
writing
blog
post
was
the
the
on-ramp
for
new
users
right.
So
this
is.
This
is
the
same
kind
of
thing
where
it's
like
look.
How
do
we
create
an
on-ramp
that
isn't
that
that
isn't
you
know
vertical?
It
needs
to
be
a
smooth
sort
of
transition
and
to
okay,
here's
this
thing
and
it's
like
now.
You
can
like
now
you're
up
to
this
level
right
so
I.
A
Think
in
the
creation
Arizona's,
you
have
to
also
have
some
type
of
handoff
/
persona.
So
that
way,
if
you
know
somebody
as
is,
is
that
the
beginner
I've
never
used
Jing
can
fight
now
have
to
or
I
want
to.
They
need
to
have
that
the
handoff
to
the
next
persona
should
also
exist
so
started
that
bridge.
B
A
A
B
Yeah
I
found
that
everyone
either
thinks
they're
a
beginner
or
thinks
they're
an
expert
right.
No
one
all
I'm
going
to
come
to
and
say
I'm
in
the
middle
of
the
road,
they're
gonna
say:
I've,
never
used
Ankush
before
or
I
know
everything
about
jacket,
I,
don't
know,
there's
NASA
and
out
of
that
statement.
But
that's
my
experience
with
trying
to
get
people
to
evaluate
their
readiness
for
a
different
topic.
A
C
A
B
Think
that
works
for
me,
my
schedule
is
like
a
roll
of
the
dice
given
different
client
sites,
I
meetings
just
pop
up
for
me
all
the
time,
it's
kind
of
hard
to
know
for
sure
I
can
try
to
be
strict
about
I'm,
not
accepting
a
meeting.
But
if
someone
says
you
have
to
go
meet
with
the
CTO
of
this
government
agency,
I
don't
have
mobility
well,.
C
I
mean
it'd,
be
the
other
thing
to
do
yours
just
and
then
I
can
push
things
around
and
say,
look
I'm.
This
is
important.
We
got
to
do
this
and
we
could
meet
weekly,
even
if
there
isn't
a
lot
to
do
like
make
the
time
and
show
up
and
then
like.
If
there
isn't
a
lot
to
talk
about
great
or
if
you
know
we
don't
have
the
ability
to
do
things
that
I
think
part
of
where
we
sort
of
fell
off
last
time.
I
can
talk
to
like.
C
Why
didn't
a
lot
they
just
because
because
the
meetings
were
far
enough
apart
and
we
were
trying
to
sort
of
both
the
ocean
as
it
were
so
yeah.
We
had
a
a
lot
of
different
things
to
look
at
and
a
long
time
between
meeting
some
people
sort
of
ran
off
to
do
with
it,
like
sort
of
oh
I
have
to
do
this
thing
here
out.
Lets
get
distracted,
so
I
also.
B
Of
someone
getting
a
presentation
on
something
that
they
had
done
and
not
as
much
as
talking
about
solutioning
so
I
think
there's
a
space
for
that.
Like
maybe
you
know,
every
third
Friday
or
something
we
try
to
bring
in
use
cases
for
people
are
so
off
like
examples,
it
might
be
thought-provoking
but
doing
it
every
time
because
it
just
becomes
something.
That's
easy
to
skip,
because
you'll
just
watch
the
presentation
later
right.
C
A
B
A
What
I'm
going
to
do
just
just
to
close
that
loop,
I'm
gonna,
move
the
meeting
I
think
we
have
set
for
weekly
right
now,
I'm
going
to
leave
it
for
next
Friday
same
time,
but
then,
following
that,
I
will
move
it
to
a
bi-weekly,
and
then
we
can
decide
from
there.
If
that's
you
know
it's
too
long
in
between
and
and
maybe
we
you
know,
we
work
in
in
get
er.
I
do
think
one
of
the
first
things
that's
gonna
be
critical,
for
us
is
the
personĂs.
B
A
C
A
C
C
B
B
B
A
A
A
C
A
And
one
other
thing:
we
oh
I,
I'm,
going
to
get
a
look.
I'm
gonna
get
two
emails
out.
I
will
revitalize
the
email
to
our
pipeline
off
cig,
saying
hey.
This
is
what
we're
working
on.
We
just
met.
Here's
a
link
to
the
recording
here's,
our
document
that
things
we're
gonna
work
on
I'm
gonna,
get
that
out
to
our
cig
emailing
list,
as
well
as
to
the
death
mailing
list,
okay,
cool,
and
that
way
we
can
see.
If
it
you
know,
drums
up,
excitement.
C
C
Right,
okay,
yeah!
This
is
more!
This
one
is
my
kids
I'm
like,
but
it's
already
here,
no,
it's
not
on
the
calendar.
I
already
did
it.
What's
that
yeah,
yeah,
okay,
alright,
so
got
it
and
all
it
will
keep
using
your
zoom
for
now.
That's
okay,
yeah.
C
A
So
so
here's
the
thing
I
am:
we
can
keep
it
hold
on.
Just
a
second
I
have
to
yell
something
Julie
check
into
your
flight.
It's
40!
Sorry!
B
A
This
video
to
YouTube,
okay
and
then
something
I
want
to
do
later
on
down
the
line
is
I
will
link
the
YouTube
and
create
automation,
so
it'll
automatically
upload
it
every
time
because
I,
don't
that's
what
I
do
for
another
community,
because
I
do
not
like
have
to
manually
upload
things.
I
want
it
to
happen.
Just
sort
of
gluto.