►
From YouTube: Introduction to Jenkins 2 277 1 Mar 17, 2021
Description
Jenkins 2.277.1 is the most recent Jenkins long term support (stable) release. It was released March 10, 2021 with breaking changes in specific areas that improve the Jenkins experience and provide foundational improvements to Jenkins internal components.
Major breaking changes include:
* Configuration Form Modernization (aka Tables-to-Divs)
* JEP-227 - Update of Acegi Security to Spring Security
* JEP-228 - Unforking XStream
* ASM Library Update
* Replacement of old system properties
Additional changes include:
* Plugin Manager Performance Improvements
* Support for specifying “Preparing to Shutdown” reasons
* New color palette in tab controls
* Performance improvements
* Dependency updates
Presentation noted that this upgrade is different than typical Jenkins LTS upgrades because it needs plugin upgrades in the same steps as the Jenkins core upgrade. Steps recommended are:
* Review the upgrade guide
* Remove unused plugins
* Update plugins before Jenkins 2.277.1 upgrade
* Upgrade to Jenkins 2.277.1
* Update plugins after Jenkins 2.277.1 upgrade
Panel discussion session with Jesse Glick, Tim Jacomb, and Félix Queiruga highlighted more details of the process upgrade process and more ways that Jenkins users and developers can have a better experience with the upgrade.
Oleg Nenashev describes the process and timeline of the Jenkins long term support releases. He notes how Jenkins weekly releases are curated and collected to a selected baseline. The baseline is augmented with additional backported changes based on issues discovered in later weekly releases.
A
A
I'm
I'm
mark
waite
and
joined
by
oleg
nanashev
and
together
we'll
be
presenting
much
of
the
material
here
then,
in
addition
to
those
the
presentation
part,
we've
asked
three
of
the
key
developers
involved
in
these
changes
to
join
us
for
a
panel
discussion.
Where
we'll
do
question
and
answer
letting
us
ask
them,
questions
gain
insights
into
their
experience
and
what
they
learned
from
taking
a
product
used
by
250
000
installations
from
previous
technologies
to
newer
technologies.
A
These
changes
how
they
were
verified,
what
sorts
of
experiences
there
were.
We
encourage
you
during
that
phase
to
ask
questions
of
our
panel
as
well
by
way
of
reminder
during
the
meetup
it's
best,
if
you
use
zoom's
q
a
feature
rather
than
chat
the
q,
a
feature
lets
us
manage
the
questions
more
effectively.
A
B
B
B
So
of
course
it's
rather
stabilization
release
and
when
we
select
new
baseline,
we
have
three
releases
every
four
weeks
with
back
parts
and
security
fixes.
Sometimes
if
we
need
to
we
release
additional
releases
or
we
can
maintain
the
reduce
line
for
longer,
but
we
commonly
expect
the
user
to
upgrade
the
new
baseline
after
12
weeks
or
eventually,
when
they
are
ready.
B
So,
first,
the
process
is
coordinated
by
the
jenkins
release
team
and
by
jenkins
release
officer
team,
who
is
also
on
the
call
and
yeah.
The
team
is
working
on
preparing
backpacks,
preparing
change
logs
and
preparing
upgrade
guidelines
for
each
release.
It's
like
this.
So
if
you're
jenkins
next
slide.
B
Oh
thank
you
now
see
so
yeah.
What
do
you
get
as
a
user?
Firstly,
you
get
all
packages,
so
it's
a
war
file,
it's
a
installers
for
different
platforms,
including
windows,
multiple
linux
versions
and
those
docker
packages
which
you
can
use
for
docker
and
kubernetes
deployments
deployments
in
other
container
environments.
B
Plus
there
are
packages
which
are
not
maintained
by
the
jenkins
project
directly
but
are
maintained
by
other
communities.
For
example,
free
bsd
grant,
of
course,
open
bsd.
We
don't
distribute
these
packages
on
our
own,
but
they
are
being
released
by
other
communities.
And,
yes,
you
get
change
logs
and
you
get
upgrade
guidelines
which
are
specific
to
the
lcs
releases.
B
So,
let's
go
to
the
next
slide.
So
for
2.27.1,
it's
basically
a
weekly
release
with
some
back
ports,
so
the
previous
braveland
was
263
and
in
this
version
we
introduced
quite
a
lot
of
changes,
but
actually
in
2077
we
introduced
a
lot
more
and
some
of
these
changes
are
breaking
once,
but
still
the
release
is
quite
stable
and
it
includes
bug
fixes
which
have
been
released
since
the
baseline
selection.
B
B
B
Okay
or
we
can
do
like
that.
So
yeah.
You
can
see
that
the
current
community
ratings
are
not
exactly
great,
so
we
have
124
successful
deployments,
but
some
users
reported
different
regressions.
So
you
can
see
that
approximately
30
percent
of
our
upgrade
attempts
experienced
some
issues
and
yeah,
it's
quite
a
high
high
number.
So
it
would
be
nice
to
understand
what
happened
and
yeah.
Let's
go
to
the
next
slide,
then,
okay,
yeah!
So
yes,
there
are
breaking
changes
and
actually
there
is
quite
a
number
of
them
it
includes.
B
Could
you
please
go
to
the
next
slide?
Yeah!
Thank
you!
So
in
this
release
we
started
the
basic
technical
debt
we
had
in
the
junkies
core.
So
there
was
a
lot
of
changes
related
to
mandatorization
and
dependencies,
most
significantly
update
of
sg
security
to
spring
security,
replacement
of
old
extreme
fork
by
upstream
version
maintained
by
the
extreme
community,
and
we
have
the
awesome
library
and
actually
we
updated
a
lot
of
other
dependencies
inside
the
weekly
baseline
between
these
releases.
We
have
enabled
a
dependable.
B
So
actually,
there
is
a
lot
of
library
updates
here
and
there,
and
these
are
main
dependency
changes.
Also,
there
was
major
change
related
to
configuration,
forms
and
forms
engineers
in
general,
so
what
we
call
table
studies,
improvement
for
better
accessibility
and
yeah.
This
is
also
breaking
change.
Lately
we
will
discuss
these
changes
in
detail,
say
just
summarize
them
and
glance
also
for
those
who
use
system
properties.
So
there
were
several
system
properties
which
were
replaced
by
new
names.
B
So
no
hudson.
Now
it's
jenkins.
In
addition
to
that,
we
had
a
few
improvements.
So,
for
example,
plugin
manager
got
a
lot
of
improvements
where
you
navigate
available
page,
so
it
lists
plugins
much
faster
and
lots
of
them
synchronously.
Then
now
you
can
specify
a
reason
for
preparing
to
shut
down
yeah.
There
is
new
colored
pilot,
which
is
a
continuation
of
your
ux
improvements,
which
you
may
have
seen
in
previous
releases,
and
also
there
is
a
lot
of
performance
improvements
and
dependencies
here
there.
B
A
A
So
what
we
see
the
old
ui
before
2.27.1
was
laid
out
with
html
table
markup,
and
that
meant
even
on
a
wide
screen.
So
this
screenshot
that
you
see
here
is
a
1280
pixel
wide
screen
notice
the
scroll
bar
at
the
bottom
and
notice
that
the
fields
are
truncated
over
there
on
the
right
hand,
side
it
just
didn't
feel
like
a
reasonable
use
when
my
nice
wide
monitor
doesn't
fit
the
whole
form
that
I
need
to
edit.
Thanks
to
these
changes
that
have
been
made
now
the
fields
fit
inside
the
page.
A
Okay,
that's
that's
already
a
nice.
There
are
also
hints
with
dashed
lines
along
the
left-hand
edge
edge
that
help
me
see
which
things
are
grouped
together
previously.
I
wrestled
with
hey.
How
does
this
work
and
where
does
which
thing
does
this
apply
to
and
that
apply
to
and
no
horizontal
scroll
bar?
A
So
those
kind
of
things
are
significant
improvements
to
the
experience
for
someone
editing
in
forms:
seven:
core
pull
requests,
40,
plug-in
releases,
40
plus
plug-in
releases,
14
weekly
core
releases
to
get
here,
56
issues
resolved
and
yes,
there
are
15
issues
still
open,
so
I
can
do
a
live
demo
as
well
and
oh,
like
I
think,
that's
that's
kind
of
a
fun
exercise.
Let's
take
a
look
at
my
jenkins
on
my
live
environment.
A
So
here
is
my
jenkins
installation
and
if
I
go
to
manage
jenkins
note,
this
is
263.4.
So
the
previous
long-term
support
release
manage
jenkins
and
I'm
going
to
click
configure
system,
and
my
screen
is
quite
wide
and
yet
we're
going
to
see
when
configure
system
arrives
that
I'll
likely
get
a
scroll
bar.
Lucky
me
meanwhile,
while
that
is
loading,
we're
going
to
do
the
same
exercise
with
jenkins
2.277.1
manage
jenkins
configure
system.
A
A
Those
kind
of
things
made
the
ui
more
difficult
for
administrators
in
jenkins
versions
prior
to
277.1,
whereas
here
look
everything
fits
and
yes,
I've
got
these
nice
little
hints
over
here
on
the
left.
That
tell
me
what's
going
on
which
thing
I'm
grouped
with
and
how
thank
you
very
much
felix
josh
tim.
A
A
A
Now,
then,
even
before
you
upgrade
to
jenkins
2.27.1
upgrade
your
plug-ins.
Now
you
may
be
accustomed
to
doing
jenkins
upgrades
without
upgrading
plug-ins,
but
because
of
the
braking
changes
inside
2.27.1,
it's
important
that
you
upgrade
your
plug-ins.
You
do
them
before,
because
there
are
many
plug-ins
that
can
be
upgraded
even
without
upgrading
to
jenkins
277.1,
and
you
get
you
get
that
newer
version.
A
C
I
I
can't
actually
talk
about
the
asm
update,
but
I
can
talk
about
these
two
slides.
So
first
one
was
listed
as
jenkins
enhancement
proposal
number
227,
and
this.
The
idea
here
was
that,
since
pretty
early
days
in
the
jenkins
project,
actually
going
back
to
hudson
days,
it
had
been
using
this
library
called
sedgy
security.
C
All
of
those
authentication
plugins,
are
all
using
this
api,
and
a
lot
of
other
plugins
were
also
using
this
api
to
pick
up
information
about
who
the
logged
in
user
is
and
what
kinds
of
groups
they
were
assigned
to.
Ldap
groups
that
sort
of
thing-
and
this
all
worked.
But
basically
we
were
stuck
on
this
old
library
and
years
and
years
ago,
that
library
was
totally
rewritten
and
it
was,
they
won't
say
totally
rewritten,
but
it
was
largely
revised.
C
Then
the
revised
version
became
known
as
spring
security
version
2.0
and
that
was
sort
of
brought
under
the
aegis
of
the
spring
project.
With
a
lot
of
other
libraries
and
by
the
time
we
came
to
this
work,
that
library
was
on
spring
security
version
five,
so
you
can
imagine
that
there
were
a
bunch
of
other
major
refactorings
in
three
four
and
five
after
that
point,
so
we
were
using
this
very
old
library.
C
C
Unfortunately,
not
only
did
the
rewrite
to
spring
security
change
the
java
packages,
but
it
introduced
a
lot
of
other
incompatible
changes
to
the
library.
So
it
wasn't
an
option
to
just
you
know,
replace
one
line
and
jenkins
and
say:
yes,
please
use
the
new
one
change.
This
version
number
and
everything
would
be
fine.
C
So
I'm
not
sure
how
much
detail
you
want
me
to
go
into
now,
but
basically,
this
involved
a
pretty
big
patch
to
jenkins
core
to
introduce
the
new
security
framework,
keep
some
stubs
in
place
for
the
old
one
without
actually
bundling
the
old
library.
Just
creating
a
sort
of
facade
that
would
let
plugins
that
were
still
built
against
older
versions
of
jenkins
continue
to
work.
The
same
way
with
only
a
very
very
few
exceptions,
and
so
this
landed
in
jenkins
2.266,
which
means
that
it
appears
in
this
lts
line
for
the
first
time
now.
A
C
C
As
far
as
I
know,
all
of
the
changes
needed
for
that
are
actually
required
for
plugins
to
work
after
this
change
have
been
released,
meaning
that
you
can
meaning
the
updating
plugins
before
the
jenkins
core
upgrade
works,
so
they've
not
just
been
released,
but
they've
been
released
in
versions
that
are
compatible
with
the
previous
lts
line.
There's
one
exception,
which
is
the
kaz
plugin,
which
is
a
sort
of
not
frequently
used
authentic,
single
sign-on
authentication
plug-in
that
one
for
technical
reasons.
We
couldn't
do
that,
and
so.
A
C
C
So
if
you're
using
an
old
version
of
the
ldap
plug-in,
you
have
an
upgrade
in
a
while
and
you
just
went
and
upgraded
jenkins
core.
Without
touching
that,
then,
after
the
upgrade,
you
would
get
all
sorts
of
errors.
The
moment
you
tried
to
log
in
and
that's
especially
a
problem
for
a
security
round
plug-in
because
you
need
to
be
logged
in
as
an
administrator
in
order
to
update
from
the
gui.
C
C
A
So
a
so
don't
miss
upgrading
your
plugins
before
you
upgrade
your
jenkins
this
in
the
past.
It
wasn't
always
that
way,
right
it's
this
is.
This
is
somewhat
distinctive
because
of
the
breaking
changes
in
this
one,
so
jesse
on
the
next
topic.
Extreme
unfork.
Would
you
be
willing
to
share
some
further
insights
there.
C
Sure
so
this
was
another
jenkins
enhancement
proposals
kind
of
along
the
same
sort
of
lines
that
we
wanted
to
be
using
an
up-to-date
standard
version
of
a
library.
In
this
case,
xstream
is
a
sort
of
an
alternative
to
java
serialization.
It
follows
similar
model
to
java
serialization,
but
it
reads
and
writes
xml
and
basically
everything
in
jenkins
that
has
any
kind
of
stored
configuration
any
kind
of
settings
as
well
as
metadata
about
builds
definitions
of
jobs.
C
So
we
had
half
a
dozen
little
changes
to
extreme
or
something
for
jenkins
use,
but
the
patch
was
was
falling
out
of
date
and
it
was
really
painful
to
maintain
those
things.
It
would
take
somebody
a
day
to
go
through
and
analyze
what
needed
to
be
done
when
we
do
the
update
and,
and
so
the
result
was
we
weren't
updating
it
and
worse
one
of
those
patches
that
was
actually
the
result
of
sort
of
a
misunderstanding
of
how
extreme
is
supposed
to
be
used.
C
So
we
were
using
an
annotation
feature
that
was
convenient
and
was
used
in
a
handful
of
places
in
jenkins
core
in
a
few
plug-ins,
and
it
was
nice,
but
it
had
a
prerequisite
about
the
threading
architecture
of
how
you
use
this
library
that
did
not
match
how
jenkins
actually
worked,
and
we
had
tried
to
work
around
it
with
some
patches
in
the
library.
But
when
we
offered
those
to
the
library
maintainer,
he
said
no.
No.
No.
This
is
not
how
you're
supposed
to
be
using
it.
C
So
that
also
cue.
The
next
slide
requires
some
updates
in
this
case,
not
so
not
quite
so
critical,
because
I
think
nothing
is
going
to
block
you
from
doing
the
update
as
an
admin
after
you
upgrade.
But
you
might
see
a
bunch
of
stuff
broken
before
that
you
could
have
failing,
builds,
I'm
not
sure
what
all
could
break.
So,
that's.
A
Being
on
the
safe
side,
thank
you
jesse,
and
thanks
for
your
work
on
on
the
jenkins
enhancement
proposals
and
what
you've
done
there
much
appreciated,
so
the
asm
upgrade
is
one
that
I've
been
aware
of.
Asm
is
a
bytecode
manipulation,
library
that
was
pulled
into
the
that
is
used
in
the
product
in
various
ways.
A
In
this
particular
case,
the
example
was
that
we
brought
in
a
new
version
of
the
asm
bytecode
library
and
the
token
macro
plugin
had
to
be
updated
to
adapt
to
that
new
one.
If
you
don't
have
the
latest
version
of
token
macro
and
you
can
install
it
still
on
2.263,
but
if
you
don't
have
the
latest
version,
when
you
upgrade,
you
may
get
messages
and
and
warnings
and
failures
that
are
described
in
the
upgrade
guide.
But
this
is
our
way
of
saying
please
oops.
This
one
has
nothing
to
do
with
breaking
jenkins
xml
reader
right.
A
A
B
A
B
Audience,
yes,
we've
got
one
and
yeah.
Please
use
some
coin
because
we
will
answer
any
questions
and
later
they
will
both
of
the
record
discussion
where
you
can
ask
all
the
questions
live.
If
you
want
okay,
so
the
first
question:
do
you
have
any
recommended
way
of
identifying
confused
plugins
in
the
environment,
with
loads
of
projects.
B
A
Well
and-
and
I
confess
I've
just
used
configuration
as
code
and
delete
the
plugin
and
experiment
with
a
prototype.
Now
that's
a
that-
maybe
that's
a
terrible
way
to
say
it,
but
many
times
I
can
look
at
the
plugins
description
and
say:
oh
you
know
what
that
that
is
somebody's
old
thing
that
they
they
brought
in
long
ago.
We
should
just
get
rid
of
it.
C
A
B
We
are
always
looking
for
contributors
because
for
some
plugins,
especially
in
a
long
tail
of
plugins,
with
just
a
few
hundreds
of
installations,
there
are
no
active
maintainers
and
it
takes
time
to
deliver
fixes
there.
So
if
you
use
this
plugin
consider
stepping
up
as
a
maintainer,
and
we
will
be
happy
to
help
you
to
get
started
to
provide
permissions
and
the
reviews
we
needed
looking
for
contributors.
B
B
I
can
start
answering
this
question
because
very
discussions
about
how
we
could
switch
to
the
database
and
moreover,
they
do
some
research
about
that.
And
if
you
go
to
jenkins
jabs,
you
can
find
a
jab
213
which
actually
provides
configuration
storage
api.
I
will
put
the
link
to
the
chat,
so
this
job
hasn't
been
fully
implemented,
but
in
principle,
it's
possible
so
that
exporting
configurations.
B
To
the
database,
whether
you
should
use
that
it's
a
good
question,
because
my
personal
recommendation
would
be
to
just
use
configuration
as
code
infrastructures
code,
so
basically
a
combination
of
jks,
plug-in
and
pipeliners
code
job.
They
said,
if
you
need
it
and
then
you
don't
really
need
a
database
to
store
your
configuration
because
your
jenkins
becomes
immutable.
C
Between
the
configuration
and
the
runtime
data
produced
by
builds
so
certainly
for
the
configuration
itself,
the
configuration
as
code
is
our
best
recommendation
at
the
moment,
as
far
as
runtime
build
metadata.
Currently,
that
is
heavily
file
system
based
entirely
file
system
based
in
default
jenkins
installation.
C
B
You
can
probably
show
it
so
if
you're
interested
to
find
this
information,
you
can
just
go
to
the
jenkins
site.
There
is
cloud
native
seek
which
has
been
historically
working
on
plugable
storage,
and
here
you
can
find
statuses
for
the
main
artifact
types,
so
artifacts
credentials,
system
logs
test
results.
That's
what
available
for
preview?
Also
fingerprints,
which
is
octopus
online
20
project,
but
yeah
for
build
logs.
B
It's
only
partially
implemented
for
pipelines,
but
you
can
use
it
and
task
logs
calculations,
code,
coverages
and
build
storage
is
what
we
haven't
implemented
yet,
but
in
principle,
it's
possible
to
implement.
We
are
just
looking
for
contributors
and,
if
you're
interested,
please
join
the
cloud
native
seek
meetings
because
we
can
collaborate
and
get
other
entities
implemented.
A
Okay
thanks,
so
we
we
have
an
additional
question.
The
question
is
specific
to
a
particular
plugin.
I'm
not
familiar
not
as
familiar
with
this,
as
I
might
like
to
be
it
is,
is
the
ui
for
post
build
action
drop
down
in
jobs
also
resolved,
so
previously
they
were
not
able
to
scroll.
I
had
to
zoom
out
the
browser
just
to
see
it,
and
I
I'm
not.
I'm
not
sure
I
recognize
this
one.
I
don't
know
that
I've
seen
it
have
any
of
our
panelists
or
oleg.
B
A
Now
the
question
has
been
asked:
are
there
any
changes
that
would
require
code,
refactoring
of
user-defined,
declarative
pipelines
or
scripted
pipelines
so
jesse
this
one
might
be
one?
Are
you
aware
of
anything
in
the
streaming
of
the
serialization,
the
extreme
code
or
the
authentication
code
that
would
require
pipeline
changes.
C
No,
there
shouldn't
be
anything
okay
yeah.
This
should
all
be
invisible
from
the
perspective
of
someone
using
jenkins.
Definitely
there
would
be
changes
for
people
writing
plugins,
but
as
long
as
you're
writing
regular
pipelines
using
the
sandbox,
there
should
be
no
effect
now,
if
you're,
if
you
have
you
know
groovy
libraries
or
other
unsandbox
code,
that's
doing
strange
things
with
jenkins
internals
using
direct
java
calls
then
you're
in
the
same
category
as
a
plugin
and
it's
possible,
but
unlikely
that
would
be
affected.
A
A
B
A
C
The
way
that's
implemented
basically
involves
scanning
every
build
of
every
project
in
the
jenkins
controller,
in
reverse,
chronological
order
going
back
to
the
beginning
of
time,
loading
the
xml
records
for
all
of
those
and
then
checking
each
one
to
see
did
it
occur
on
this
particular
agent
and,
if
so,
show
it
in
the
list
which
will
work
for
a
small
system,
but
it
it
can
definitely
cause
io,
thrashing
and
serious
performance
problems
on
big
systems
and
to
implement
it
for
pipeline.
It
would
be
worse
because
of
the
the
pipeline.
C
B
Thanks
jesse,
thank
you
very
much.
Thank
you.
There
was
one
question
which
I
accidentally
moved
to
answered
about
performance
where
I
can
find
performance
reports
about
the
jenkins,
for
example,
how
many
files
I
can
handle
it
in
the
jenkins
home
and
how
many
jobs
simultaneous.
I
can
run
with
a
specific
resource
and
configuration.
A
Okay,
so
that's
as
the
documentation
officer,
that's
an
indelicate
indelicate
thing
for
me
to
painfully
acknowledge.
We
don't
have
an
awful
lot
of
performance
data
on
the
jenkins,
the
jenkins
public
site.
We've
got
some
rudimentary
guidelines
there,
but
that's
about
it
and
and
in
general
jenkins
at
scale.
There's
been
some
interesting
talks.
A
talk
from
stephen
connolly
some
years
ago
on
running
live
the
largest
jenkins
cluster.
A
B
So
resource
requirements
really
depend
on
what
tasks
you
execute
with
jenkins
and
if
you
want
to
do
performance
testing
for
your
instance,
there
are
some
guidelines
which
you
can
follow,
or
just
use
standard,
java
development
tools
and
begin
from
there.
But
yeah
targets
will
be
really
dependent
on
what
the
system.
A
Thanks
so
we've
got
another
question
that
arrived
for
cloud
images.
I
often
see
them
become
unavailable
during
the
job
and
then
the
job
just
keeps
running
until
it
times
out
or
is
manually
killed.
Are
there
plans
to
add
any
pipeline
scripting
options
to
capture
when
an
agent
fails,
so
that
that
portion
of
the
pipeline
can
be
relaunched
on
a
new
agent.
C
Yeah,
that
is
something
that
has
been
proposed.
I
mean
it's
it's
possible
to
do,
but
it's
awkward
essentially
right
now,
so
you
can
have.
For
example,
you
can
have
a
retry
block
that
just
you
know,
retries
the
whole
chunk
of
work,
including
allocate,
including
requesting
an
agent
waiting
in
the
queue
for
it
to
become
available
connecting
to
it
doing
your
build
process
and
the
cleanup
at
the
end.
B
A
Thank
you
good
all
right,
so
we've
got
another
question
about
related
to
plug-in
downloads
change
to
artifactory.
I'm
not
sure.
I
recognize
that
I'm
not
aware
of
any
change
in
the
plug-in
mirror
infrastructure.
As
far
as
I
know,
we're
still
using
our
publicly
maintained
mirrors
throughout
the
world
mirrors
in
china
in
japan,
in
the
us
three
or
four
of
them
in
europe,
three
or
four
of
them.
So
I'm
not
sure
I
do
do
others
on
the
panel
know
anything
that
I
need
that
maybe
I've
missed
with
regard
to
artifactory
plug-in
downloads.
B
C
B
Okay,
configuration
is
called
plugin,
so
if
you
talk
about
plugin
installation
manager,
it
downloads
from
update
centers,
it
does
good.
Okay.
If
we
talk
about
other
custom
tools
like
let's
say,
custom
work,
the
install
plug-in
csh,
all
of
them
also
download
from
mirrors,
so
the
only
thing
which
downloads
from
artifactory
and
all
about
is
this
thing?
So
if
you
go
to
the
list
here,
you
get
the
artifactory
vertical.
A
Yeah
so
now
now
there
was,
there
was
a
request
to
to
assure
that
we
sanity
check
that
the
use
of
of
repos.jenkins.ci.org
was
legitimately
for
the
jenkins
project,
and
so
we
did
have
to
change
some
things
where
we
had
mistakenly
allowed
some
tools
to
be
uploaded
to
the
artifact
repository
those
needed
to
be
held
elsewhere
because
they
weren't
strictly
related
to
jenkins.
So
we
we
did
that.
But
that's
that's
about
all
that.
I
know
about
with
regard
to
artifactory
changes.
A
B
A
B
Maybe
before
we
go
that,
so
there
was
a
question
about
post
directions,
I
can
just
show
you
how
it
looks
like
so
I
have
a
test
instance,
it's
basically
very
recent
lcs
release,
and
here
you
can
see
post
built
actions
like
how
they
look
like
now,
so
the
most
of
possible
actions
are
compatible
with
the
changes
they
have
been
also
updated,
and
here
you
can
see
that
even
message.
Actions
with
a
lot
of
configurations
look
quite
well
on
the
new
interface
so
yeah.
B
D
A
A
They
have
their
own
pipelines
that
run
unit
tests
using
junit
pipeline
testing
framework,
but
because
they
don't
have
var
steps,
they
aren't
able
to
pick
up
the
tests
covering
any
kind
of
percentage.
So
I'm
not
sure
is
there
a
recommended
way
to
handle
how
you
develop
pipeline
shared
libraries,
I
guess
is:
I
think,
what
the
what
the
user
is
asking
and
I'm
not
sure
that
we've
got
the
right
panel
here,
but
let's
go
ahead.
B
B
There
is
no
strict
difference,
whether
you
use
vars
or
whether
you
use
classes
except
of
encapsulation.
If
you
want
to
see
one
of
reference
pipeline
libraries,
you
can
just
go
to
the
jenkins
project.
We
have
a
pipeline
library
here,
so
this
is
pipeline
library
which
actually
builds
junkies,
plugins
and
many
other
components.
B
So
here
you
can
see
the
layout
we
use
in
the
project
directly,
so
we
have
jenkins
files.
We
have
maven
project
which
basically
triggers
pipeline
unit
as
as
well
as
some
static
analysis,
etc
and
here's
our
pipeline.
So
you
can
see
here
that
we
also
use
vars
so,
for
example,
build
plugin.
We
invoke
in
pretty
much
every
jenkins
file
et
cetera
there
bars,
but
we
also
have
some
classes,
not
that
many
at
the
moment.
B
C
Yeah
the
question
was
specifically
about
code
coverage
during
tests
and
I
don't
know
I
will
say
that
under
the
archetypes
repository
there
are
a
couple
of
samples
of
defining
libraries.
I
can't
remember
whether
using
vars
or
source
or
both
that
includes
usage
of
the
test
system,
but
I
don't
believe
that
includes
any.
B
C
D
B
C
B
For
that
a
couple
of
years
ago,
I
had
a
similar
issue
with
documentation,
because
I
wanted
to
create
a
documentation
generator
for
pipeline
libraries
and
somewhere
in
my
github.
I
have
a
converter
code
which
basically
converts
pipeline
library,
including
course
directory
and
standard
classes,
so
that
groovy
tools
can
process
them.
C
The
only
higher
level
advice
I
would
have
is
that
if
your
code
in
the
groovy
library
is
complex
enough,
that
you
feel
the
need
for
code
coverage,
then
you
should
probably
be
working
to
simplify
it
and
move
most
of
that
logic
into
external
processes
that
don't
require
any
complex
setup
to
launch.
That's
just
run
this
python
script,
something
like
that
and
for
the
cases
where
you're
genuinely
interacting
with
jenkins
and
genuinely
do
need
some
sort
of
logic.
C
The
the
use
of
a
mock
framework
like
the
pipeline
testing
system
is
going
to
be
somewhat
awkward
because
it's
not
going
to
give
you
all
that
realistic
a
view
of
how
this
is
actually
being
used
in
the
context
of
the
system,
so
you
might
consider
sort
of
higher
level
end-to-end
integration
tests
at
that
point,
but
there's
not
a
single
clear
answer.
I
think.
B
Yeah
for
integration
tests,
we
have
two
frameworks.
One
is
jenkins
test
harness
which
you
can
use
for
testing
pipelines
like
we
do
for
plugins.
Another
more
advanced
way
is
jenkins
file
runner
and
the
frameworks
around
that,
for
example,
jinx
runner
test
harness,
which
you
can
try,
but
yeah.
This
is
a
more
complicated
way
and
it
doesn't
fully
cover
all
the
functionality.
B
B
Also,
you
can
use
test,
containers
and
other
rules
in
order
to
provision
environments,
if
you
want
to
do
it
for
the
test
and
this
framework
can
be
successfully
used
with
pipeline
libraries
as
well.
So
even
if
we
developed
it
for
testing
plugins,
it
can
be
used
for
advanced
pipeline
library,
testing
and
junkies
file
test
as
well.
B
B
You
should
you
should
have
test
right
yeah
here.
It
is
so
test
pipeline
compatibility,
really
simple
example,
which
basically
runs
a
pipeline
on
a
jenkins
instance
and
verifies
some
results.
Obviously,
you
can
create
more
complicated
examples
with
agents
with
additional
tools,
environments,
and
you
can
also
use
configuration
as
code
rules
to
automatically
configure
your
entire
system.
B
B
And
the
answer
is
yes,
it's
possible
because
when
we
talk
about
forms,
yes,
there
are
configuration
forms,
but
actually
there
are
many
other
forms.
So,
for
example,
if
I
just
start
build
with
parameters,
here's
also
a
configuration
for
my
password,
and
here
then,
if
something
breaks
breaks
in
this
plugin,
so
the
layout
will
be
impacted.
A
A
A
B
B
B
Also,
keep
in
mind
that
the
configuration
layout
is
just
the
first
iteration
and
there
will
be
more
changes
in
layouts.
For
example,
team
has
already
proposed
a
pull
request,
which
changes
run
summaries
page
to
from
tables
to
this.
So
we
will
keep
working
on
that
improve
accessibility
of
the
jenkins
web
interface
and
in
the
next
releases,
so
there
will
be
more
significant
changes.
A
So,
like
you
noted
that
we
were
approaching
sort
of
our
end,
I've
I've
got
questions,
but
I'm
okay.
With
deferring
my
questions,
I
think
we've
got
most
of
the
questions.
We've
got
the
questions
answered
from
the
the
audience.
Were
there
any
comments
that
tim,
jesse
or
felix
you
wanted
to
share
as
we're
as
we're
at
this
about
one
hour
into
the
webinar
mark.
B
So
before
we
close,
we
will
appreciate
your
feedback
about
the
github,
so
we
can
address
feedback
in
future.
Meetups
make
them
better
and
specifically
we're
interested
to
know
what
topics
would
you
like
to
hear
the
next
meetups,
because
me
you
want
to
organize
small
online
meetups
and
any
inputs
would
be
appreciated
and
if
you
want
to
present
the
jenkins
online
meetup,
please
contact
us,
because
we
are
looking
for
speakers
and
we
are
happy
to
host
any
meetup
related
to
jenkins
development.
The
case
studies
and,
basically,
everything
which
includes
jenkins.