►
Description
Let’s review the current Jenkinsfile Runner status. How is the project doing? What are the obstacles and missing features? What is the roadmap towards the 1.0 release?
Jenkinsfile Runner: https://github.com/jenkinsci/jenkinsfile-runner
Meeting notes: https://docs.google.com/document/d/1QLWXNG23ui-LvQXth3UREzOvLYgTMSZcv-El0H141a4/edit#heading=h.ywqy0v70eb25
A
Into
the
cloud
okay,
so
I
want
to
spend
some
time
to
discuss
drinks
for
granted
experiences
and
what
would
be
the
roadmap
for
the
project,
so
I
believe
that
levy
has
some
experience
with
jinx
followers.
What
about
you,
martin.
A
A
I
still
have
some
items
in
my
backyard,
for
example
leaving
quartz,
because
built-in
timing
is
initialization
and
other
things
which
would
make
it
even
more
performant.
But
currently
performance
is
not.
The
biggest
concern
is
fast
enough.
So
for
me,
the
biggest
problem
is
what
user
experience
we
want
to
deliver
before
the
1.0
release
this
one.
I
would
appreciate
feedback,
especially
from
you
davis,
since
you
use
it,
so
I
lined
up
a
few
topics
which
I
would
like
to
consid
to
finalize.
A
So,
first
of
all,
I
want
to
have
java
17
preview
for
1.0,
maybe
even
before
so
that
ensure
that
there
is
no
breaking
changes
needed.
Also.
We
are
closing
up
interactive,
ui
capabilities
so
that
you
can
start
up
a
junkies
file
runner
in
the
ui
mode
on
demand
and
browse
what
happens
to
them.
Then
I
want
to
finalize
custom
word
packager.
So
it's
the
original
tool
which
was
created
for
jenkins
for
runner,
packaging.
A
So
I
want
to
release
custom
word
packages
2.0,
which
actually
supports
new
packaging
formats
for
gengxis
file,
runner,
so
that
you
can
define
jxfile
runner
as
yaml
and
I'm
about
simplifying
this
file
so
that
I
will
drop
group
ids
everywhere.
So
they
will
be
on
the
artifact
id.
So
plugin,
ids
and
record
will
be
much
more
simple
for
common
cases.
A
Then
yeah
build
time
initialization,
maybe
not
for
1.0,
actually
also,
I
need
to
finish
packaging
because
currently
packaging
relies
on
docker
hub
and
it
became
a
bloody
mess
which
actually
just
needs
to
be
rewritten
so
that
if
the
release
agency
is
used
or
did
have
actions
to
be
defined,
I
also
want
to
have
support
for
techtron
out
of
the
box
and
for
github
action,
but
have
actions
may
come
later
because
right
now,
I
still
cannot
use
work
on
that
and
another
topic
which
I
already
started
and
finish
this
jbank
integration.
A
So
if
you're
not
familiar,
je
bank
is
a
cli
tool
which
can
execute
java
as
script,
and
it
has
a
lot
of
enhancements.
So
probably
we
could
execute
jenkins
file
as
crypt
using
this
engine
without
standalone
tools,
so
that
everyone
who
uses
jbank
they
could
use
jinx
for
the
runner
out
of
the
box.
A
A
A
A
A
C
Yeah,
I
think
it
was
almost
three
years
ago
that
I
found
it
by
accident.
I
think
the
most
challenging
part
is
if
you
are
not
a
if
you
don't
have
a
java
background
or
if
you're
not
in
intimate
with
jenkins,
it
can
be
hard
to
set
up
from
scratch.
C
You
know,
jenkins
is
a
very
customized
tool.
Everyone's,
like
version
of
jenkins,
is
different
because
of
the
plugins
and
how
they
bring
it
up.
You
know
whether
they're
configuring
it
with
jenkins
configuration
as
code
or
maybe
they're,
using
custom,
groovy
scripts,
and
so
in
order
to
use
jenkins
file
runner,
you
almost
always
have
to
customize
it
to
for
you
for
your
liking
and
as
of
right
now,
you
know
you're
going
to
have
to
know
some
java
stuff,
like
you're
still
talking
about
the
packaging.
C
That's
kind
of
a
a
java
thing
you
know,
setting
up
the
jenkins
war
is
kind
of
a
java
thing
and
that's
where
I've
always
struggled
with
getting
it
to
run,
so
I've
never
been
able
to
do
it
on
my
own.
Instead,
I
find
someone
else,
that's
done
it
and
how
they
did
it,
and
then
I
kind
of
modify
what
they
did
to
work
for
me
and
what
I
think
would
really
help,
and
I
created
an
issue.
C
They
already
have
documentation
on
how
to
install
plug-ins
and
set
up
things
like
that,
and
then
all
the
jfr
repo
would
have
to
do
is
probably
give
you
know
like
a
java,
a
docker
file
that
started
with
the
community
image
so
from
jenkins,
jenkins,
lts
and
then
provide
three
or
four
lines
to
execute
to
install
the
jfr
binary
into
that
con.
You
know
into
that
and
then
have
that
pre-configured
to
use
the
existing
installation,
if
that
makes
sense.
C
A
Yeah,
I
think,
that's
totally
reasonable
and
yeah.
Basically,
junkies
file
runners
started
like
that.
I
deleted
back
to
java
development
flow
because
I
wanted
to
just
optimize
speed
and
size
of
images,
and
I've
been
quite
successful
with
that,
I
was
able
to
reduce
the
juxtapod
runner
size,
maybe
from
400
megabytes
containers
to
120
megabytes
container
by
now
as
minimum,
but
you're
right
that
now
we
should
circle
back
and
provide
better
experience.
C
A
C
Extensively
at
all
the
documentation
pages
in
that
repo-
I
I
did
take
a
look
at
it.
I
don't
remember
exactly
what
it
says
it
was
a
year
ago,
but
that
kind
of
stuff
tend
to
tends
to
go
over
my
head.
A
A
So
at
some
point
I
was
thinking
whether
I
just
dropped
it
completely
and
built
a
new
tool,
and
I
ended
up
basically,
instead
of
a
two
building
proper
packaging
form
which
you
can
extend
but
yeah.
I
think
that
you
will
still
need
a
separate
cli
because
custom
work.
Packager
is
not
very
good
for
junkies
for
run
resist.
A
It
has
a
lot
of
steps
and
well
that
designed
for
classic
war
files,
so
that
yeah,
it
seems
a
bit
over
complicated
yeah.
For
example.
Here's
example
for
djing's
fall
runner
pekka
junk,
and
it
looks
like
that
right
now,
so
a
lot
of
optimizations
could
be
done.
A
Actually,
more
because
what
it
does
it
bundles
plugins
it
bundles
configurations
called
groovy
hooks.
It
sets
up
system
properties.
A
Everything
is
packaged,
so
yeah,
it's
redistributable
also
it
can
build
components
on
demand
and
it
can
operate
libraries
so,
for
example,
for
junkies
war
file,
it
can
insert
additional
libraries
like
newer
version
of
remote
inc,
or
maybe
just
a
client
library
like
let's
say,
java
agent
and
whatever,
which
is
not
available
by
default.
A
So
it
has
a
lot
of
edit
features
but
you're,
basically
just
taking
everything
and
building
this
single
image.
The
most
important
part
is
actually
here,
it's
also
pre-initialization,
so
you
can
define
it
here
as
well,
either
as
files
or
even
in
the
same
file,
but
in
the
same
file
you
don't
get
a
syntax
validation.
So
in
my
case
I
finally
opted
out
to
having
a
separate,
initialization
and
scripts.
A
Yeah,
so
it
actually
can
produce
docker
file
as
well,
but
it
also
can
produce
jenkins
war
file
why
it
was
done
historically
custom
word
packages
was
created
for
testing
purposes,
so
we
have
frameworks
like
jenkins
test
harness
which
take
work,
war
file
and
test
plugins
against
that,
and
I
wanted
to
test
features
like
pluggable
storage.
A
So,
for
example,
artifact
manager
is
three
plugin
when
I
you
run
a
unit
test,
for
example,
for
jenkins
core
but
add
additional
plugin
and
the
red
configuration
so
that
you
can
test
this
pluggable
storage
behavior
with
the
existing
tests
you
eat.
A
C
A
A
A
A
So
sorry,
if
I
confused
you,
let's
yeah,
I
just
took
a
time
machine.
So
the
version
I
had
here
it
takes
basically
build
settings
and
it
includes
a
palm
from
which
you
get
plugins
and
the
word
file.
A
So
you
can
see
that
the
format
is
not
that
obvious,
because
it
was
well
basically
created
quickly
just
to
get
things
integrated.
C
Yeah,
I
think,
that's
a
that's
a
definitely
a
big
deal
getting
to
depend
upon
health
and
maintaining
your
jenkins.
I
mean
the
jenkins
community.
Image
is
great,
but
yeah.
I
I
feel
like
this
would
be
better
if,
if
you
were
going
to
have
a
complete
pipeline
to
deploy
your
jenkins
and
especially
if
you're,
both
doing
it
for
your
jenkins
production
and
your
jfr,
you
really
get
you
know
the
advantage
using
the
custom
war
packager.
A
Yeah
so
see
edging
seo
runner
build
4,
so
it
produces
war
file
and
it
produces
a
jinx
file
runner
but
yeah.
Currently
it
always
packages
jinx
file,
runner
into
the
docker
image,
though
technically
it's
possible
to
create
a
binary,
didn't
support
it
in
custom
word
packages,
and
maybe
I
will
do
it
later,
but
let's
see
right
now.
I
still
need
to
finish
all
this
packaging
for
newer
versions
of
jenkinsfeld
runners.
A
Well,
currently
so
custom
work
packager,
maybe
makes
sense
to
rewrite
it
completely
because
yeah.
Currently
it's
designed
for
multiple
cases,
maybe
it's
better
to
create
just
separate
genius
file,
runner,
packager
and
simplify
the
logic
and,
if
you're,
not
up
to
that,
just
making
some
incremental
changes
would
be
super
useful.
A
Okay,
so
if
you're
interested
to
take
a
look
at
that,
just
try
yeah,
it
should
be
operational
but
yeah.
Actually,
I
wanted
to
to
work
a
lot
of
the
things
here.
C
Yeah,
I'm
a
bit
green
when
it
comes
to
java
packaging.
I
don't
know
if
I
could
rewrite
this
from
scratch,
but
if.
A
A
Also,
there
are
image,
packs
and
the
image
box.
Well,
I
was
able
to
just
add
one
image
because
then,
due
to
again
non-technical
reasons,
I
was
unable
to
proceed
with
this
repository,
but
if
you're
interested,
you
can
create
more
image
packs
and
they
look
like
that.
So
that
is,
for
example,
they're
just
jenkins
yaml,
which
is
really
simple.
It's
for
configuration
is
code.
There
is
paw
maximal
which
basically
defines
the
build.
You
can
see
that
there
is
a
bunch
of
plugins
and
again
here
many
things
could
be
optimized
and
then
basically,
there
is
docker
file.
A
So
creating
a
few
extra
images
for
other
two
chains
would
be
definitely
cool.
A
A
Image
so
jinx
file
runner
can
run
on
agents,
so
it
can
connect
agents
as
well,
but
the
in
majority
of
these
cases
you
can
also
run
locally,
so
this
image
is
designed
for
local
run.
So
basically
you
run
on
the
controller,
which
is
the
massive
and
the
pattern
for
other
jenkins
use
cases.
But
here
it's
okay,
so
here.
A
A
Makes
sense
yeah
yeah,
so
again
a
lot
needs
to
be
done
so
easily.
I
want
to
have
junkies
yaml
integrated
this
system
definition
into
a
single
file.
A
A
There
is
one
which
was
created
by
evarist
and
francisco
from
claudius
it's
available,
but
it's
based
on
sh
unit
2
and
it's
a
bit
heavy
because
it
it
needs
a
docker,
etc.
C
The
other
kind
of
general
question
I
had
around
the
jenkins
file
runner
is,
I
use
it.
I
tend
to
execute.
I
haven't
run
about
15
to
20
jobs
back
to
back
to
back,
but
even
even
when
I
keep
the
container
running
and
I'm
just
calling
you
know
the
jfr
command
line,
executable
like
the
jenkins
internally
is
restarting
in
between
runs,
and
so
it's
it's
doing
things
like
you
know
the
startup
initialization
and
things
like
that.
Is
there
a
way
to
like
put
put
jfr
in
like
like
a
damien
mode.
A
Yes,
it's
possible,
so
actually
one
pull
request,
which
makes
it
fancy
spending
so
once
so
romance
for
border
risk
from
his
immediate
option
to
keep
zhang's
fellow
running
without
hacks
like
sleep
and
once
it's
already,
you
just
get
things
for
runners
with
web
interface.
Once
you
set
up
a
open
web
ui
and
wait
an
exit
option
also,
you
can
start
up
in
the
cli
mode
and
if
you
start
in
the
cli
mode,
then
you
can
basically
interact
with
instance
like
with
classic
cli.
A
C
Yeah
yeah
yeah
yeah,
so
I'm
going
to
call
it
sequentially.
I
just
don't
want
to
pay
the
startup
tax
like
if
I'm
pulling
down
like
configuring,
the
shared
library
over
and
over
again
every
time.
A
A
A
A
So
if
you're
missing
something
just
submit
a
github
issue
like
you
already
did
and
yeah,
I
promise
that
I
will
process
the
current
backlog
and
yeah.
If
you
just
want
to
adjust
execution.
It's
super
straightforward,
yeah.
There
are
three
levels
of
execution,
but
once
you
get
familiarized
with
the
code
yeah
you
just
get
it
trying.
A
So
actually
yeah.
There
is
a
bunch
of
directories
there,
but
yeah.
There
are
just
three
companies
which
mata
up
bootstrap
and
set
up
for
common
development.
The
rest
are
the
utilities,
developer,
tools
etc
and
later
it
will
be
probably
regrouping
it
into
a
separate
repository,
maybe
even
in
a
separate
github
organization,
but
yeah
likely
just
a
separate
repository.