►
From YouTube: Pipeline-Authoring SIG Weekly Meeting
Description
Pipeline-Authoring SIG Weekly Meeting for Jan 31th, 2020
Agenda:
- Open items from the previous meeting
- Personas
- Other use cases
- Next steps
A
Welcome
welcome
welcome
to
the
pipeline
authoring
sig.
This
is
January
31st,
and
this
is
the
revitalization
of
this
sig
and
I'm
Mark
II.
Everybody
else
is
on
the
line.
We
think
we
all
pretty
much
know
each
other,
but
for
anybody
watching
this
recording
we
meet
weekly,
it
is
on
the
community
calendar.
A
B
A
B
Last
time
we
were
talking
about
what
we
wanted
to
do
want
to
discuss.
We
were
sort
of
spinning
back
up
some
of
the
old
notes
and
getting
sort
of
trying
to
figure
out
and
I
think
we're
still
gonna
be
doing
this
this
time.
What
we
want
to
do
these
were
the
open
tasks.
I,
don't
know
if
marki
I
felt,
like
you
had
the
actually
you
and
Steven
both
had
much
larger
tasks
to
do
in
terms
of
what
to
do
this
time.
So
you
do.
Did
you
to
run
through
creating
a
persona,
doc
or.
C
A
C
B
C
Definitely
started
thinking
about
it
didn't
create
any
artifacts
for
it.
Okay,
I
think
that
accent
ties
in
to
what
we
were
talking
about
last
time
with
the
Charter
and
talking
about
the
high
level
grandiose
visions,
so
yeah
I
certainly
have
things
to
say
that
I
think
it's
probably
gonna
be
a
lot
of
recap
those
what
we
talked
about
last
time.
We
have
a
new
perspective
on
the
call
today,
so
I'd
be
interested
to
hear.
D
D
Again
so,
if
I
understand
correctly,
I
think
this
may
be
actually
something
I've
thought
a
lot
about.
One
of
the
problems
that
I'm
running
into
in
the
workplace
is,
although
the
company
has
spent
a
lot
of
time
and
expertise,
learning,
Jenkins
and
and
in
particularly
I've,
you
know
some
become
a
contributor
people
think
that
writing
pipelines
is
hard
and
so
they're
talking
about
moving
to
things
like
circle,
CI
or
Travis
CI,
just
because
I
think
Jenkins
is
hard
and
first
of
all,
I
mean.
D
D
B
B
B
Now
the
weird
thing
is
now
I,
don't
know
if
you've
seen
this
happen,
but
like
I
find
that,
like
yes,
sir
circle,
CI
Oh,
it's
super
easy
and
then
they
start
trying
to
do
things
and
they
can't
the
the
the
issue
is
that
we
sort
of
Jenkins
as
a
whole
sort
of
throws
all
the
complexity
at
us
will
at
once,
and
so
you
end
up
feeling
like
it's
harder.
Then
then
the
other
thing,
but
the
other
thing
that's
just
as
hard
once
you
try
to
do
the
thing
that
we're
trying
to
do
yeah.
C
C
It's
like
not
a
level
grass
when
you
talk
about
complexity,
to
ease
right
with
Jenkins,
it
gets
easier
as
your
pot,
you
have
more
complex
situations
and
that's
where
Jenkins
starts
to
shine
bright
circle
me,
I
or
Travis
might
be
ideal.
If
your
pipeline
is
run
one
command
or
something,
but
the
second,
you
need
to
start
interacting
with
external
resources
or
dealing
with
multiply
component
applications.
D
C
A
lot
of
the
time,
I
think
a
lot
of
times.
A
challenge
is
that
people
don't
have
a
good
mental
model
for
how
Jenkins
works
or
how
pipelines
work.
So
when
you
throw
them
into
it
at
the
beginning,
they
sort
of
feel
like
they
have
to
know
how
to
code,
and
they
have
to
understand
what
steps
are
available
and
how
to
figure
out
the
syntax
for
them
and
there's
there's
all
these
challenges.
So
it's
really
about
like
how
do
we
help
them
build
that
mental
model?
C
D
So
what
one
of
the
suggestions
that
one
of
my
old
old
managers
had
that
he
thought
would
would
make
Jenkins
easier
as
if
there
was
a
set
of
of
samples
for
building
different
types
of
things
and
and
and
maybe
there
is
but
like
if
you
could
go
somewhere
to
a
repository
or
some
documentation,
and
it
says:
okay,
if
you
wanted
to
build
an
NPM
project,
here's
what
you
do!
If
you
want
to
build
a
go
project,
here's
what
you
do!
D
A
Ahead,
goodnight
overhead
Marquis
I
know
that
in
the
other
see
especially
the
docks,
Zig
they're
doing
a
lot
of
work
and
we're
finding
the
docks
are
how
the
docks
are
laid
out.
One
of
the
examples
you
gave
for
10
p.m.
how
to
build
a
simple,
a
sample,
NPM
project
and
there
is
an
actual
documentation
on
how
to
do
that.
A
I
think
what
happens
is
most
users
will
come
in
at
a
beginning
level
and
do
these
beginning
sample
steps
but
quickly
go
to
intermediate
and
there's
no
good
handoff
documentation
wise
to
show
how
to
go
from
beginner
to
intermediate
okay.
Great
I
can
now
set
up.
You
know
a
basic
NPM
project,
but
now
how
do
I
add
things
to
that
project?
There's
no
good
way
to
to
do
that.
Handoff
and
I
find,
especially
in
a
lot
of
the
questions
that
get
asked
and
getter.
A
B
C
C
Mean
so
I
I've
had
to
write
a
lot
of
learning
labs
for
various
frameworks
like
how
maintain
and
what
I'm?
What
I'm
finding
is
that
people
will
walk
step
by
step
through
documentation
to
get
something
minimal
working
without
pausing
to
understand
the
steps
of
what's
going
on
right
and
then
they
get
to
an
end
of
it
and
they
have
something
that
works,
but
they
they
didn't
actually
learn
the
the
basics
that
the
documentation
was
trying
to
teach
you
right.
So
whenever
you
have
copy
and
paste
the
bull
working
examples,
people
copy
and
paste.
C
C
But
if
someone
see
something
they
can
copy
and
paste
they're
gonna
copy
and
paste
it
and
then
figure
out
how
to
modify
that
right,
which
speaks
to
the
fact
that
people
are
struggling
to
build
mental
models
because
they
don't
understand
yet
how
all
the
pieces
they
copied
are
are
actually
working
together.
I'm.
A
Wondering
knew
it
makes
sense
in
future
meetings
to
actually
maybe
skip
like
maybe
do
one
meeting
a
month
where
we
do
like
a
walk
through
and
encourage
people
to
come.
Like
hey,
we're
going
to
show
you
how
to
build
a
go.
You
know
job
in
a
pipeline
and
and
I
bet
you
we
would
get
a
lot
of
people
that
would
would
come
to
that.
We
should
we.
B
B
Okay,
let's
run
through
this
together
and
see
how
that
works,
and
then
have
one
of
us
go
to
the
like:
go
do
a
sorry,
Jenkins
online
meetup
or
something
where
you
actually
have
that
and
then
run
through
that
again
right
for
a
larger
just
audience.
Here's
here's
the
example
right.
Yeah
I
like
having
having
this
groups
like
be
part
of
part
of
the
the
engine
that
generates
the
the
Doc's
that
we're
talking
about
seems
great
to
me
and
yes,
having
a
video
would
be
great
I.
C
C
If
we're
talking
about
this
from,
like
a
user
centered
design
perspective,
and
we
want
to
do
interviews
with
our
stakeholders
like
we're
almost
too
familiar
with
it,
to
know
what
what
knowledge
we
take
for
granted
all
right
so
seeing
a
beginner
tried
to
work
through,
it
would
probably
show
us
a
lot
more
about
what
the
challenges
actually
are.
Now.
D
A
I'm
also
wondering
I
know
one
of
the
things
that
we
talked
about
in
our
last
meeting,
which
would
be
good
towards
personas,
and
the
Charter
is
to
get
a
survey
out
and
to
really
start
to
put
a
get
a
pulse
on
what
the
community
is
is
having,
and
you
know
what
I'll
tell
you
what
you
could
put
an
action
item
for
me.
I
will
draft
up
a
survey
and
then
I'll
give
it
to
the
to
the
team
to
look
at
and-
and
we
can
see
you
know
what's
good
and
send
something
out.
D
A
Point
because
at
least
one
of
the
goals
that
I
have
for
this
SIG
is
to
start
to
be
able
to
generate
items
that
people
are
able
to
use
and
and
find
value,
and
that's
something
where
you
know
we're
trying
to
help
author
for
them.
So
I
would
love
to
be
able
to
have
data
to
know
that
we're
working
in
the
right
direction,
and
not
just
it's
for
people
who
know
Jenkins
really
well,
we
take
advantage
of
some
of
the
things
that
we
find
hard
that
other
people
may
find.
A
B
C
A
C
Down
a
pie
chart
of
of
the
challenges
that
people
are
hitting,
how
frequently
is
it
that
they
misunderstood
the
pipeline,
syntax
versus
an
infrastructure,
related
problem
of
they're,
trying
to
do
something
with
node,
but
they're
building
doesn't
have
node
installed
or
like.
In
my
experience,
a
lot
of
the
challenges,
people
running
two
or
more
platform
related
than
actual
pipeline
code
related?
D
A
similar
experience,
so
I
I
kind
of
I
see
two
things
on
I.
I
do
see
that
a
lot
I
mean
people
are
like
Oh,
Jenkins
is
broken
and
you
look
at
it.
Well,
Jenkins
just
runs
tasks.
No
Jenkins
isn't
broken
your
your
misconfigured.
The
other
thing
I
see
is
people
not
really
understanding.
All
of
the
things
that
Jenkins
has
to
offer
like
I
see
people
instead
of
using
credentials
they
they
have
an
environment
variable
it
has
a
user
and
password
in
it
and
their
jobs
they
just
they
just
don't
know
that
credentials
exist.
D
D
Somebody
was
like
using
curl
to
do
rest
things
because
they
didn't
know
that
there
was
a
plug-in
that
lets
so
a
lot
of
us
just
people,
just
not
knowing
what's
available
and
I
I,
don't
know
either,
but
when
I
want
to
do
something
new,
the
first
place.
I
look
as
the
the
plugins
the
plugins
site,
so
just.
A
A
A
maintainer
of
plugins
I
have
a
love-hate
relationship
with
plugins,
uh-huh
and
and
and
to
touch
on
what
you're
talking
about
yeah.
The
the
reason
that
I
do
is
I
find,
and
especially
with
your
slack
example,
you
gave
because
I've
had
this
happen,
uh-huh,
there's
a
reliance
on
a
plug-in
and
I
think
a
lot
of
people
don't
understand
that
that
plug-in
is
maintained
by
volunteers
yeah,
and
that
means
it
may
not
be
up
to
date.
A
So
I
have
found
that
in
my
personal
professional
dealings
that
I
like
to
write
something
out
code
wise
and
not
rely
on
a
plug-in
every
time,
mainly
because
if
the
plug-in
fails
for
some
reason
and
people
have
gotten
used
to
the
functionality,
I
need
to
be
able
to
give
that
back
to
them.
Instead,
I
have
to
go,
you
have
not
have
to
go
read.
You
know,
write
code
for
that
plug-in,
so
a
good
example
would
be.
You
know,
durable
tasks
and
how
that
sometimes
breaks
the
docker
agent
so
using
a
docker
file
and
I.
A
B
Oh
yeah,
no
I
as
someone
whose
maintained
a
Jenkinson
since
14,
like
that,
that's
exactly
the
same
philosophy
that
I
ended
up
with
where
it's
like.
Okay
I
could
do
this
with
the
plug-in,
but
I
might
you
know,
because
of
where
we're
at
I'm
not
going
to
because
I
need
this
feature
or
the
like
I
need.
I
need
people
to
actually
know
how
this
works
so
or
I
need
to
know.
How
do
you
have
more
control
over
it
right?
It.
A
D
But
part
of
it,
too,
is
not
not
just
the
fact
that
they're
that
they're
doing
it
outside
the
plugin,
but
if
you,
if
you
set
programmers
that
know
a
little
bit
of
groovy
to
the
task,
they
just
create
these.
These
monstrous
hierarchies
of
infrastructure
around
something
that
could
be
one
line.
I
could
probably
find
some
examples,
but.
C
C
A
B
B
A
B
Didn't
like
it
in
a
document
yeah,
and
even
if
you,
even
if
you
don't
feel
like
it's
in
great
shape,
it's
it's
better
to
just
have
something
that
we
can
sort
of
play
around
with
agreed,
agreed
that'll
be
out
today:
okay,
I,
don't
even
really
put
that
on
here.
That's
the
thing
put
that
in
here
no
I
started:
writing
okay!
B
B
B
B
This
is
one
example
of
I
wonder
whether
or
not
moving
moving,
not
moving,
but
basically
providing
people
with
the
Yambol
version
of
the
the
declarative.
Syntax
would
would
make
them
think
more
in
terms
of
don't
think
less
in
terms
of
it
being
groovy,
but
I
don't
know
that
that
would
help,
because
we're
still,
we
still
have
shared
libraries
where
it's
like.
Oh
you
can
do
this
thing
and
it.
D
B
Most
of
what
people
do
in
that
context
is
could
be
done
anywhere
right,
like
if
you're
talking
about
hey,
I'm,
I,
I'm
gonna,
write
myself
a
slack
step
right.
There's
no
need
for
for
that
to
happen
on
master.
It
could
happen
anywhere
right
as
long
as
you
as
long
as
you
pass
the
right
information,
then
then
then
you're
fine,
it's
that
fair.
So.
D
C
B
B
You
know
for
loop,
crazy
stuff
inside
of
there
inside
of
a
node
block
and
they
think
well
obviously,
that's
running
on
the
nodes
like
no,
it's
not
mm-hmm,
it's
not
running
on
the
agent,
it's
running
in
master
and
you're,
just
doing
a
bunch
of
work
while
you're
holding
on
to
your
agent,
the
worst
of
all
possible
worlds.
Exactly
so,
there's.
B
Nothing
that
specifically
stops
it,
except
for
the
hundred
million
gotchas
that
that
about
around
assumptions
right
about,
like
oh
I'm,
gonna,
run
this
thing
and
I
expect
that
this
variable
that
I,
that
I
declared
at
at
the
top
of
my
pipeline
is
gonna,
be
there.
Well,
it
wouldn't
be
there
if
it
was
running
on
on
the
age
unless
we.
D
But
you
could
have
shared
groovy
that
exposes
a
snap
like
I'm
thinking
about
the
the
build,
the
build
plugin
step
that
that
we
use
to
build
our
plugins
does.
Does
that
actually
end
up
running
on
the
agent
and
muss
it?
Basically,
it's
a
step
that
returns
a
pipeline
I'm,
not
sure
so
some
of
it
has
to
because
it
runs
on
like
it
does
a
Windows
build
in
a
Linux
build.
D
B
Okay,
so
that's
not
a
step,
though
that's
that's
the
shared
library
that
calls
that
is
still
running
on
master
eventually,
there's
like
that
that
turn
I
heard
if
I
want,
if
you
want
I,
could
go
pull
that
up,
but
basically
that
that
is
that's
a
shared
library
method
that
gets
called
and
then
that
runs
submit
some
code
and
eventually
that
calls
some
steps
that
do
like
something
on
agents
right.
But,
okay,
maybe
it's
worth.
D
D
B
In
fact,
absurdly
saying
we're,
not
gonna,
do
it
in
groovy
we're
gonna
say
you
know.
Anything
inside
here
goes
on
to
an
agent
and
have
some
way
of
transferring.
You
know
the
little
bit
of
data
that
people
usually
want
between
those
two
things
new.
This
is
too
far
afield,
but
it's
I
guess:
I
you're
you're
talking
about
crazy,
groovy
scripts,
which
got
me
thinking
about
yeah.
We
saw.
D
This
is:
can
we
guide
people
off
the
end
of
that
odd
ramp,
so
I
I
can
I
could
give
you
a
another
example
of
crazy
groovy
libraries.
So
I
was
on
reverse
engineering,
a
pipeline
that
one
of
our
mobile
apps
uses
that
it
wasn't
working.
It
uses
a
bunch
of
shared
libraries
and
I
started,
like
digging
into
it,
and
I
found
something
several
layers
in
that
uploaded
code
coverage
to
a
confluence
page
for
another
app.
So
so,
every
time
you
ran
any
any
Android
build
or
iOS
build
that
that
usually
shares
shared
libraries.
D
They
would
contribute
code
coverage
to
a
specific
app,
even
though
it
was
a
different
app,
and
that
happened
because
the
the
team
that
owned
the
app
that
was
doing
code
coverage,
they
said
well,
we'll
put
it
in
a
shared
library,
even
though
that
that's
was
used
by
everybody
and
it
happened
because
I
think
somebody
copied
their
pipeline.
It's
like.
Oh,
this
is
working
I'll
just
copy
this
pipeline,
and
so
that's
kind
of
the
sorts
of
things
that
I
mean
with
these
like,
like
crazy
groovy.
D
B
A
C
A
Think
one
of
the
things
that
I
I'm
gonna
speak
for
myself,
I
won't
speak
or
generalized,
but
one
of
the
things
that
I
do
is
if
I
go
and
I
copy
something
I'm
only
using
that
as
a
vehicle
of
under
for
understanding.
So
I'd
like
to
try
to,
unlike
you
were
saying,
Steven
I
personally
like
to
try
to
understand
what
is
happening
with
what
I'm
looking
at
or
why
it's
doing
this
and
how
it's
doing
it,
because
essentially
I
want
the
knowledge
to
build
my
own
thing
and
not
just
take
somebody's.
A
D
A
But
see
the
aliens
are
real,
noting
the
part
that
is
making
that
difficult
is
because
companies
are
especially
competitors
with
paid
products
or
attacking
open
source.
As
Jenkins
is
the
problem
when
it
truly
hey,
they
shouldn't
be
tacking
attacking
open
source,
but
that's
their
marketing
arm
and
I,
get
it
yeah
yeah.
A
C
You
get
when
you
get
to
a
specific
scale
at
some
point,
you
have
a
centralized
team
that
helps
manage
it
for
people
and
it
really
becomes.
How
do
I
configure
my
pipeline
instead
of
build
it
so
there's
definitely
a
significant
portion
of
the
community-
that's
probably
represented
when
in
one
of
our
personas
that
do
not
need
to
know
how
Jenkins
works.
They
need
to
know
how
to
consume
the
pipeline
and
maybe
configure
it
with
certain
parameters
or
different
libraries
or
whatever,
but
I.
A
Well,
I
think.
We
also
think
that
the
met
expert
is
right.
What
do
we
define
as
an
expert
and
I
think
that
that
speaks
to
what
you're
describing
Steven
is
we
for
pipeline
authoring
have
to
make
it
easy
enough,
so
that
the
persona
of
expert
who
knows
how
to
write
groovy
code
can
consume
it
and
the
persona
of
expert
who
it
just
needs
to
be
able
to
tweak
or
configure
or
just
consume?
What
is
already
there.
A
D
D
A
A
B
Maybe
based
on
the
personas
but
I
wonder
if
we
have
like
organization
organization,
another
lifecycle
of
an
of
a
jenkins
org
right
of
other
Jenkins
pipeline
right,
because
you
can
kind
of
see
like
people
start
with
okay
I'm,
just
this
one
person
I
do
this
pipeline
and
then,
like
Stephen,
was
saying
they
moved
to
having
a
central.
You
know
having
having
a
Jenkins
person
that
does
does
these
things
and
then
having
it
gets
big
enough
that
there's
an
organization
that
now
does
that
right.
C
Yeah,
it's
really
hard
to
take
off.
My
plugin,
maintain
our
hat
and,
like
my
life,
focuses
around
that
large
scale.
Adoption
type
of
thing
so
I'm
trying
to
remember
the
first
time,
I
wrote
a
pipeline
and
what
it
was
like
when
your
scale
was.
You
know
an
individual
app
team,
but
I
I'm,
usually
the
devil's
person
supporting
like
16
micro
services,
built
by
different
development
teams
across
different
companies
like
so
I
I
sort
of
live
in
a
different
world
than
I'd
say
a
lot
of
a
lot
of
Jenkins
users
end
up
having
to
I
know.
B
It's
the
thing
that
I
was
where
I
was
going
with.
That
was
just
that.
There's
a
this
is
again
we're
back
to
that
on-ramp,
where
we
there's
there's
both
a
front-loading
of
that
difficulty,
because
people
like
I'm
a
beginner
I,
don't
know
what
I'm
doing.
Okay
I
got
something
work
copy
and
paste,
and
then
we
actually
guide
them
into
that
scripting
space.
That
Jeff
was
talking
about
which
makes
their
life
later
on
harder
right.
B
A
Have
a
document
later
on
after
this
meeting,
I'll
put
it
in
the
channel
and
well
I.
Think
what
you're
describing
liam
is
something
that
we
created
at
Yahoo,
and
this
was
called
the
it's
called
the
continuous
delivery
maturity
model.
Where
I
talks
about
like
what
the
culture
and
the
organization
is
it
starts.
It
starts
off
like
what
the
initial
view
looks
like
what
the
manage
view
defined,
quantitive,
managed
and
then
optimized,
and
then
it
talks
about
all
these
blocks
in
the
lifecycle
of
that
model.
A
So,
like
its
top
says,
like
teams
are
based
on
platforms
and
technologies.
The
build
and
release
is
like
infrequently
and
unreliable
manual
processes,
and
it
goes
through
how
you
get
to
these
different
steps.
I'll
share
that
document,
because
I
actually
have
it
and
it's
it
I
think
that's
part
of
the
public
domain
now,
but
I
think
that
would
help,
because
it's
describing
very
very
much
what
you're
talking
about
with.
C
Okay
and
I
think
that
the
personas
that
we're
gonna
generate
as
part
of
this
there's
some
opportunity
for
the
collaboration
with
big
Doc's
right
like
it
would
be
fantastic
if
you
go
to
the
doc
site
and
it's
organized
per
by
persona.
So
like
people
of
different
levels
and
directed
to
different
levels
of
in-depth
documentation
based
upon
our
and
there
are
anticipation
of
their
needs,
which
is
never
going
to
be
perfect,
but
might
be
a
little
bit
easier
than
it
is
now.