►
From YouTube: Platform SIG 2020 02 13
Description
Jenkins platform special interest group meeting February 13, 2020. Topics include Docker image build optimizations, Git LFS installation techniques, AdoptOpenJDK progress, and a brief report on platform conversations at FOSDEM.
A
A
A
Then
we've
got
a
question
from
a
submitter
or
a
question
or
a
statement
of
a
project.
That's
in
progress
that
we'll
talk
about
related
to
rework
of
the
agent
projects,
then
Jim
you've
got
a
topic
on
reducing
that
workload
for
publishing
images
and
a
second
topic
on
how
good
LFS
is
installed
in
docker
files.
Yep
great,
thank
you.
Any
other
topics
you
wanted
to
add:
Jim
nope.
A
B
A
A
Great,
so
I've
still
got
the
open
action
item.
Hang
my
head
in
shame
open
at
a
Jenkins
enhancement
proposal
for
docker
operating
system.
Support
rules.
Sorry,
likewise
for
Oleg
on
the
windows,
support
policy,
the
one
that
has
had
some.
What
I
call
progress
and
non
progress?
Is
we've
changed
blocking
modes
on
the
call
code
signing
instead
of
being
blocked
on
finding
a
vendor.
We've
got
a
vendor.
A
What
we're
now
trying
to
work
through
is
the
legal
legal
entity
definition
things
to
allow
them
to
issue
a
signing
certificate
to
what
is
not
a
corporation
and
not
a
person.
So
there's
certainly
organizations
that
have
done
this
before,
but
they're
working
through
legal
discussions
and
no
because
it's
involving
lawyers
I,
don't
know
when
it
will
complete
its
just
ongoing.
A
So
next
topic
will
we'll
skip
this
one.
There's
a
there's,
an
ongoing
question:
can
we
do
more
to
get
rid
of
the
use
of
the
deprecated
term
slaves
inside
the
Jenkins
Jenkins
environments,
and
one
is
that
the
docker
agent
docket
images
actually
used
the
word
slave
in
their
name.
We'll
discuss
that
in
another
session.
A
Glad
to
note
that
there
are
google
Summer
of
Code
2020
project
ideas
that
are
being
run
from
inside
the
platform,
special
interest
group
that
includes
the
get
plug
to
get
plug-in
project
ideas
and
several
others
get
the
google
Summer
of
Code
2020
timeline.
We
are
now
inside
the
period
where
we
have
submitted
our
application
to
the
google
Summer
of
Code
project
and
we're
hoping
to
hear
and
the
timeline
says
their
answer
will
come
back
in
a
relatively
few
weeks.
A
The
recording
of
the
google
Summer
of
Code
team
meeting
for
the
Jenkins
project
from
just
a
few
days
ago
includes
a
review
of
the
timeline
as
presented
by
Oleg
Natasha.
So
this
looks
really
good
and
it
looks
like
we're.
Gonna
have
an
even
better
google
Summer
of
Code,
they
sure
than
we
did
last
year.
Awesome
now
the
next
topic
on
the
list.
This
one
was
a
rework
item
that
is
just
here
is
included
in
this
list
for
information.
A
A
user
has
submitted
the
following
and
I'm
going
to
increase
the
size
of
this,
so
that
we
can
read
it
together,
so
they're
using
docker,
jnlp
slave
and
ssh
slave
and
the
docker
slave
image,
and
they
need
it
with
newer
versions
of
open
JDK.
But
those
newer
versions
of
open
JDK
are
not
yet
included
in
those
base.
Images
and
he's
proposing
a
significant
rework
of
the
structure
of
the
projects
to
allow
easier
introduction
of
new
images
and
to
adapt
more
readily.
Oleg
said
hey.
A
This
is
this
looks
good
to
him
and
gave
some
initial
warnings
on
hey.
It
might
be.
This
might
be
a
problem
in
these
areas,
but
it's
a
really
great
thing
to
be
doing,
and
it's
been
mentioned
in
in
other
poll
requests
that
are
open.
So
there's
some
progress.
There
I
haven't
seen
much
recently
on
the
project,
so.
B
A
Repositories
right,
correct,
that's
right,
okay,
so
it
is.
This
is
just
touching
agents
and
and
but
I
think
I
think
you've
got
a
good
point
that
it's
likely
worth
it
as
we're.
Considering
alternatives
for
the
the
main
docker
repository.
Should
we
look
at
the
ideas
that
are
involved
here
and
evaluate
them
hey
with
this?
Would
this
help
the
main
repositories
build
process,
yeah,
mm-hmm.
B
A
A
B
Yes,
yes,
so
it
might
not
be
exactly
helpful
for
you
guys
right
now,
but
it
was
definitely
something
I
took
note
of,
because
adopt
did
get
blocked
in
terms
of
pushing
alpine
images
to
the
official
repository,
because
when
you
were
using
the
well
one
of
the
reasons
due
to
using
live
GC,
you
know
on
Alpine
instead
of
using
muscle,
and
then
we
did
have
enough
testing
currently
at
the
time.
But
worse
than
that,.
A
B
B
A
I
think
we're
on
to
our
next
topic
and
ideas
for
reducing
workload
for
publishing
images.
Jim.
Can
you
give
for
people
like
me,
I,
don't
know
the
details
of
the
image
publishing
process
so
tell
the
shell
that
share
the
story
with
us.
I'll
take
some
notes,
I'm
actually
going
to
mute
so
that
my
keyboard
is
not
is
not
terribly
left.
B
A
B
B
If
you
want
to
take
a
look
at
that
eventually,
but
what
happens
is
when,
when
we
trigger
a
build
and
I'm
pretty
sure
it's
a
manual
process,
so
Daniel
Beck
or
whoever
is
in
charge
of
the
builds
I'm,
not
sure
who
those
people
are
I
have
to
kick
it
off.
What
happens?
Is
it
grabs
the
last
30
I,
think
of
production
and
grabs
the
last
30
releases
of
Jenkins
on
the
experimental
build
so
like
the
multi
arch
I?
B
Think
it
grabs
the
last
20,
but
it
grabs
a
significant
amount
of
the
Jenkins
builds
and
what
it
does
basically
loops
through
and
starts
building
images,
but
before
it
pushes
the
images
it
checks.
If
the
tags
already
exist
up
in
docker
hub,
if
they
do,
they
do
not
push
them.
Assuming
that
the
images
they
just
built
or
the
same
as
images
of
the
entire
hub
after
that's
done,
they
go
ahead
and
start
making
more
tags
in
terms
of
like
okay,
hey.
This
is
a
LTS
image
for
Debian.
B
B
You
know
a
update
to
a
certain
variant.
So
if
we
need
to
update
just
Debian,
it
takes
a
lot
of
time
because
there's
no
way
to
controller
right
now,
via
the
pipeline
that
we
have
said
you
guys
have
set
up
on
like
hey
I,
just
want
to
rebuild
Debian
or
I
just
want
to
rebuild
Alpine
or
sent
away.
So
there's
there's
no
way
to
do
that.
It's
lit
hey,
Greg
last
30
releases
and
then
go
through
every
single
variant
that
you
guys
support,
which
isn't
very
intensive.
B
So
he
was
saying
that
the
way
he
wanted
was
a
quicker
way
to
kind
of
streamline,
streamlined
building
and
actually
my
PR.
It
actually
addresses
a
lot
of
the
the
issues
that
he
brought
up
in
the
glitter
chat,
but
that's
kind
of
gist
of
how
it
works
right
now,
and
some
of
the
downfalls
of
it
and
I
can
get
you
that
PR
right
now.
If
you
want
to
take
a
least
a
little
look
at.
B
A
I'm
there
either
is
either
is
great,
so
if
you
want
to
put
it
right
in
the
meeting
notes,
that's
probably
simpler.
If,
okay,
whatever
works
for
you,
yeah
I,
just
I,
just
I,
just
put
it
down
so
perfect,
all
right,
because
I
wanted
to
open
that
up
and
take
a
look
at
it
together.
It's
a
good
excuse
for
us
to
look
at
it.
Yeah.
B
I
know
the
the
FOSDEM
kind
of
I
wanted
to
get
this
in
front
of
you
guys
two
weeks
ago
or
I
guess
would
have
been
four
weeks
ago,
whatever
it
is,
but
now
it's
a
really
good
opportunity.
I
was
hoping
old
I
wouldn't
be
here
exceed
he
was
the
one
also
talking
with
Daniel
back
and
also
slide
actually
was
too
about
the
whole
builds.
B
So
some
of
the
major
changes
I
went
through
is
currently
you
guys
are
using
the
the
manifest
tool.
The
manifest
tool
to
build
manifest
is
for
docker
was
made
I.
Think
I
should
buy
a
IBM
er,
but
what
happened
it
was
made
before
docker
docker
manifest
the
command
actually
got
integrated
into
docker,
and
it's
docker
manifest
is
still
in
experimental.
B
It's
still
like
in
kind
of
like
a
technically
beta,
but
it's
what
we
use
internally.
It's
what
a
lot
of
companies
actually
used
to
build
manifest
manifest
yeah
I,
guess
that's
a
plural.
So
what
I
did
was
I
swapped
to
docker
manifest
instead
of
the
manifest
tool?
Hey.
That
gives
us
a
little
better
use
of
things
in
terms
of
it's
just
native
docker.
B
We
don't
need
another
tool
and
it
gives
us
some
cool
extra
things
we
can
do
later
on
in
terms
of
instead
of
like
hitting
Dockers
API,
we
can
just
hit
Dockers
a
command-line
and
parse
out
the
information
we
need,
where
the
API
usually
changes
a
lot
and
where
I
should
seeing
that
in
adopt
well,
the
docker
manifest
should
always
roughly
point
the
same.
You
know
end
point
whatever
they
change
it.
To
should
roughly
give
you
the
same
output.
A
B
All
good,
it's
very
simple,
you'll,
pretty
random
money
that
there
it's
really
a
metal
file
that
basically
says
hey
here.
So
for
one
manifest,
you
guys
have
this
LTS
right
for
LTS
right,
you
might
be
producing
a
s/390
image
when
I've
been
pushing
like
a
arm
a
v60
for
what
it
does.
Is
you
basically
said:
hey
I
want
to
have
one
tag
called
LTS
right
and
in
this
LTS
tag,
I
want
its
own
poster.
S/390
I!
Want
it
to
point
to
this
specific
image
if
someone
pulls
for
amd64
point
to
this
specific
image.
B
So
when
what
happens
in
reality
is
when
I
do
a
darker
pull
Jenkins
LTS,
it
goes
up
and
hits
the
docker
API.
It
looks
at
what
arch
I'm
running
and
then
basically
points
me
into
the
right
image
and
pulls
down
that
specific
arches
image.
This
is
very
helpful
because
you
know
you
don't
need
to
worry
about
hey.
Let
me
pull
from
s/390
Jenkins
and
blah
blah
blah.
It's
just
one
universal
image
image
and
because
very
important
place
in
IBM,
where
we
are
doing
constant,
builds
on
any
type
of
arch.
B
A
Oldest
thank
you.thank
that
so
that
means
that's
why,
for
instance,
even
in
my
world,
where
I
don't
have
access
to
s/390,
but
I
do
have
access
to
arm
boxes,
for
instance.
So
this
would
allow
me
to
say:
docker
run
Jenkins
size,
Jenkins,
:
LTS
on
my
arm
box,
and
it
would
automatically
detect
all
your
unarmed
I
need
to
go.
Get
the
arm
image
instead
of
the
x64
image.
Yep.
B
And
then,
if
some
some
reason
they
they
didn't
put
push
the
arm
image
in
the
manifest.
It
would
basically
come
back
saying:
hey
no,
no
image
for
that
platform
found.
So
you
can,
in
official
images
a
lot
of
fishel
images.
Go
through
the
docker
library
build
pipeline,
which
the
Jenkins
server
that
has
access
to
all
the
arches
and
then
thus
gets
you.
You
know
hey
a
manifest
file,
but
some
of
them
don't
build
for
arm.
So
if
you
go
to
like
pull
hey
like
docker
Ubuntu,
you
know
1604
right.
B
No,
it's
good.
It's
good
background
info
all
right,
so
we
basically
just
for
that
whole
kind
of
bullet
note,
is
switching
to
docker
manifest
instead
of
having
this
whole
another
tool
legacy
tool.
Even
the
next
major
update
is
parallel
builds.
So
what
I
did
is
I
split
up
all
the
builds
and
to
basically
split
it
into
three
stages.
The
publish
images
published
tanks
and
publish
manifests
these
three
different
scripts
that
you
can
trigger
at
different
points
or
just
trigger
one.
B
If
you
wanted,
and
basically
they
do
as
name
kind
of
implies
public
the
published
images
builds
images
and
pushes
onto
docker
hub,
publish
tags.
Does
all
the
tagging
mechanisms
so
hey?
Let
me
tag
this
image
like.
Let
me
take
Debian
ones
as
LTS.
Let
me
tag
whatever
latest
image
is
pointing
to
and
because
you're
just
generating
all
these
tags
and
then
for
docker
manifest.
We
as
you
pull
all
those
tags
and
pull
those
images,
build
the
manifest
and
pushes
the
manifest
files
up,
but
I
did
that
all
the
way
where
hey?
B
If
you,
if
you
want
to
build,
you
know,
if
you
have
all
these
different
variants,
like
Debian,
Debian,
slim
Alpine
right,
they
all
can
build
it
at
the
exact
same
time,
the
colossal
script
that
you
guys
kind
of
were
using
before
which
is
going.
It
was
one
for
loop,
basically
going
through
all
the
different
possibilities
and
wasn't
paralyzed
at
all.
So
you
know
this
provides
speed,
upgrades
and
also
kind
of
going
back
to
Daniel
Beck's
point:
it's
like
hey
I,
really
just
want
to
do.
Update
your
security
update
from
Debian
I.
B
A
B
I
kept
it
that
way
for
an
easier
integration,
but
in
in
my
script,
I
broke
it
up
where
you
can
actually
pass
in
the
version.
Yes,
so
what
it
does
actually
is
gold
collects
twenty
versions,
and
that's
the
only
thing
that's
looping
over
right.
You
you
pass
in
how
you
want
to
build
for
s
through
ninety
I
want
to
build
for
Debian
and
I.
B
Want
to
you
know:
do
you
know
whatever
the
last
parameter
is
and
then
it
basically
loops
over
the
versions
passing
them
in
it's
very
easy
to
just
modify
it
slightly
or
just
have
a
make
command
where
it
it
will
pass
in
a
certain
version,
and
you
can
just
do
it
for
that
specific
one,
great
yeah.
So,
ideally
what
Alex-
and
you
know,
Oleg
and
Daniel
when
I
were
talking
about
it-
would
be
really
nice
to
trigger.
B
If,
if
we
could
set
up
a
github
actions
to
kick
off
of
Jenkins
job
like
github
actions
on
the
official
Jenkins
repo
and
whenever
they
release
a
release,
a
new
release
of
Jenkins
right
have
a
trigger
this
build
pipeline.
We
have
and
do
the
release
so
that
way,
the
gap
between
when
the
Jenkins
gets
released
and
when
the
docker
image
gets
released
is
a
lot
smaller
and
you
know
that
could
be
like
hey.
Let's
push
it
to
the
unofficial
repository
first
and
then
one
of
us
could
come
in
just
make
sure
hey
it
works.
B
That's
why
I
had
a
couple
ideas
of
mine,
but
this
whole
rework
of
the
whole
build
pipeline,
really
addresses
that
when
the
other
major
changes
was
instead
of
building
with
TMU
headers
or
the
qmu
emulation,
we
are
building
our
platform,
so
this
would
require
a
rework
of
how
you
guys
have
it
set
up
in
terms
of
you
would
need
to
have
access
to
the
architecture
and
I
did
that
because
accumulation
isn't
a
hundred
percent,
it's
pretty
good,
but
there
are
some
I
seen
some
handy.
Some
issues
prop
up
on
s/390
and
I.
B
B
A
B
The
github
actions
only
supports
x86
currently,
but
they
also
produce
they
produce
the
support.
Mac,
OS
and
I
think
I
think
we
might
do
arm.
But
the
thing
is
for
docker
builds
it's
just
any
x86
right
now,
so
that
there
are
other
build
pipelines.
I
haven't
looked
into
it
all
that
much,
but
what
I
was
working
with
get
a
large
file
system
and
they
are
using
your
hub
actions
aimed
the
limitation
right
now
is
only
x86
on
docker
builds
got.
A
It
ok
good!
Thank
you,
alright!
So,
but
this
one
this
one
is
the
change
from
QA
Moo
to
building
on
on
the
actual
architecture.
To
me,
that
seems
like
a
positive
just
in
terms
of
reliability.
Yes,
as
I
love,
emulators
native
building
on
the
actual
architecture
seems
more
likely
to
be
successful.
So
ok,
good
yeah.
B
And
for
that
I
we
do
have
an
arch
flag
passed
into
the
host
scripts.
So
if
you
have
existing
x86
architecture,
you
can
just
pass
in
well.
You
know
the
amd64
tag
and
it
just
builds
that
one.
You
know
if
you
had
like
and
then
I
was
thinking
like
you
know.
If
you
have
a
janky
agent
on
us
or
90
cluster
right,
you
could
deploy
workloads
with
the
s3
90
tag
and
stuff,
like
that.
This
is
how
I
was
similar
doing
it.
With
the
example
I
think
I
showed
you
in
Travis.
B
A
B
Added
this
is
a
nice
one
and
so
for
debian
tag
in
the
tagging
schema.
You
guys
had
I
added
a
debian
tag,
so
a
lot
of
years
would
be
like
Jenkins
2.10,
Alpine
210
sent
to
Wes
right
and
there
wasn't
one
for
Debian.
It
was
just
too
dot
ten
right,
I,
think
being
a
little
more
verbose
and
making
sure
it
says.
Debian
I
didn't
delete
any
of
the
tags.
I
just
added
one
more
tag,
the
tag
alias.
B
If
you
will
that
points
back
to
Debian,
to
make
it
a
little
more
verbose
and
for
people
who
are
automating
things
and
maybe
iterating
over
that
variance
or
distro.
It
would
be
nice
to
have
that
we
actually
running
into
a
similar
issue
in
adopt
where
we
just
assumed
the
default
image
is
JDK.
Instead,
Java
Runtime,
environment
and
I'm,
going
back
with
them
and
be
like
hey,
you
guys
need
to
do
verbose
tags.
I,
helps
clarify
everything
right.
A
And
that
makes
sense
to
me
the
so
you
you
didn't
take
away
the
LPS
tag.
You
just
added
one
that
says
this
is
LTS
on
Debian.
Yes,
you
will
point
to
the
same
image:
I
assume
as
or
to
the
same
yeah
to
the
same
yep
Yoshi
56
as
as
the
the
LTS.
It's
just
a
a
way
for
me
to
be
explicit.
Yes,
I
know
I'm
using
Debian
and
reference
into
my
from
clause,
yep,
exactly
100.
B
Cent,
that's
all
I
did
then
I
added
a
dot,
CI
folder.
This
is
what
I'm,
seeing
a
lot
of
like
repositories.
I've
been
working
with
the
open
source
teams.
Basically,
instead
of
putting
all
the
see
I
kind
of
build
pipeline
stuff
in
the
main
repository
you
know
main
folder,
you
don't
want
to
clutter
the
main
folder.
You
want
to
keep
that
as
much
as
like:
hey
here's
our
build
files,
here's
the
plug-in
scripts,
I,
guess
what
you
guys
utilize
for
some
of
the
docker
builds
and
here's
everything
that
goes
into
the
docker
containers.
B
Let's
move
all
the
CI
CD
scripts
to
a
folder.
They
kind
of
keep
it
a
little
more
clean
and
a
little
more
organized,
so
I
moved
the
published
scripts
to
a
dot.
Ci
folder!
You
see
this
with.
You
know
doc
github.
You
know
for
issuing
templates,
it's
just
a
common
practice,
I
least
from
what
I
seen
mm-hmm
doesn't
change
any
functionality.
It's
just
a
little
cleanup,
I
guess:
I
added
a
force
parameter
to
push
the
tags
and
images.
B
No
matter
what
one
of
the
things
was
when
we
are
pushing
basically
ability
the
the
published
images
builds.
The
images
and
checks
if
the
tags
are
up
there,
one
thing
I
want
to
do
is
say:
there's
a
security
patch
right
and
the
tags
are
up
there
right,
saying:
hey,
there's
already
an
image
called.
You
know
LTS
Debian
right,
but
you
just
fada
security
patch.
B
You
want
to
force
that
image
up
there,
even
though
there
is
a
tag
already
up
there
with
the
associated
name,
so
that
would
just
automatically
push
it
no
matter
what
and
that
that
force
parameter
goes
throughout
all
the
different
build
scripts,
so
you
can
have
a
force
framers
set
for
the
build
images
for
parameter
for
the
build
tags
and
force
parameter
for
the
manifest,
so
that
you're
always
pushing.
If
you
have
something
good
so.
A
B
B
It
didn't
necessarily
apply
just
to
everything
like
hey,
just
a
manifest
no
I
mean
so
if
a
maybe
the
force
tag
was
just
for
the
images
right,
but
if
it
saw
the
same
tags
there,
and
you
really
really
want
to
reissue
the
tags
to
point
three
different
images
and
stuff
like
that.
That
wasn't
an
option
same
thing
we
manifest
if
the
the
manifest
needed
to
be
updated,
it
would
just
check
hey
the
manifest
our
exist.
Don't
don't
go
ahead
and
do
it
the
force
tag
wasn't
there
for
those.
B
More
yeah,
yeah,
I
guess
this
is
the
same
thing.
Add
additional
checks
to
make
sure
images
and
tags
are
always
up
to
date.
That
kind
of
goes
back
to
I,
guess,
checking
the
shah's
of
each
images.
Basically
saying
comparing
hey
this
image.
I
just
built
was
Shaw.
You
know
blah
blah
blah
the
image
already
up.
There
is
sha
below
blah.
Are
they
the
same?
Are
they
different?
Okay,
hey
they're
different.
Let
me
push
the
image
because
it
must
have
some
sort
of
security
patch
or
it
must
be
new.
It.
Okay,.
A
So
this
this
additional
check
would
potentially
then
when,
for
instance,
a
Deborah
Debian
operating
system
patch
happens
on
the
base
image
below
yes
mm-hmm.
This
would
get
us
that
base
image
included
in
a
new
image
and
could,
if
we
were
using
force,
I
guess
in
that
case
push
that
image
out.
Yes,
even
to.
B
B
Tried
to
add
as
much
checks
as
possible
to
be
short-circuit
things
so
like
hey:
what's
not
re,
Ryu,
no
waste
bandwidth
and
re
pushed
things
if
it's
the
same
exact
straws
already
up
there,
but
the
jaws
are
different.
We
assume
that
hey,
it
must
be
new,
and
if
you
have
that
force
tag,
it
will
always
push
it.
Even
if
it's
the
same
or
whatever
so
I
thought
those
were
good.
Your
head
is,
there
was
some
of
the
checks
are
in
there.
I
think
they
were
just
going
back.
B
I
think
they
were
just
for
images,
not
just
tags
or
manifests.
So
I
wanted
to
be
a
little
more
verbose
in
the
checking
and
save
bandwidth
and
time
where
I
can.
The
last
thing
is
still
an
ongoing
thing,
so
get
large
file
system,
and
this
is
actually
going
out
to
our
next
agenda.
Point
I,
so
I'll
keep
it
brief
here.
I
was
using
multistage
build,
so
I
was
actually
compiling,
get
a
large
file
system
from
source
and
actually
copying
that
binary
into
the
docker
images,
because
they
didn't
release
for
s/390.
B
They
didn't
release
for
a
power
and
I,
don't
think
they
have
arm
release.
So
I
was
just
compiling
everything
from
source
which
added
a
lots
of
time
in
my
update
and
I'm.
Actually
working
with
get
large
files
system
on,
you
know,
fixing
things
that
should
PR
I,
think
I've
closed
to
add
support
for
s/390
yeah,
so
I'm
actually
having
an
update
to
this
PR
coming
soon,
which
added
those
patches
in
where
it
saves
time
and
not
needing
to
build
everything
again
from
source.
It's
just
actually
pulling
from
these
releases
on
the
github
page
excellent.
B
A
B
A
B
So
I'm
trying
to
get
him
to
apply
a
patch
for
that
and
we'll
talk
more
about
that
in
the
second
gen,
because
there's
there's
some
different
options.
We
can
go
down,
but
this
is
the
general
gist
of
this
hope.
You
are
know
we
took
up
a
large
chunk
of
time
on
this,
but
it
is
a
a
good
rework
of
a
lot
of
things,
and
this
is
just
the
experimental
images.
This
is
nothing
to
impact
the
official
pipeline
you
guys
have
for
the
official
images.
B
A
B
A
B
B
A
B
Yes,
go
ahead,
so
in
my
amid
talking
with
the
maintainers
of
get
FS
they,
so
we
won
the
big
issues
right
now.
I
got
the
building
for
Z
and
you
got
a
bill
from
power,
so
the
binaries
are
up
there.
One
thing
you
guys
were
doing
is
pulling
from
I
guess
they're,
the
most
recent
change
to
those
images
or
all
the
images
is
pulling
from
package
cloud
IO,
which
is
where
they
officially
release
their
images,
are
sorry
binaries
for
Debian
and
I
think
also
young.
They
have
a
young
repository
or
rpm
right.
B
B
A
B
A
The
from
the
get
LFS
project
so
get
pulling
from
github
releases
sounds
even
better
than
using
package
clouds.
So
that's
that's
as
one
of
the
people
who
was
deeply
involved
in
the
in
getting
in
having
git
LFS
included
in
the
images
at
all
I
have
no
problem
with
that
proposal.
That
sounds
great.
It's
okay,
you
know
no
dispute
for
me
it.
It
won't
be
quite
as
easy.
A
I
assume
it
in
the
script,
although
that
that
horrible
script
that
we
are
horrible
is
the
wrong
way
to
say
is
that
piece
of
script
code
that
we
copied
and
pasted
from
package
cloud
IO
will
have
to
have
a
different
script
that
that
copies
from
from
github
releases,
but
you've
already
got
that
right.
Yes,.
A
B
Okay,
so
the
only
the
only
sore
thumb
or
the
thing
that
kind
of
sticks
out
is
alpine
right
now
so
alpine,
since
the
they
have
a
binary
for
linux.
You
know
amd64
linux,
you
know
s/390
right
they're,
all
built
like
we
talked
about
against
g
lib,
see
the
crater
does
have
a
PR
open
and
I
was
actually
working
on
him
about
like
five
o'clock
last
night
on
doing
it.
I
think
he
also
may
be
in
a
different
time
zone
or
whatever,
but
he
looks
like
he
got
off
for
tonight,
so
the
pr
is
open.
B
So
that
would
be
good
in
terms
of
right
now
for
Alpine
I'm,
actually
just
pulling
from
the
Alpine
release
package
of
get
LFS,
which
is
good,
but
it's
not
maintained
by
them
at
all.
It's
some,
some
other
guy,
I,
guess
heavily
involved
in
the
Alpine
community
Spain.
They
also
lag
behind
in
terms
of
versions
right
now.
The
version
there
they
have
is
2.92,
which
is
one
version
behind
the
newest
release,
is
210.
B
We
do
get
it
supported
in
terms
of
the
binary.
So
then
we
can
just
do
the
exact
same
methodology,
we're
doing
hey,
let's
curl
down
the
binary
curl
down
the
signature
file
there.
If
I
install
it
and
we'll
be
good
yeah.
That
states
basically
outlines
the
sore
thumb
here
in
terms
of
it's
not
great
so
but
yeah
like
you
said,
the
current
work
round
could
be
just
the
package
they
provide
or
not
they
pry,
but
the
Alpine
brides
yeah.
So
that's
a
hoping
mess.
I've
been
dealing
with.
A
B
A
A
B
B
A
A
Is
all
and
so
I'll?
Let
me
just
conveyed
here
the
the
link
to
it
so
that
it's
actually
a
mailing
list.
Let's
go
grab
it
real
quickly
here
and
so.
Community
infra
sub
projects,
infra
and
mailing
lists
should
be
this,
and
here
we
go
Jenkins
infra
I
know
that's
the
old
list.
Let's
go
grab
that
and
look
at
the
archive,
or
it
will
tell
us
where
the
new
list
is
mailing.
This
migration
move.
Here
we
go
so
this
is
the
new
list
and
I'll
embed
this
link
into
it.
Awesome.
A
Thank
you
so
much
so,
if
you
just
want
to
send
email
to
that
list,
you
can
get.
The
discussion
started.
Be
sure,
you're,
clear
in
that
email,
that
the
initial
proposal
is
just
just
for
experimental
exactly
because
there
is
a
if
I
understand
correctly,
there's
a
different
process
for
official
builds
and
eventually
we'll
have
to
deal
with
it
for
official
builds.
But
this
is
a
this
is
experimental
stage.
First,
yep,
okay,
good
all
right
and
I
had
started
those
discussions
some
time
ago,
but
did
not
drive
them
to
conclusion.
So
that's
that's
a
yes.
A
B
Only
other
question
I
had
any
beach
for
you
or
maybe
I,
go
back
to
the
gale
LFS
crater
these
on
some
of
the
images,
and
maybe
it's
cuz
command.
You
copy
Coggan
patient
for
the
package.
I.
Oh,
you
guys
are
installing
and
get
LFS
and
then
doing
git
LFS
install.
So
it
looks
like
you're,
initializing
I
guess,
like
the
gate,
LFS
like
Damien,
the
config
files,
or
something
like
that.
It's.
B
B
Additionally
is
it's:
it's
calling
the
install
on
the
root
user
right,
but
then
we
make
a
Jenkins
user
and
switch
to
that
in
that
user.
Space
is
a
is
the
get
you
know.
Lfs
install
needed
in
terms
of
you
know
like
alpine
seems
to
function,
fine
and
then
B.
Is
it
smart
to
have
it?
Do
the
initialize
on
the
user
or
Jenkins
user
I.
A
B
B
B
A
The
all
I
can
tell
you
is
in
my
case
it's
it's
card
occult
meaning
I
learned
to
do
it
long
ago
and
I
don't
bother
even
thinking
about
it
now,
I
make
sure
I.
Do
it
at
least
once
every
time
I
when
I,
when
I'm
in
a
new
machine
and
okay,
is
it
really
needed?
I
have
no
idea,
it
could
be.
That
is
just
entirely
me.
Having
developed
a
conditioned
response.
Oh
yes,
you
need
to
do
get
LFS
installed,
but
it
may
no
longer
be
required
at
all.
Okay.
B
A
B
Pro
it's,
the
Dobb
contribution
is
going
well.
They
were
pushing
forwards
with
that
I.
Actually,
we
redid
the
whole
test
framework,
and
now
they
we
just
need
to
hook
into
the
Jenkins
pipeline.
We
can
test
pretty
much
for
any
of
the
variants.
Any
of
the
base
images
so
hopefully
coming
up
soon,
we'll
see
more
the
the
variants
being
pushed
into
the
official
images
for
adopt
open
JJ,
which
would
be
one
one
one
step
closer
to
becoming.
B
You
know
actually
starting
a
discussion
for
jenkin
and
actually
looking
into
switching
to
adopt,
but
it's
it's
been
a
little.
It's
a
little
slow
progress
over
there.
It's
it's
I,
don't
know
that
much
sigh,
you
know,
I,
don't
know
that
much
Java
development
side
of
things,
I'm
running
all
these
workloads
and
I'm
like
I,
don't
know
I
used
me
even
once,
but
that's
about
it.
So
it's
I'm
diving,
a
deep
without
kind
of
know
what
I'm
looking
at
so
welcome.
B
A
Boldly
go
where,
where
angels
fear
to
tread?
Well
done,
that's
great!
Thank
you
thanks
very
much
so
I'm
gonna,
just
a
brief
comment
on
the
FOSDEM
notes.
I
had
good
conversations
with
several
platform
and
operating
system
vendors
that
our
platform
and
operating
system
teams
that
were
at
FOSDEM
in
Belgium,
for
instance,
the
things
that
that
were
interesting
to
me
were,
let's
see,
I
talked
with
the
Santos
people
about
how
getting
in
AWS
image
and
they
are
working
on
creating
one
suite.
A
So
it
was.
There
was
been
one
where
I've
had
to
do
my
testing
with
images
that
I
found
and
got
lucky
on,
because
there
isn't
an
official
and
they
said
yeah.
We
know
that
I
talked
to
the
FreeBSD
people
about
for
AWS
image
availability
and
yes,
there
are
available
so
that
I
can
do
more
platform
testing
on
freebsd,
using
AWS
images.
Talk
to
the
open
suzy
team.
A
A
And
that's
that
you,
you
make
a
good
point
on
the
free
one
of
the
things
that
I
was
worrying
about
in
having
this
conversation
with
them
is
how
do
we
describe
back
up
for
a
Jenkins
user
and
a
Jenkins
user?
That's
on
a
ZFS
capable
filesystem
should
just
use
snapshots
right.
Yeah
I
mean
they
should
not
waste
their
time,
creating
a
file
system,
backup
when
they've
got
snapshots
built
into
the
operating
systems.
Yeah.
A
Likewise
and
I
confirmed
with
the
butter
FS
people
in
open
Susie
that
they
agreed
snapshots
for
backup
is
the
is
absolutely
what
they
would
recommend
as
well
right.
It's
it's
their
preferred
way
of
doing
it.
They've
got
a
concept
of
doing
like
ZFS
has
with
where
you
can
ship
a
snapshot
to
another
machine,
and
so
so
good
good
progress
there.
A
A
It
actually
has
some
very
specific
knowledge
about
how
to
use
the
FS
very,
very
well
interesting,
but
it's
outdated
because
it
hasn't
been
touched
in
a
very
long
time
and
because
the
Solaris
variants
that
on
which
it
was
based
so
so
needs
needs
more
work
but
is
known
to
work
with
ZFS
using
I
think
it's
called
live
ZFS
native,
so
those
those
things
are
there
and
platform
interesting.
That's
all
that
I
had
from
FOSDEM.
B
A
A
B
Know
I
mentioned
it
to
shell,
you
would
you'd
won
the
then
the
leads
there
she's
the
woman
I've
been
working
with
the
adopt
team
and
she
I
saw
you
joined
the
whole,
adopt
slack
channel
too,
which
seems
pretty
good
she's,
pretty
active.
That
says
she
how
I've
been
communicating
a
lot
with
the
top
team,
and
we
actually
do
have
weekly
meetings
now
or
bi-weekly
meetings
on.