►
Description
Jenkins Pipeline-Authoring SIG Weekly Meeting for 20200410
A
Welcome
everyone
to
the
Jenkins
pipeline
authoring
sig
for
Friday
April
10th.
My
name
is
marquise
Jackson
I
am
one
of
the
leads
for
this
sig.
Thank
you,
everybody!
That's
coming
I
see
we
have
a
lot
of
names
here
that
are
new
and
that,
first
and
foremost,
is
awesome.
I.
Thank
you
so
very,
very,
very
much
for
participating
before
we
do
get
started.
A
If
you
could,
please
jump
on
there
and
add
your
name
to
the
attendees
list,
we
do
like
to
keep
attendance
just
to
know
who
showed
up
and
whatnot
all
those
fun
things
generally
what
we
do
when
we
start
this
meeting
for
the
new
people
that
are
here,
we
will
walk
the
meeting
notes
and
cover
anything
that
are
on
the
meeting
notes.
I.
Usually,
we
usually
turn
that
over
to
Liam,
so
Liam
I
am
actually
going
to
make
you
the
host
okay
with
the
most,
and
the
reason
for
that
is
is
because
that
will
allow
you.
B
B
That
without
take
it
away,
Liam
take
it
away
one
second
trying
that
there
it
is
there's
my
so
now
I'm
sharing
my
screen
and
everybody
see
the
blank
screen
there.
We
go.
Here's
the
docks.
B
A
Week
be
care
was
a
little
bit
crazy
and
chaotic
for
me.
I
will
work
on
that
between
now
and
the
next
meeting.
I
have
a
rough
draft
off,
but
I
did
not
feel
that
that
would
have
been
a
good
enough
job
to
put
up
because
I
think
would
have
been
like.
Why
are
you
putting
this
up?
There's
nothing
to
do
with
it.
So.
C
B
So
that's
the
stuff
from
last
meeting
we
can
for
this
meeting.
I
guess
talk
about
items
that
would
like
to
see
on
the
roadmap
that
we
think
that
you
good
on
there.
We
could
also
Craig
I,
welcome
you
here
and
I
guess
we
could
talk
about
the
in
topics
that
you've
been
bringing
up
in
get
er
here.
If
you
want
to
do
that
as
well,
I,
don't
know
if
you're,
unmuted
or
anything
or
if
you
have
I,
can't
actually
hear
you
if
you're
not.
B
D
B
B
B
I'd,
rather
not
actually
talk
about
this
in
terms
of
cloudBees,
this
is
a
Jenkins.
Admittedly,
there
are
I
mean
I
MacLeod,
B's,
employee,
but
I'd
rather
talk
about
this
in
terms
of
but
I'm
the
only
cloud
B's
employee,
currently
sitting
here
so
I,
the
sig
is
independent
from
that
it
exists
as
a
Jenkins
project.
B
C
A
Wasn't
finished
but
I
was
from
Craig.
I
was
not
okay.
Alright,
thank
you
when
you're,
defining
cloudy's
cloudBees
is
a
product.
Cobby's
does
not
dictate
the
charter
of
this
sig
and
they're
very
different.
So
that's
one
thing:
I
want
to
make
sure
that
I'm
very
clear
I'm,
not
a
cloud
based
employee,
the
charters
not
dictated
by
cloud
knees,
and
if
anybody
tried
to
dictate
that
from
a
company
standpoint,
my
guess
is,
is
the
board
would
get
involved?
It
just
wouldn't
happen.
Okay,.
D
So
I
mean
the
problem
that
I
have
is
that
this
technology
was
developed
by
cloudBees
employees,
while
they
were
working
for
cloudBees
and
unfortunately,
the
technology
itself
is
very
complicated
and
the
barrier
of
entry
is
very
high.
So
for
people,
if
there
are
people
in
the
community
that
can
come
in
and
keep
this
going,
that's
good,
but
some
of
the
problems
that
I've
had
with
pipeline
that
interfere
with
you
know
the
ability
to
write
and
author
pipelines
I
mean
the
only
people
that
really
have
the
knowledge
to
solve.
D
This
are
at
cloudBees
unless
there
are
people
that
can
come
in
from
the
community,
and
maybe
we
mentor
to
to
come
up
with
this,
so
I
mean
sure
if
you
have
a
roadmap
and
everything
that's
good,
but
there
are
some
fundamental
problems
with
pipeline
that
interfere
with
some
of
the
Charter
items
and
when
the
original
sig
was
developed
by
the
author
of
pipeline,
it
was
very
easy
to
say.
Oh
okay,
you
know
we
can
do
all
these
things
and
work
on
the
pipeline
because,
like
I've
raised
issues
from
like
two
years
ago,.
A
A
B
D
So
I'm
not
I'm,
not
against
the
Charter
I'm,
just
raising
the
issues
that
I
have
seen
and
the
problem
that
I
have
had
and
I'm
hoping
that
some
of
the
issues
that
I
could
I
have
raised
could
be.
You
know,
acknowledged
and
addressed
within
the
framework
of
this
of
the
sig,
because
from
my
perspective,
what
I
have
done.
I
found
problems
in
pipeline
and
I've
reported
the
bugs
on
JIRA
and
and
it's
and
some
of
the
issues
they
are
valid
issues
yeah.
E
D
They
you
know,
because
of
you
know,
issues
with
people
at
cloudBees,
I
mean
people
have
left
the
company.
People
have
moved
to
other
projects.
Some
of
these
issues
have
fallen
through
the
cracks
and
as
someone
who
I
don't
work
for
cloudBees,
but
I
used
Ekans
heavily
and
I.
Don't
have
the
technical
knowledge
to
address
some
of
these
problems.
D
Agenda
right,
they
were
like
to
what
I
consider
common
ones,
and
you
know
if
we
could,
you
know,
have
lists
of
bugs
and
pipeline
itself
that
are
tracked
through
this
say
you
know
even
if
they're
not
solved
tomorrow,
but
if,
if
there's
some,
you
know
movement
on
those
and
if
the
people
who
wrote
this
stuff
are
too
busy
to
help.
But
if
you
know
people
could
be
mentored
to
help
fix
these
problems,
you
know
from
my
perspective,
that
would
be
a
good
outcome
of
the
sake.
B
B
Craig
could
I
ask
you
to
mute
yourself
when
you're
not
talking
just
because
there's
otherwise,
there's
feedback?
Thank
you.
So
that's
that
exists
in
all
open-source
projects
and
I
understand
that
your
opinion
from
your
perspective,
there
aren't
there,
isn't
enough
technical
knowledge
outside
of
cloudBees.
To
do
this
work
I
would
say
that
there
that
there
also
isn't
there
isn't
enough.
B
They
they
are
predicated
on
there
being
more
resources
from
one
particular
area
that
you
would
like
focused
on
this
thing,
right
on
the
on
the
issues
that
you're
talking
about
I
I'll
pick
out
at
least
one
thing
that
you
said,
which
is
having
a
list
of
issues
that
that
are
of
interest
to
the
sig,
that
that
is
a
great
idea.
We
should
probably
do
something
like
that
where
we
can
actually
start
gathering.
B
You
know,
issues
and
pipeline
that
are
there
a
high
priority
or
just
a
of
interest,
also
having
a
list
of
issues
that
are
good
first
issues
for
people
to
work
on
one
of
these
that
you
brought
up
here,
the
the
need
for
the
linter.
That's
actually,
though,
and
we
talked
about
that
a
little
bit
where
it's
like
having
a
little
inter
a
you,
know
a
validate
now
button
in
the
UI.
B
B
If
you're,
just
I
guess
just
there,
what
I
should
do
set
expectation
if
you're
looking
at
this
SIG
as
a
as
a
venue
to
poke
cloud
bees
to
do
more
work
that
you
think
needs
to
be
done
in
Jenkins.
I,
don't
know
that
this
is
going
to
be
the
place
for
that
I.
Don't
think
you're
going
to
to
achieve
what
you're
looking
for
so.
B
We
need
someone
from
cloudBees
to
come,
give
a
presentation
or
decent
like
that.
We
can
probably
get
that
kind
of
resource,
but
just
pay
cloudBees
do
more
work
on
this.
It's
gonna,
be
me
not
it's
not
going
to
be
a
very
effective
way
to
go
about
it.
We're
not
gonna.
That's
not!
That's
not
going
to
be
always
an
outcome
for
this.
Yes,.
C
A
C
That
you
know
I
do
not
work
at
cloud.
Bees
and
I've
contributed
to
the
underlying
pipeline.
Plugging
your
pipeline,
groupie
workflow,
CPS,
the
workflow,
CPS,
groovy
library
and
I.
Definitely,
sympathize,
there's
a
high
technical
barrier
to
entry
and
it
sort
of
involved
just
getting
my
hands
dirty
and
diving
into
the
codebase.
I
would
just
say
that,
like
from
as
a
plugin
maintainer
to
like
it's,
not
that
no
one
wants
to
do
this
work
right.
It's
that
there
are
so
many
different
avenues
for
potential
improvement.
C
I've
got
seven
open
issues
on
a
repo
I
maintain
that
keeping
up
at
night-
and
it's
just
you
know-
bandwidth-
is
limited,
I
think
from
a
mentoring
standpoint.
This
take
is
sort
of
well
mentoring
might
not
be.
The
primary
point
is
sort
of
you
know
it
does
that
by
talking
about
these
issues-
and
maybe
if
there
are
people
on
the
call
that
have
that
experience
of
where
to
look,
you
know
we
can.
We
can
start
to
do
that
stuff.
But
I
just
wanted
to
echo
that
it's
not
that
people
don't
care
about
the
issues.
C
A
A
If
you
have
and
I'm
not
saying
you
I'm
more
saying
this
in
a
general
sense,
if
you
expect
people
or
if
individuals
expect
people
to
just
stop
and
focus
on
something
else,
we'll
never
get
anything
actually
done
and,
as
the
word
has
been
used
here,
it's
a
volunteer
organization.
I
personally
do
not
work
for
cloudBees,
so
we
have
to.
D
D
Yeah,
so
from
what
Liam
described,
I
think
that
is
a
if
this
thing
moves
in
that
direction.
I
think
that
would
be
a
good
outcome
for
the
same
because,
from
my
perspective,
I,
don't
care
who
solves
the
problem,
whether
it's
me
or
someone
from
cloudBees
or
someone
from
the
community,
but
on
the
other
hand,
yeah
I
can't
expect
cloudy
stew.
B
There
we
go
I
forgot,
I
was
muted,
so
I'm
gonna
just
take
a
couple
of
notes,
notes
get
there.
B
D
Two
things
so
the
thing
that
you
expect
that
you
can
poke
cloudBees
and
get
them
to
do
things.
That
was
not
it.
So
the
other
thing
that
you
mentioned,
which
is
I'm,
asking
you
to
help
me
so
I.
Can
you
take
it
out
so
provide
a
venue
to
bring
up
issues
and
ask
for
help
from
technical
domain
experts
to
mentor
and
help
fix
the
problems
like
whatever
you
said.
That
was
in
the.
B
Head
so
so
I
think
so
the
way
that
I'm
looking
at
this.
Let
me
just
see
here
to
notation
preferences.
B
B
D
A
A
B
Yeah
but
like
so,
this
is
okay,
improving
and
curating.
So
that's
that's
fair
I
think
it's
just
it
would
be.
It
might
be
helpful.
To
add,
add
this
so
that
we're
so
that
we're
talking
about
the
same
thing
so
that,
because
I
think
part
of
what
happened,
what
has
happened
with
from
my
perspective,
with
Craig
coming
in
and
asking
asking
about
these
bugs
was
that
there
isn't.
B
All
we
were
able
to
say
was
well
that's
not
in
the
Charter
right
and
what
he's
asking,
if,
if
we
say
well,
if,
instead,
what
we
had
in,
if
we
had
something
in
the
Charter
says
yes
you're.
We
are
totally
on
board
with
people
asking
about
technical
issues
in
pipeline
and
getting
help
with
working
on
them.
C
A
common
thing,
I
think
one
of
the
risks
of
opening
up
bugs
is
that
it
can
quickly
consume
the
entire
meeting.
But
one
thing
I
try
to
do
on
projects
that
I'm
working
on
it
and
my
job
is,
you
know,
dedicate
a
per
particular
percentage
of
capacity
towards
like
sre
or
continuous
improvement.
So
if
we
were
to
expand
the
charter
to
include
something
like
pipeline
bugs,
we
could
also
include
like
to
ensure
that
we
keep
making
progress
on
the
experience
of
running
pipelines.
C
B
A
A
A
question
Craig:
would
you
what,
if
we
thinking
about
that,
if
we
had
say
one
meeting
a
month
where
the
meeting
was
just
a
you
know,
a
focus
where
we
kind
of
like
I
know
in
other
communities
that
I'm
in
we
have
something
called
walk
the
board
and
we'll
do
that
once
a
month
where
we'll
actually
go
over,
whatever
the
project
board
is
or
whatever
issues
are
open
and
jeredy,
what
I
mean
in
injera
or
get
up
if
we
actually
did
that
once
a
month?
Would
that
be?
Would
that
be
good.
B
So
that
I,
just
I,
want
to
be
sure
that
were
clear
on
this,
though
tracking
it
doesn't
mean
that
they'll
get
worked
on
by
this
by
the
people,
in
the
sake
of
things
that
will
track
them
and
and
it
so
that,
if
someone
wants
them
with
to
work
on
the
need
to
come
in
and
will
help
at
least
provide
some
like.
Oh
okay,
you'll
need
to
look
here
here
and
here
to
work
on
that
or
something
right.
Yeah
yeah.
D
B
B
B
Doesn't
sound
whether
its
objection
so
yeah,
let's,
okay,
the
sense
this
is
this:
this
will
help
I
think
in
the
future,
so
cool
and
maybe
that's
okay.
So
my
background
is
in
Test.
I
would
like
to
take
on
the
task
of
creating
something
in
our
JIRA
in
the
JIRA
that
has
a
list
of
pipeline
bugs
and
a
way
to
sort
of,
say,
here's
the
things
that
are
on
the
radar
at
least
I
mean
it's
going
to
be
a
huge
list,
but
maybe
there's
some
way
of.
A
E
I
couldn't
find
that
on
the
websites
at
all,
so
I
thought
I'd
come
here
and
ask
what
what
the
direction
is
and
the
reason
I
asked
is
relatively
new
to
Jenkins
myself
I've
been
using
it
for
a
couple
of
years
now
and
started
with
the
declarative
pipeline
syntax,
which
I
think
was
very
new
at
the
time
and
very
quickly
after
getting
started,
realized,
there's,
declarative,
syntax
and
then
there's
this
other
syntax,
which
is
older
and
supports
more
features.
But
there's
no.
E
B
C
E
I
think
a
lot
of
the
newer
examples
use
declarative,
syntax,
but
there's
a
lot
of
things
you
can't
do
in
declarative
syntax.
So
as
a
person
trying
to
use
Jenkins,
you
get
so
far
using
one
syntax
and
hit
a
wall
where
you
end
up
copying
and
pasting
a
whole
bunch
of
things
instead
of
creating
functions
and
I
have
to
fall
back
to
those
other
syntax
which
is
similar
but
different.
So
it's
not
a
particularly
good
experience
for
for
users.
Yeah.
A
E
B
E
Yeah,
so
I
can
think
of
two
specific
examples
using
the
clarity
of
syntax,
where
I've
run
into
issues
in
the
last
little
bit.
One
is
like
each
of
our
stages
has
a
a
post
action
that
happens
and
it's
the
same
for
each
stage
and
it's
maybe
five
or
six
lines
or
eight
or
ten
lines
right
and
if
we
have
six
or
seven
pipeline
stages
that
I'm
kind
of
copy
and
pasted
and
as
a
developer,
that's
taste
bad
to
me
right
and
on
the
second
one.
E
Recently
we
had
a
single
pipeline
stage
and
declarative
syntax
that
we
wanted
to
run
across
multiple
nodes
in
parallel
and
again
relatively
easy.
If
you
just
copy
and
paste
the
block
and
stick
it
in
a
parallel
declaration
and
again
you're
copying
and
pasting
you're,
not
there's
no
language
feature
in
the
declarative,
syntax
that
allows
you
to
express
repeating
something
so.
B
E
B
Okay,
yeah,
if
you
can
soak
good
point,
okay,
all
right!
Thank
you.
C
I
would
take
a
step
back
and
just
talk
about
the
difference
between
scripted
and
declarative
for
a
second,
this
is
disclaimer.
This
is
my
perception
of
the
two
features.
I,
definitely
don't
speak
for
the
plug-in.
What
maintain
errs
at
all
my
understanding
is
that
declarative
is
intended
to
be
easy
to
validate
and
easier
to
write
right.
C
It's
not
a
programming
language,
necessarily,
it's
a
spec,
a
data
structure
that
can
be
easily
validated
and
have
some
functionality
and
then
scripted
exists
for
some
more
advanced
use
cases
right,
I,
think
under
the
covers,
declarative,
syntax
and
scripted
syntax
or
invoking
the
same
things.
It's
just
different
facades
for
for
interacting
with
them
right
so
to
me
that
they
both
exist
in
parallel
to
support
different
use
cases.
So
it's
not
really
like
a
one.
C
How
complex
about
pipeline
are
you
trying
to
write
and
if
you
need
to
do
things
like
looping
and
things
like
that,
that
you
would
typically
do
with
the
programming
language
scripted
is
gonna,
be
a
better
fit
if
you
just
want
to
like
run
a
bunch
of
make
commands
and
maybe
spread
them
across
agents
and
have
some
post
blocks
and
declared
it
might
be
a
better
fit
and
I
am
very
open
to
feedback.
If
that
is
anyone
else,
those
different
perspectives
on
the
two
there
yeah.
So
my
perspective.
D
Is
a
little
bit
different
so
how
I
saw
this
stuff
evolve,
so
I?
Actually
I
talked
to
Andrew
barrer
like
very
early
on
even
before,
like
declarative
pipeline
was
around
and
he
had
a
earlier
earlier
prototype
called
plumber,
where
you
could
specify
a
pipeline
in
llamó
and
then
that
that
kind
of
didn't
go
anywhere.
D
But
basically
scripted
pipeline
was
the
first
implementation
of
pipeline
and
then
the
declarative
pipeline
came
after
that,
and
the
idea
was
that
declarative
was
a
easier
and
easier
and
more
intuitive
way
to
write
a
pipeline
but
still
reuse
all
the
same
code
and
constructs.
So
it's
like
a
dia.
It's
like
a
restricted
DSL
that
tries
to
make
a
pipeline
more
readable,
but
I
found
when
I
wanted
pipeline.
D
When
I
tell
new
people
I
point
them
to
the
the
new
stuff,
because
it's
a
little
bit
more
easier
to
follow,
but
I
end
up
using
the
script
tag
quite
heavily
too,
and
to
me
the
script
tag
is
an
escape
hatch
because
the
the
script
tag.
Basically,
it
doesn't
mean
what
you
think.
It
means
like.
A
lot
of
people
think
the
script
tag
means:
oh
I
can
put
a
shell
script
syntax
in
here,
but
it's
not
the
script
tag
means
you
can
use
any
groovy
construct
in
the
script
tag.
D
So
what
I
end
up
doing
and
a
lot
of
pipelines
that
I've
written
is
I
start
out
with
the
pipeline
and
the
restrictive
DSL.
But
then
I
use
the
script
tag
to
do
more
Cody
kinds
of
stuff
like
loops
and
defining
variables,
and
things
like
that,
and
so
I
mean
there
was
the
intent
of
what
this
stuff
was
and
then
there's
actually
what
you
end
up
doing
to
actually
get
things
moving
and
what?
What
I?
What
I
found?
Is
that
I
kind
of
straddle
both
things
where
I
used
the
decorative
pipeline?
D
C
The
one
clarification
I
would
make
just
in
cases
you
can't
use
technically
any
groovy
syntax
Jenkins
under
the
covers
leverage
is
something
called
continuation
passing
style
so
that
Jenkins
pipelines
can
resume.
The
implication
that
that
has
on
the
code
that
you
write
is
that
everything
has
to
be
serializable,
because
it's
continuously
writing
the
state
of
the
pipeline
to
disk.
So
there's
a
lot
of
common
bugs
that
can
come
up
where
you
write.
C
B
So,
coming
back
around
I
noted
that
matrix
does
this,
but
many
peas
defined
for
some
of
the
some
of
these
scenarios
that
it's
that
it
really
actually
does
apply
to
and
you're
right,
I
think
the
the
way
that
I
have
with
the
documentation
for
matrix.
There
probably
needs
to
be
something
more
added
to
it
to
say:
hey
if
into
the
pipe
to
the
parallel
section
to
say:
hey
if
you're
trying
to
do
this
go
over
here,
you
can
get
that,
but
the
other
there's
two
things
that
I
want
to
bring
up
here.
B
Whenever
the
the
consensus
seems
to
me:
oh
yeah,
you
do
declarative
for
the
simpler
things
and
then,
when
you,
when
you
grow
up
and
and
and
you
are
ready
to
take
on
the
real
thing,
you
build
your
scripted
and
I'm
like
yeah-
that's
not
what
that's
not
the
design
intent.
In
fact,
the
intent
has
always
been
for
declarative
to
similar.
It's
similar
to
the
now
to
declarative
and
devotion
were
created,
sort
of
side
by
side
and
the
descriptions
are
executed.
Similar
declarative
is
an
opinionated
way
of
going
up
doing
pipeline
and
form.
B
For
me,
the
main
thing
that
you
that,
when
people
bring
up,
oh
well
as
I,
there's
something
that
I
need
to
do,
but
I
can't
do
it
in
declarative,
and
my
question
is
what
is
that?
Because
there's
we
as
a
sort
of
a
short
like
okay,
I'm,
just
gonna
fall
back,
would
be
put
something
like
for
the
the
case
that
you
mentioned,
which
was
you
know
the
same
five
lines.
You
need
to
do
a
bunch
of
different
places.
That's
what
shared
libraries
are
for,
but
I'm,
not
I'm,
not
completely
satisfied
with
that
answer.
B
I
I'd
like
to
see
that
addressed
more
locally
or
the
ability
to
dress
something
like
that
locally
right
within
your
jenkins
file.
So
you're
not
having
to
go
out
to
a
shared
library,
could
completely
separate
repository
just
to
do
some
basic
code,
reuse
right
so
and
in
fact,
I've
even
reached
a
point
of
like
okay.
We
don't
for
the
original
version
of
original
releases
of
declarative.
B
There
was
very
much
a
no
we're
not
going
to
do
variables
and
I'm
like
yeah,
but
there
are
cases
you
know
where
it
makes
sense,
and
it's
not
an
the
thing.
Is
it's
not
the
easiest
thing
to
solve
within
the
the
structure
that
we're
trying
to
establish
and
the
on
the
flip
side
from
this
when
people
say
well,
I
can't
do
X
in
declarative
the
some
of
sometimes
that
X
is
stuff
where
I
have
to
say.
Why
are
you
doing
that
in
your
pipeline
yeah?
B
You
can
do
that
inside
of
Jenkins,
but
you
have
to
understand
that
you're,
not
that
you
that
you're
doing
things
that
are
actually
more
expensive
inside
of
groovy
and
inside
of
the
CPS
framework
and
you're
running
them
all
on
your
master.
It's
maybe
not
where
you
want
to
be
doing
that
so
there's
sort
of
a
two
sided
thing.
B
B
This
is
another
example
of
like
we
should
have
a
set
of
I'm
hoping
to
put
this
put
this
together
as
part
of
the
sig
a
set
of
items
on
the
on
the
road
on
the
roadmap
that
okay,
here's
what
we're
going
to
do
if
the
gaps
going
to
fill
and
then
when,
after
those
we
should
be
sort
of
pushing
back
on
people
to
go.
Okay,
no
don't
do
that
right.
D
Yeah
but
I
Michael
I
sympathize.
All
the
points
you
have
brought
up
are
valid.
I
have
encountered
these
things
myself,
and
so
you
know
keep
keep
bringing
up
these
points.
One
thing
that
I
would
maybe
recommend
and
I've
done
this
myself
when
I
find
weird
things
and
pipeline
that
I
don't
understand,
I,
ask
the
question
on
Stack
Overflow
and
then,
if
I
find
a
solution
or
if
someone
else
finds
a
solution,
I
I
post
that
solution
to
my
question
on
Stack
Overflow,
so
at
least
I
have
that
you
know
automated
somewhere.
D
That
was
something
decided
by
someone
else
a
long
time
ago,
but
you
know,
do
do
raise
the
issues
and
if
you
find
solutions
to
the
your
problems,
you
know
put
them
somewhere,
where
other
people
can
benefit,
because
I
I
use
Google
a
lot
too.
You
know
and
I
looked
at
Stack
Overflow
a
lot
to
ask
questions
and
also
find
answers
to
questions
that
I
have
about
pipeline.
C
We
are
about
ten
minutes.
I
was
just
gonna
say
just
imagine
an
equally
interesting
and
horrifying
idea
of
being
able
to
do
something
like
go
templating
for
your
declarative
pipelines
to
be
able
to
augment
your
declarative
syntax
with
some
of
those
more
scripted
functionalities.
But
please
do
not
actually
implement
that.
A
E
A
D
A
A
So
it
renders
it
very
weird:
that's
why
it
was
removed.
Somebody
actually
complained
the
way
that
the
doc
the
link
in
there
I
think
is
fine,
but
the
way
it
got
it
rendered
the
Lincoln
in
the
actual
webpage.
So
when
you
were
scrolling,
you
hit
the
dock
and
then
you're
scrolling
through
the
dock.
So
I
don't
know
in
the.
B
A
A
A
So
would
you
just
not
have
that
bookmarked
somewhere
or
I
guess
what
we're
trying
to
do
is
limit.
So
in
your
originally,
you
had
asked
to
get
her
to
have
this
information
put
at
the
top
of
the
topic
of
the
getter
channel.
The
reason
that
I
find
that
difficult
is
because
now
we
have
to
maintain
multiple
places
where
there's
a
link
or
documentation
to
something
in
the
calendar
invite
which
is
on
the
Jenkins
community
event
say
it
has
the.
E
B
I
mean
what
I'm
feeling
right
now
is
actually
the
the
problem.
The
problem
that
Mark
II
was
the
meeting
agendas
right
and
this
this
sort
of
embedded
in
the
in
the
page.
It's
like
well
so,
but
we
can
there's
certainly
a
way
to
do
that
without
actually
and
it
I
think
it
actually
is
right
here
you
can
click
on
this
and
it'll.
Take
you
to
thing
rather
than
there's
got
to
be
a
way
to
have
it
not
embed
died,
though,.
B
You
know
I
think
if
we
can,
the
the
link
to
the
document
I
mean
you
could
always
post
it
figure
out
a
way
to
post
it
as
a
tiny,
URL
I
said
it,
it
redirects
automatically
should
go
and
redirect
it
from
one
place
that
it
really
matters
in
that
respect,
but
I
think
we
shouldn't
try
and
follow
some.
You
know
the
consistent
behavior
from
other
SIG's
so
seems
like,
and
it
seems
like
that's
this
posting
the
agenda
in
some
form,
some
of
them
are
embedded
in
it
by
doing
PRS.
B
B
And
the
point
there
is
that
we
just
need
people
to
keep
talking
about
them.
So
all
right
anything
else.
This
has
been
a
really
good
meeting.
I.
It's
been
a
really
a
discussion.