►
From YouTube: 2021 01 19 Jenkins Infra Meeting
Description
Jenkins infrastructure meeting with a discussion of
A
Hi
everybody-
I
guess
it's
recording.
So
let's
start
this
new
jenkins
infrastructure
meeting
today
we
have
multiple
things:
the
agenda,
in
fact,
we
have
quite
a
lot
of
things
to
the
agenda.
The
first
thing
is
regarding
the
mirror
infrastructure,
the
current
states,
so
I
contacted
the
salvarian.com
mirror
maintainer
and
he
told
me
that
they
had
some
maintenance
plan
with
the
red,
so
I'm
waiting
for
some
feedback
from
there.
A
So
basically,
you
just
run
a
helm,
helm
install
with
a
path
with
a
link
to
the
to
the
hand,
chat,
and
then
it
will
automatically
deploy
a
nursing
server,
an
http
server
and
a
cranjob
that
will
irregularly
like
every
five
minutes,
synchronize
with
one
mirror
provided
by
parameter
right
now
we
are
targeting
the
osceola
style
mirror,
but
yeah.
This
is
something
that
can
be
easily
changed
in
the
future.
A
What
I
would
like
to
have
is,
I
would
like
to
publish
that
and
version
the
mirror,
so
we
can
start
asking
contributors
to
install
that
mirror
if
they
don't
want
to
run
on
kubernetes,
I
mean
that's
fine
as
well.
Everything
is
explained
in
the
in
the
hem
chart,
so
they
can
easily
adapt
the
service,
but
basically
we
we
start
to
need
more
mirrors.
A
A
Topic
yeah
sounds
like
we
can
continue,
then.
The
second
topic
is
about
maintenance
on
infrared
ci
and
released
ci.
So
basically,
we
want
to
switch
to
the
hand.
So
we
are
using
the
hem
chat
for
the
jenkins
helm,
chats
in
our
infrastructure,
and
we
are.
We
would
like
to
switch
to
version
three
and
because
there
are
some
breaking
changes
in
the
configuration
we
need
to
plan
that
upgrade
carefully.
We
shouldn't
have
major
issues,
but
yeah
still
still
be
ready
to
have
those
two
environment
down.
B
A
Okay,
so
basically,
we
initially
plan
to
do
that
upgrade
tomorrow
afternoon,
but
because
of
the
weekly
release
that
is
delayed
right
now,
we'll
probably
do
that
on
a
thursday
afternoon,
yeah,
probably
I
still
have
to
announce.
I
sent
an
email
on
the
mailing
list.
It
should
not
affect
users,
obviously,
because
it's
only
concerned
release
dot
ci
ends
in
infrared
ci,
but
yeah
still,
because
we'll
have
to
delete
that
that
upgrade.
A
A
Couldn't
we
use
to
get
up
level
filter
to
filter,
to
stop
building
every
pr
for
jenkins
core,
so
this
is
something
that
garrett
introduced
on
infrared
ci,
so
using
the
github
level,
filter,
plugin,
and
so
basically
is.
If
you
specify
a
label
on
a
pr,
we
stop
building
that
pr,
and
I
think
it
could
be
useful
for
still
prs
on
the
jnk
nci
on
the
car.
On
the
main
couch
repository
before
I
sent
an
email
on
the
dev
mailing
list.
Any
suggestions
here
like
mark.
C
A
D
C
D
D
A
A
C
C
D
A
C
Olivia,
you,
you
see
indications
on
cid.jenkins.io
that
rebuilds
of
jenkins
core
prs
are
a
significant
burden
on
the
on
the
processing.
The
ones
I
had
seen
were
acceptance
test,
harness,
which
was
quite
different,
you're
you're,
seeing
even
core
pr,
the
60
or
so
that
are
open
right
now
they
are
a
real
burden
on
on
ci.
A
D
A
So
basically
yeah.
I
have
to
see
because
obviously
using
that
the
that
that
label
approach
for
jenkins
core
is
quite
easy,
because
we
don't
have
a
lot
of
configuration
to
change
and
if
we
decide
to
go
with
every
plugin
for
every
plugin,
maybe
it
will
be
easier
to
first
convert
ci
to
jenkins.io
to
a
gcask
configuration
before
doing
that.
So
we
are.
We
already
have
the
gps
configuration
for
infrared
ci
garrett
worked
on
that
over
the
past
weeks
and
it's
working
well
right
now
so
yeah.
C
A
Yes,
okay
thanks!
So
it's
not
so
sorry,
it's
not
so.
We
have
component
force
the
hydrogen
in
the
io.
We
did
some
tests,
so
basically
team
jacob
did
some
work
several
months
ago.
Maybe
almost
a
year
ago
now
we
already
have
gene
cast
configuration
for
a
lot
of
components,
but
maybe
not
for
everything
related
to
citations.
A
A
We
have
quite
a
lot
of
components
in
place
because
of
the
work
done
by
damien
to
build
docker
images
to
simplify
the
build
and
test
docker
images,
I
think,
would
be
nice
to
move
forward.
This
thing
as
well.
Garrett
made
a
small
cli
to
automatically
update
a
plugins
touch
jenkins,
the
plugins.txt
file.
So
I
don't
know
if
you
can
do
a
quintimore
of
that.
B
B
It
seems
to
work
quite
nicely.
It
obviously
is
quite
dependent
on
the
version
of
jenkins
that
you're
running,
so
you
can
pass
in
a
path
to
the
docker
file
and
it
will
try
and
best
guess
the
version
of
jenkins
if
you're,
using
lts
or
not
using
lts
and
you've
got
a
version
in
there
it
can.
It
can
extract
that
out.
D
A
A
And
so
you
can
specify
the
plugin.txt
that
you
want
to
update.
You
specify
the
jenkins
version
that
you
are
targeting
and
based
on
that
it's
queries
the
update
center
url
and
then
show
you
what
are
the
plugin
version
available
for
that
specific
jenkins
version
and
then
obviously
we
can
commit
that
file
to
the
git
repository
and
so
on
and
the
new
images.
So
it's
I
mean
the
binary
is
quite
small.
It's
like
11
megabytes
and
it
could
be
easily
integrated
in
our
workflow.
A
B
C
B
B
C
Well,
and-
and
is
this
kind
of
thing
something
that
long-term
we
might
consider
putting
into
plug-in
installation
manager?
I
know
it
would
be
different
because
it's
java
instead
of
golang
but
oleg,
you
noted
that
there
is
there's,
there's
some
potential
for
this
to
be
needed
in
in
our
docker
image
context.
C
D
D
A
C
I
did
just
as
a
warning
that
some
of
the
regressions
that
are
included
in
2.263.2
may
be
significant
enough.
That
we'll
want
to
do
an
out-of-order
release.
It's
not
a
known,
yet
this
is
definitely
not
a
oh
yes,
absolutely
it's
rather
just
a
hint
that
we
may,
over
the
coming
days
or
weeks,
decide
that
there
is
enough
in
the
for
what
will
be
in
2.276
that
we
want
to
include
those
into
an
out
of
order,
lts
release.
C
Yeah,
so
the
idea
is
that
we'd
like
to
take
advantage
of
virtual
to
do
a
combined
meeting
session
first,
where
60
to
90
minutes,
probably
in
the
european
late
evening
afternoon,
or
you
know,
think
think
sometimes
between
3
and
6
p.m.
European
time
so
be
switzerland,
time
and
belgium
time
roughly
there
to
do
an
initial
startup
session,
where
we
invite
everyone
who
will
be
part
of
it,
then
we
break
out
into
separate
sessions
with
time
zones
focused
on
meeting
the
needs
of
the
people
in
that
subgroup.
C
C
A
Now
I
I
just
wanted
to
highlight
that
the
reason
that
we
bring
the
code
the
reason
why
what
we
want
to
do
the
contributor
submits
around
for
them
is
because
we
usually
took
advantages
of
the
fact
that
everybody
was
at
first
then,
or
at
least
a
big
big
amount
of
people.
The
thing
is
because
this
time
it's
a
virtual
event,
we
want
to
take
the
opportunity
together
together,
but
we
don't
have
constraint
physical
constraints,
so
we
we
can
split
the
event
on
multiple
days.
So
I
think
that's.