►
Description
Jenkins Pipeline-Authoring SIG Meeting for 20200612
Discussed:
- Pipeline-Authoring SIG Roadmap
- Requesting help testing git plugin 4.3 beta soon
- Generic question regarding pipeline changelog
A
Welcome
welcome.
Welcome
everybody
to
the
Jenkins
pipeline
authoring,
sig
meetup
for
Friday
June
12th,
my
name
is
Marky
I
am
one
of
the
sig
leads
welcome
everybody.
We
do
have
a
code
of
conduct
and
that
essentially
amounts
to
be
nice.
Don't
make
anybody
have
to
kick
you
out
with
that?
I
am
I.
Put
a
note.
I
put
a
chat
in
Dee
zoom,
as
well
as
in
the
channel,
to
give
everybody
the
docs
link
to
the
docks,
and
oh
no
I
can't
share
my
screen.
A
Oh
beautiful,
thank
you
zoom.
Give
me
a
second
find
out
where
I'm
at
here.
Can
everybody
see
my
screen,
give
me
a
thumbs
up.
If
you
can
awesome
awesome?
Okay,
so
we
will
go
ahead
and
start
off
the
meeting
talking
about
the
first
item,
and
that
is
the
pipeline
authoring
sig
roadmap,
if
everybody
saw
the
email
I
was
sent
out
by
Oleg.
A
A
They
need
to
be
better
drafted
to
support
what
the
item
is.
That's
up
for
the
roadmap
or
in
some
instances,
items
that
have
been
referenced
or
items
which
don't
really
fit,
or
it's
like
a
bug.
So
we
need
to
go
through
and
change
that
now
I've
done
a
little
bit,
but
there's
still
a
lot
lot
more
to
do.
What
I
want
to
know
is:
is
anybody
willing
to
work
with
me
to
do
that,
essentially
what
we
need
to
do
I'm
going
to
use?
This?
A
B
A
Ok,
does
anybody
want
to
sync
with
me,
maybe
at
some
point
today,
I'm
kind
of
booked
dealing
with
another
issue
with
log
updates?
Does
anybody
want
to
sync
with
me,
maybe
next
week
to
get
this
done
like
we
could
I'm
sure
we
could
probably
get
this
done
in
an
hour
or
at
least
get
the
skeleton
up
and
I
could
take
the
rest.
What
I
don't
want
to
do
is
have
to
do
it
all.
B
So,
for
me,
yeah
I
was
not
speaking
to
no
platform
sick
meetings
but
yeah,
which
the
videos
last
week
I
was
still
unable
to
identify.
What's
the
purpose
of
certain
stories,
for
example,
functional
testing
tools
or
unit
testing
tools,
so
just
for
the
context
of
sig
members
yeah,
there
are
already
some
more
functional
and
unit
testing
tools
for
pipeline.
B
These
tools
obviously
have
their
own
advantages
and
disadvantages,
but,
for
example,
for
me,
I
was
unable
to
understand
what
the
goal
would
be
scope.
What
is
missing
from
the
standpoint
of
sig
members?
So
for
me
it's
not
just
writing
the
description,
but
also
trying
to
define
my
goals
for
this
project
and
his
existing
solutions.
Okay,
if
there
is
existing
solution,
maybe
if
it's
not
well
known,
maybe
it
would
be
it
rather
beneficial
to
document
that
as
a
roadmap
I
can.
B
Do
too,
if
you
really
needed
in
Utah,
we
need
to
understand,
what's
the
purpose
of
that
and
what
weaknesses
of
the
existing
tools
it's
going
to
address,
because
otherwise
for
maintenance
of
existing
tools,
it
may
come
along
as
a
lot
of
entity
a
syndrome.
At
the
same
time
for
users
they
won't
be
able
to
discover
the
existing
tools.
So
for
me,
it's
a
major
concern
and
that's
why
I
propose
to
the
fix
roadmap
item
so
to
remove
them.
A
C
A
B
B
For
the
record,
I
do
not
want
B
is
a
heart
requirement,
but
at
the
same
time,
doing
some
efforts
to
clean
up
the
road
map.
No
and
yeah
I
would
really
appreciate.
If
some
progress
is
done
by
Wednesday,
if
it's
not
possible,
okay,
we
can
postpone
it
or
just
comment
out
the
existing
without
really
the
deleting
them
from
llamó
file
yeah.
B
B
A
B
A
B
D
B
So
do
you
see
my
screen?
Yes,
okay,
so
this
is
a
development
revision
of
the
road
map.
You
can
say,
oh
so,
and
there
is
a
pull
request
for
that.
Just
a
second,
it's
here,
so
I
forgot
to
rename
the
title,
but
actually
does
three
things
now.
I
previous
column
supports
three
broken
items
and
also
adding
labels
and
filtering
them.
B
So
what
I've
done
and
now
a
metadata
includes
some
additional
fields
which
we
can
use
so,
for
example,
via
the
rest,
labels
have
been
with
definition
straight
inside,
so
everybody
can
consume
them,
and
the
items
now
include
explicit
labels
a
little
time
later,
like
future
documentation,
tools
and
I
applied
all
my
expertise
with
JavaScript
and
I
implemented,
filtering
yeah.
Basically,
I
had
to
Google
a
lot.
It
still
looks
terrible,
but
especially
one
massage
kisses,
but
it
kind
of
works,
so
I
will
probably
exclude
people
this
way.
B
There
is
no
labels
and
then
fine,
but
yet
this
is
how
it
looks
like
and
later
also
fun
to
add
filtering
by
a
sea
or
sub
project,
so
that
yeah
it
looks
a
bit
better
and,
for
example,
what
I've
done
I
removed
service
categories,
for
example.
Here
we
had
a
lot
of
documentation,
categories,
advocacy
and
outreach,
documentation,
etc,
and
instead
of
that
now
we
use
labels.
B
Why
it's
important
because,
for
example,
it's
hard
fest,
it
was
focused
on
user
experience,
so
I
put
it
to
the
user
experience
column
same,
for
example,
for
solution
pages
for
user
documentation.
Right
now
notes
here,
administrative
communication,
straight
column
and
then
for
example.
If
somebody
wants
to
see
what's
happening
with
the
plantation,
you
click
a
box,
and
you
see
that,
for
example,
the
immunization
for
fishes
is
here
to
ski,
etc,
etc.
A
B
Appreciate
any
reviews
here,
but
you
mean
my
target-
is
too
much
it
at
some
point,
maybe
over
the
weekend
and
yeah
after
that.
Yet
so
next
Monday
or
Tuesday
we
can
merge.
Pipeline
I
also
have
a
lot
of
other
items
to
it,
for
example,
dark
theme
or
different
terminology
update.
It
still
needs
to
be
applied,
but
I
want
not
sure
this
one.
Just
in.
A
B
Has
items,
for
example,
I
know
that
there
is
a
script
security
interface,
rework
I
was
thinking
about
it
today,
but
if
you
have
other
examples
of
such
important
issues
for
users,
we
can
add
them
here
as
well.
Any
contributions
and
suggestions
are
welcome
and
if
you
don't
want
to
go
to
just
drop
it
in
the
mailing
list,
leave
it
from
the
job
so
that
I
will
incorporate
editor
on
my
own
in
a
few
ways.
A
D
D
A
B
Nothing
specific
I
had
a
generic
question
about
pipeline
plugin.
Plugin
change
lot:
okay,
because
what
I
have
noticed
that
we
have
many
pipeline
plugins,
which
haven't
immigrated
to
github
releases
or
change
local
movies
yet
and
the
why
it's
important.
We
have
virus
topped
it
on
the
flag
inside
by
Gavin
Morgan,
but
our
plugin
site
now
displays
change
logs
right
inside
the
web
interface.
B
C
Guess,
that's
mostly
for
me,
but
I
mean
historically.
The
main
reason
for
me
is
that
I
find
from
my
use
cases
released.
Raptor
is
like
quite
annoying
to
look
at
because
it
uses
the
format
like
when
I'm
looking
at
change,
like
so
I'm,
usually
looking
at
historical
releases
trying
to
track
down
some
old
bug.
You
know
in
some
relief
six
years
ago
that
I
wish
I'd
never
had
to
look
at
again
or
something.
B
C
It's
like
when
I'm
using
release
chapter
right,
there's
like
pagination
and
there's
a
ton
of
white
space,
and
it
becomes
a
lot
harder
to
carry
version
to
version
so
I.
Just
kind
of
never
really
felt
motivated
to
make
the
change
I
mean
if
it's
important,
no
for
it
to
show
up
on
the
plugins
page
automatically
and
I'm
more
willing
to
go
ahead
and
do
it
just
before
it.
B
Yes,
some
plugins,
don't
yeah,
that's
sort
of
my
confusion,
because
some
plugins
still
put
it
on
the
readme
page.
Some
plugins
seem
to
still
have
way
on
weekend
so
yeah.
It
was
just
a
browsing
through
plugins.
A
couple
of
days
ago,
when
I
was
trying
to
resolve
the
pipeline,
like
insanity,
sure
I
hit,
do.
D
C
B
Side,
but
there
is
a
ticket
for
that
I
approached
a
is
that
a
change
low
can
be,
is
pretty
much
standard
format
in
open
source
projects,
so
we
should
support
it
on
the
plug-in
side
and
yet
I
believe
that
we
will
just
do
that.
I'm,
not
sure
how
exactly
because
we
can
allow.
There
are
multiple
ways
to
do
that,
including
let's
just
dump
half
of
the
dependable
course,
so
that
it
resolves
everything
for
us
or
doing
something
on
our
own.
But
it's
yet
to
be
implemented.
B
C
It's
important
I
can
use
released
rapture
this
until
now
like
this
is
a
more
important
reason
for
users
to
actually
able
see
it
in
an
automated
way.
Until
now,
I
didn't
see
them
as
important.
There's-
probably
some
plugins
to
like
that
I.
Don't
ever
really
look
at
that,
probably
might
still
have
their
change
logs
on
the
wiki,
but
I
don't
know
yeah.
B
So
I
will
check
my
notes
and
report
issues
if
I
hit
them.
But
here,
for
me,
keeping
change
locally
is
perfectly
fine.
We
will
just
need
to
apply
some
magic
to
indentify
these
files,
because
right
now
we
rely
on
metadata
supplied
by
a
every
Center.
So
we
do
some
magic
on
the
update,
Center,
a
generator
site
or
a
bit
moving
in
inject
additional
metadata
so
which
is
yet
to
be
seen
but
yeah
cheese,
locum
de
might
be
fine.
B
D
No,
but
but
I
certainly
haven't
done
that
with
any
of
the
plugins
that
I,
maintain
and
I
haven't,
had
any
complaints
about
having
just
drawn
a
line
in
the
sand
where,
after
this
point,
I
used
release
drafter
is
that
still,
okay,
that
I
just
changed
a
lot?
I
changed
logged
at
MD
records
all
the
things
that
used
to
be
in
the
wiki
and
release
drafters
started
at
some
point
to
record
things
for
new.
I
hadn't
bothered
to
do
any
transition.
Is
that
it
I
assume
that's
okay,
yet.
C
B
Change,
locking
diff
has
a
lot
of
benefits
on
its
own,
for
example,
moving.
If
you
wouldn't
want
to
rely
on
it
happen
for
construction,
then
using
change.
Lo
can
be
it's
just
using
it
if
you
go
to
github
releases,
etc,
and
basically
your
change
looks
all
in
github
or
tools.
Oh
yeah
force.
We
are
already
rolling
so
a
bit
relaxed
about
that.
But
yeah
I
understand
maintain
your
application
to
become
be.