►
Description
Tekton Client Plugin has been a great start for Jenkins and Tekton integration. But Tekton is just a Pipeline step at the moment. What if we make the Jenkins Pipeline orchestrator part (Multibranch, Jenkins UI/reporting, ) universal and allow plugging in multiple Pipeline engines, including [Jenkins Pipeline with and without Sandbox, Tekton, Jenkinsfile Runner, and more]?
Meeting notes: https://docs.google.com/document/d/1QLWXNG23ui-LvQXth3UREzOvLYgTMSZcv-El0H141a4/edit#heading=h.rbvy02o8js5h
A
No
because
I
should
have
clicked
there,
okay
and
now:
yes,
yes,
okay,
so
what
do
we
have
so
something
like
one
year
ago,
a
bit
more
with
bavar
from
red
hat?
He
started
integrating
tech
one
with
jenkins.
There
is
client,
it
was
also
a
part
of
work
for
openshift
magenti's
pipeline,
so
there
so
what
you
can
client
plugin
does
well.
It's
basically
provides
some
interface
for
communicating
with
the
pipelines,
so
you
can
create
resources,
trigger
bills
and
retrieve
some
results,
but
basically
that's
it
and
how
it's
implemented.
A
A
A
Jenkins
itself,
it
consists
of
multiple
components,
so
we
have
this
web
ui.
We
also
have
what
I
call
orchestrator
part.
So
basically,
here,
for
example,
there
is
a
webhook
receiver,
which
triggers
builds
and
propagates
results
back
to
the
acm,
so
all
of
that
is
handled
by
jenkins.
All
of
that
can
be
handled
by
pro,
for
example,
in
the
nether
circus
system,
but
yeah.
This
way
zinc
is
quite
strong,
especially
thanks
to
all
its
reporting
compatibility
compatibilities,
but
there
is
also
pipeline
engine.
A
B
We
do
have
a
dashboard,
it's
part
of
tecton,
but
it's
it's
it's
kind
of
like
the
kubernetes
dashboard,
so
it
allows
you
to
see
resources.
It's
not
specifically.
I
think
the
jenkins
ui
is
more
targeted
towards
maybe
cicd
scenarios.
Where
you
see
the
pipelines
and
you
have
you,
you
can
see
the
history
of
execution
as
well,
while
the
execution
history
protection
relies
on
what
is
in
the
cluster.
Basically
right.
B
Will
evolve
the
time,
but
the
the
fact
is
that
a
lot
of
people
as
well
as
is
used
and
enjoys
the
the
jenkins
ui,
and
I
think
for
for
people
used
to
work
with
with
the
jenkins
ui.
It
would
be
beneficial
to
be
able
to
to
continue
using
that
ui,
but
rely
on
some
of
the
benefits
of
having
tecton
running
underneath.
A
All
right-
and
there
are
multiple
ways
to
make
it
compatible,
so
we
have
already
have
many
beats.
So,
for
example,
we
have
this
tecton
client.
We
basically
is
based
on
a
java
library
which
provides
the
optical
interactions.
It's
still
missing
a
few
critical
bits,
for
example,
visualization
execution.
A
A
So
one
of
our
issues
with
sticktone
technolon
has
a
huge
ecosystem
of
various
tasks
that
are
reusable
on
its
own.
But
of
course
it
doesn't
have
a
report
publishing,
but
what
we
could
do.
We
could
take
jenkinsfeld
runner
and
run
it
as
a
publishing
step
which
streams
the
data
back
to
jenkins,
so
basically
how
it
would
look
like
that
yeah.
We
have
jenkins
as
a
big
orchestrator.
A
A
And
it
could
stream
the
data
back
to
jenkins,
so
what
it
means
that
we
would
keep
all
this
orchestrator
part.
For
example,
jfr
could
provide
reporting
capability
and
tickton
execution
could
stream
all
the
build
results
and
metadata
again
to
jenkins.
So
we
could
even
rebuild
the
pipeline
graph
so
that
we
could
display
pipeline
execution
graph,
even
if
it
gets
produced
by
tecton,
with
all
parallel
steps,
et
cetera,
it's
already
supported
api.
A
B
B
Would
be
interesting
to
to
find
to
maybe
highlight
some
use
cases
for
these
or
like
what
would
be
the
benefit?
What
would
people
looking
for
when
using
this
kind
of
combination?
Right?
It's
not
entirely
clear
to
me
whether,
in
this
setup,
people
would
be
writing
pipelines
using
the
jenkins
pipeline
format
or
detect
on.
A
A
So
if
you
take
the
jenkins
controller
on
its
own,
it's
not
cloud
native.
It's
not
scalable
enough.
When
it
comes
to
big
pipelines,
you
can
create
multiple
controllers.
You
can
create
clusters
of
junkies
with
integration
ion
message,
bus,
but
still
it
has
a
lot
of
limitations,
but
if
we
have
loaded
execution
to
tipton,
so
firstly,
we
would
get
benefits
of
with
all
its
scalability
features
available.
A
This
opportunity
to
just
spawn
as
many
tecton
pipelines
as
needed
on
different
kubernetes
clusters
again,
if
needed,
and
the
jenkins
itself
could
stay
as
to
some
extent
aside
and
just
provide
publishing
front
end
and
again.
Jinx
itself
can
be
eventually
converted
in
this
way,
so
that,
let's
say
there
are
multiple
web
ui
providers
connected
in
the
cluster
somehow,
and
we
have
prototypes
for
that,
for
example,
project
nirvana.
I
was
working
on
but
yeah
for
that.
B
Right
yeah
and,
as
you
mentioned,
like
high
availability,
I
think
scalability
and
support.
I
think
one
of
the
main
points
for
jenkins
in
enterprise
that
I've
heard
at
least
is
high
availability.
So,
if
you
like
want
to
reconfigure
your
jenkins,
you
need
to
reload
it
and
you
have
a
downtime
a
few
minutes.
B
So
I
think
in
this
approach
you
would
not
have
the
downtime
for
running
the
pipelines,
but
what
happens
in
so
if
you
restart
jenkins,
is,
is,
is
that
what's
that?
Would
this
so?
Would
that
still
be
a
single
point
of
failure
in
terms
of
I
guess
it
depends
how
how
the
pipelines
are
triggered
and
that's
what
I
wanted
to
envision.
B
A
It's
actually,
but
classic
architecture
is
just
one
of
configurations
for
jenkins
and
actually
what
blocks
us
right
now
is
the
fact
that
we
have
a
lot
of
context
in
runtime,
so
some
data
can
be
uploaded
to
pluggable
storage.
There
are
implementations
the
roles,
event
systems
so,
for
example,
for
blue
ocean
web
ui
for
various
logging
systems.
We
can
stream
events
across
multiple
instances.
A
A
There
is,
of
course,
many
edge
cases
where
it
wouldn't
be
possible,
because
jenkins
is
also
a
webhook
receiver,
which
is
a
single
pointer
failure.
Whatever
you
do,
but
once
a
pipeline
execution
happens
separately,
we
can
actually
do
a
lot
of
exchanges
to
the
controller
itself,
so
basically
converting
jenkins
controller
to
controller
plane
and
also
have
a
kind
of
web
ui
which
again
can
be
scalable,
and
basically
it
can
be
a
fully
client-side
api
event
as
well,
if
needed
so
even
bloation.
A
A
Yes,
it
would
require
a
lot
of
changes
in
jenkins,
but
if
you
experiment
with
stepton
it
would
be
one
of
possibilities.
It
can
be
done
with
james
pipeline
as
well
without
action.
So,
for
example,
jinx
file
runner
is
basically
the
same
offloading
pipeline
engine
to
a
separate
instance
like
container
streaming
results
back,
but
tekshon
has
its
own
advantages,
because
you
hope
that
techtron
will
become
a
commodity
at
some
point.
So
why
don't
we
integrate
the
agencies
with
tecton
as
well.
B
A
Yeah,
so
we
will
talk
about
real
high
availability.
Of
course
we
will
need
to
externalize
the
context
and
well
it
has
been
a
common
understanding
conjunctions
for
more
than
five
years.
If
you
want
to
change
the
section,
if
you
want
to
get
rid
of
controller,
as
instance,
we
will
need
to
significantly
rework
but
yeah.
Currently
pipeline
is
one
of
the
impediments,
because
well
you
either
have
multiple
controllers
in
some
way
or
you
create
completely
different
architecture.
A
In
other
projects,
so
yeah
there
are
many
ticked
on
users
by
now.
So
for
me,
it
would
be
natural
that
if
we
at
least
tried
using
this
engine
and
provide
the
possibility
for
end
users
to
choose
whether
they
use
jinx,
pipeline
or
tickton,
because
current
state
for
junkies
pipeline
is
yeah,
it's
a
kind
of
liability
for
us.
A
A
Think
and
but
you
can
use
jenkins
python,
but
what
the
engine
is
under.
The
hood
is
a
separate
topic
because
I
think
spy
plan
again.
They
first
expect
the
user
experience
and
yes,
of
course,
groovy.
They
say
they're
perfect,
but
many
of
these
speeds
can
be
mapped
to
dictionary
execution.
So
there
was
already
a
prototype.
Haseo
was
presenting
to
the
devops
world
that,
basically
your
thought
pipeline
execution
to
jenkins
fat
runner
and
then
return
the
results
back,
jinx
felt
runner
can
run
and
dicktone,
for
example,
sap.
C
A
In
five
to
ten
years,
you
will
still
have
jenkins
pipeline
but
yeah.
For
me,
it's
not
like
saying
that
tikton
will
be
the
only
solution
in
january.
For
me,
it's
rather
making
it
as
an
alternative
for
those
who
want
to
get
just
takes
on
execution,
but
get
benefits
of
changes
like
publishing.
So
where
jenkins
is
really
strong.
A
A
So
for
that
yeah
I
wanted
to
really
talk
to
tom
coming
to
see
what
would
be
missing
and
what
would
be
just
cases
on
your
side,
because
for
us
one
of
the
questions
is
don't
like
jenkins,
a
tickton
but
other
ecosystem
parts
which
could
be
reused
so,
for
example,
lock
streaming,
because
if
tikton
community
plans
to
adopt
a
standard
lock
streaming
solution,
for
example,
open
telemetry
who
knows
in
the
future
and
first
it
would
be
also
an
opportunity
to
hook
on
that.
Instead
of
inventing
something
on
our
own.
B
B
A
A
So
what
we
did,
the
remoting
itself,
it's
quite
stable
solution,
but,
for
example,
when
we
are
talking
about
clustering
jenkins,
the
option
we
discussed
is
actually
using
message,
bus
and
during
google
summer
of
code
in
2017,
we
created
the
implementation
for
apache
kafka,
so
basically
what
it
means
there
can
be
multiple
controllers
and
multiple
agents
and
the
agents
could
stream.
The
data
to
controllers
and
controllers
can
generate
them
just
by
subscribing
to
events,
and
it's
also
one
step
towards
high
availability,
because
remoting
itself
is
point
to
point
communication.
A
So
in
remoting
there
is
no
any
kind
of
broadcast
company
capabilities,
but
when
we
switched
to
apache
kafka,
we
in
that
particular
plugin.
We
were
actually
able
to
avoid
that
and,
for
example,
that's
why
I
mentioned
open
telemetry,
because
if
tickton
streams
that
they
looks
to
open
telemetry
logs,
then
obviously
it
can
be
used
by
any
visualization
tool
in
kubernetes
but
jenkins
on
the
same
part,
with
just
subscribe
to
this
information
and
do
visualization
on
the
inside.
A
B
I'm
just
wondering
if
that's
something
that
needs
to
be
techno
specific
or
if
there
might
be
something
already
out
there
for
this,
because
at
the
end,
in
terms
of
like
pipeline
execution
logs,
it's
all
running
in
parts.
So
basically
it's
a
logs
subresource
in
kubernetes.
So
you
can
already
get
those
from
the
api
and
that's
what
we
we
do
like
in
detecting
cli.
B
You
can
stream
the
logs
by
using
dkn,
which
is
detect
on
cli,
which
basically
connects
to
the
api
using
the
watch
option,
and
then
you
get
the
logs
there
and
I
think
that's
the
same,
that
the
dashboard
does
and
then
it
uses
websocket
to
display
those.
So
I
wonder
if
there
is
anything
that
would
generate
a
kafka
events,
type
of
stream
already
from
from
pod
logs
kubernetes
but
logs.
B
A
So
for
us,
apache
kafka
was
just
an
experimental
implementation,
so
yeah,
I
keep
him
in
co-op
and
telemetry
just
because
we
started
a
lot
of
activities.
Consolidating
combat,
but
yeah
following
part
is
in
the
very
beginning.
So
let's
see
how
it
goes
for
us.
When
we
talk
about
pipeline
information,
we
actually
need
some
additional
metadata
because
we
need
to
build
a
pipeline
drive
so
so
that
we
can
visualize
steps,
and
the
question
is
about
metadata.
That
would
be
submitted.
So
pretty
much
like
cd
events
project
does
for
various
events.
A
B
B
B
Yeah,
so
if
you
have
the,
as
I
said,
I
think
if
you
have
the,
if
you
know
about
the
the
pipeline
structure
and
junk
inside,
you
don't
need
to
go
and
retrieve,
and
you
can
get
right
time
information
either.
You
could
get
it
from
events
in
cloud
events
contact
them
or
you
could
have
like
you
said
in
the
beginning,
you
could
have
this
jenkins
run
jenkins
file,
runner
type
of
execution
in
detecting
steps
that
report
back
into
the
jenkins
store
directly.
I
think
so.
A
For
all
complex
data,
I
would
expect
it
to
be
keys
because
well,
it's
very
tempting
to
have
a
kind
of
unified
record
reporting
for
common
operations,
so,
for
example,
publishing
unit
test
results.
I
guess
for
tectonic
would
be
use
case
without
jenkins
2
to
be
able
to
visualize
it
somehow
and
maybe
transfer
this
bit
in
a
standard
form,
but
it
goes
way
beyond
just
jenkins,
so
just
tone.
A
It's
super
complex
area,
but
for
jenkins,
specifically,
we
could
take
jenkinsfeld
runner
because,
for
example,
in
jenkins
there
is
g
unit
plugin,
but
the
unique
plugin
doesn't
do
the
unit
test,
genuine
plugin,
just
processes,
the
report
and
just
publishes
the
results.
So
we
could
basically
have
firstly
right
one
task
which
does
all
the
build
and
tests
we
use,
maybe
and
this
whatever
and
then
just
another
task
which
connects
to
the
same
workspace
and
publishes
the
report
and
well
basically,
that's
it
wouldn't
be
a
huge
performance
ever
have
so
yeah.
A
C
B
A
So
basically
jenkins
would
be
the
same,
at
least
in
the
beginning.
So
there
is
no
need
in
various
magic
mechanisms
to
determine
how
and
where
to
publish
but
yeah.
Then
we
still
have
a
question
like
how
we
transparently
pass
information
about
connecting
back
to
jenkins,
because
you
could,
for
example,
just
create
api
token
for
the
build
put
it
somewhere
on
kubernetes
secret,
but
it
doesn't
seem
to
be
the
best
solution.
B
B
B
C
B
B
A
A
So
I'm
not
sure
whether
I
guess
for
text
on
it's
not
a
big
concern
by
default,
because
if
you
use
tickton
it
means
that
yeah.
This
relational
is
on
the
cluster
level,
but
yeah
for
jenkins.
Historically,
it
hasn't
been
a
case,
or
maybe
it's
something
we
need
to
rethink
on
the
junk
inside,
but
yeah
right
now.
If
I
offered
whatever
jenkins
user
to
basically
give
up
on
the
security
mechanisms,
it
might
be
a
kind
of
uphill
battle
for
us
yeah.
A
B
A
B
Yeah,
no,
the
the
controller
itself
runs
in
in
one
name
space,
but
the
execution
happens
in
whatever
name
space
that
you
you
decide.
Usually
you
you
will
have
one
or
more
other
namespaces
where
the
execution
of
your
runs
it
happens
and
you
can
control
which
service
accounts
are
used,
so
you
can
have
even
within
the
same
space.
Different
service
accounts.
A
A
A
A
B
A
A
A
B
A
A
A
Okay,
so
we
have
been
with
quite
a
lot
in
this
engine
because
it's
advantage
and
disadvantage
of
jenkins
that
execute
execution
happens
on
the
controller
and
yeah.
It
saves
a
lot
of
time,
but
at
the
same
time,
it's
a
massive
security
concern.
If
you
consider
jenkins
control,
which
has
a
shared
service
and
the
whole
drink
is
controlled,
it
is
a
shared
service
by
default.
A
A
A
B
So
we
have
a
tecton
cluster,
which
is
multi-tenant
with
all
the
nice
features
and
compliance
built
in
so
it
would
make
sense
for
us
to,
you
know,
have
a
because
we
have
a
techno
infrastructure
which
is
quite
proven
and
stable
and
meets
all
the
requirements
to
use
that
as
a
runtime
environment
for
the
services
on
top,
which
we
do
for
other
things.
But
yeah.
A
A
B
I
know,
but
I
I
know
where
that
is
interested
as
well,
and
this
is
kind
of
work
I
mean
for
for
ibm
specifically.
I
know
we
have
a
lot
of
customers
that
are
used
to
jenkins
in
terms
of
ui,
but
also
the
jenkins
syntax
for
riding
pipelines,
and
so
what
would
be
interesting
for
sure
would
be
to
have
a
setup
where
you
can
still
write
your
pipelines
in
the
jenkins
format,
not
execute
them
on
tickton,
but
execute
them
yeah,
and
it
doesn't
have
to
be
necessarily.
B
A
A
So
if
you
want
something
real,
we
would
need
to
somehow
convert
this
pipeline
definition
to
multiple
tickton
tasks
and
while
it's
possible
it
might
additional
issues.
So
declarative
syntax
would
be
easier
for
that,
but
yeah.
I
guess
many
people
on
this
call,
don't
really
use
declarative
because
declarative
results,
a
kind
of
simplification
for
junk's
pipeline,
it's
basically
syntax
sugar,
which
creates
all
these
stages
tied
to
a
single
engine
and
drags
more
more
flexible.
A
So
when
you
develop
by
client
libraries,
essentially
you
usually
opt
out
to
script
pipeline
and
okay,
yeah
and
the
yeah.
Then
it
becomes
complicated
so
actually
for
declaration
of
pipeline.
There
was
already
converted
and
jenkins
said
so:
the
declaration
of
five
interject
sex
pipelines
and
while
we
put
them
well
nzx
pipelines,
we
are
basically
on
the
top
of
techcon
2..
A
B
C
B
A
project
that
was
driven
mostly
play
by
ibm
and
basically
in
kubeflow,
is
a
is
an
engine
for
the
machine,
learning
data
type
of
pipelines
and
it
provides
a
python
dsl
and
what
we
we
have,
that
that
python
dsl
can
compile
into
argo
cd
pipeline
or
you
can
compile
now
as
well
and
detect
pipelines.
So
there
isn't.
B
C
B
Your
python,
via
the
dashboard
technical
dashboard,
if
you
want
to
but
then
yeah,
you
can
basically
continue
to
write
pipeline
in
the
same
format
as
you
would
tube
flow
pipelines,
and
then
you
can
visualize
them
also
in
the
cube
for
ui,
because
they
are
written
in
the
geoflow
psl.
So
it's
all
nothing
to
kill,
and
I
was
wondering
whether
a
similar
approach
could
work
for
for
pipeline
as
well.
B
C
B
A
There
will
be
a
lot
of
restriction,
but
technically
could
be
done
so
for
us
yeah.
The
main
problem
would
be
to
map
two
tasks,
because
we
definitely
want
to
have
multiple
tickton
tasks
so
that
we
have
execution
in
different
containers
while
passing
the
workspace
and
not
all
jinx
pipelines
are
implemented.
In
this
way,
though,
it's
possible.
A
A
A
B
A
And
what
it
means
that
here
you
have
execution.
So
if
you
want
to
have
a
stage
in
the
jenkins,
it's
something
like
that
and
that's
it.
So,
basically,
you
have
a
stage
and
there,
for
example.
If
you
need
a
note,
you
say
note
note,
for
example,
linux
and
you
do
something
there
and
it's
more
less
common.
At
the
same
time,
you
don't
have
to
do
that.
You
can
avoid
using
stages
at
all.
A
You
can
somehow
switch
between
note
implicitly
so,
for
example,
there
might
be
pipeline
library
steps
something
like
on
linux,
node
and
then
this
code
is
some
way
deep
inside,
because
in
jenkins
we
have
a
lot
of
extensions,
so
just
by
groovy
closures.
So
it
would
be
like
that
and
it
can
be
even
more
chord
because,
for
example,
in
jenkins
from
one
note
you
can
call
another
note
and
yeah
you
would
need
to
unravel
many
of
these
edge
cases.
If
you
wanted
to
just
process
the
execution
correctly
again
how
popular
it
is
yeah.
A
So,
for
example,
in
jenkins
itself,
we
have
pipeline
library,
and
I
believe
that
all
pipelines
we
have
here
would
be
easily
convertible
to
tecton,
because
here,
for
example,
there
is
a
lot
of
scripting
there.
But
ultimately
we
end
up
with
parallel
tasks
which
in
execute
on
node
and
pass
through
just
several
common
stages
like
doing
command,
doing
more
maven
and
then
just
publishing
the
results
and
archiving.
A
So
these
constructs
could
be
easily
converted
to
tickton.
The
problem
is
how
to
do
it
automatically,
because
here
you
can
see
that
the
pattern
is
probably
inverted
compared
to
tecton,
because
we
just
allocated
the
node
and
then
within
the
node.
We
do
multiple
steps
electron.
We
rather
expect
that
every
step
will
be
performed
in
a
separate
container,
so,
firstly,
we
would
execute
maven.
A
B
B
B
C
B
C
B
A
Which
is
definitely
an
advantage
but
yeah
if
we
create
compiler,
two
tectonic
pipelines,
many
use
case
could
be
determined
and,
of
course,
if
you
use
kubernetes
plug-in
if
you
use
docker
pipeline
plug-in
and
others
they're
more
naturally
convertible
to
tickton,
because
they
have
more
of
a
clear
separation
between
stages,
so
you
can
in
kubernetes
plugin.
You
can
also
create
just
a
port
with
multiple
regions
for
different
stairs
and
multiple.
A
A
B
B
A
C
B
A
Maybe
I
should
talk
to
ander
buyer
a
to
see
whether
he
would
be
interested
at
least
to
do
some
to
see
whether
we
could
apply
what
we
did
for
jenkins
x
to
such
conversion
and
yeah.
If
it's
doable.
Why
not?
So
there
are
questions
about
the
recording.
I
will
upload
it
to
jenkins
youtube
by
the
end
of
the
weekend,
so
yeah
there
will
be
some
notes
and
yeah.
We
will
we
don't.
B
A
A
So
it's
usually
plugins
that
do
that,
but
what
we
would
need
is
to
have
a
kind
of
api
in
the
build
when
you
call
jenkins
and
say
that
yeah
for
this
particular
build
which
is
pending.
I
would
want
to
upload
this
report
and
please
attach
it
to
the
built
data
it's
doable,
but
yeah.
We
don't
have
this
apis
at
the
moment.
For
many
cases.
A
B
A
Yeah,
so
it's
available
everywhere.
At
the
same
time,
yeah
architecture
of
jenkins
is
a
bit
complicated
because
historically
many
such
interfaces
are
not
even
a
part
of
the
jenkins
core.
So,
for
example,
unit
test
reporting
is
a
part
of
the
g-unit
plug-in
due
to
historical
reasons
and
yeah.
There
are
some
exceptions,
so,
for
example,
robot
framework
plug-in
for
python
doesn't
really
integrate
with
this
g
unit
at
the
beginning.
Instead
of
that
in
the
remaining
bits
on
its
own,
but
apart
from
this
atrocities,
it
should
be
more
or
less
straightforward
for
jenkins.
A
B
A
A
B
A
B
So
and
then
again
I
mean
if
we,
if
you
were
using
tecton
format
in
jenkins.
I
think
that
the
pipeline
structure
is
then
provided
by
the
definition
right.
So
we
only
need
to
provide
the
runtime,
and
if
we
use
the
jenkins
format
translated
again,
we
would
have
a
static
definition
already
in
the
pipeline.
So
it's.
B
B
C
B
A
Now,
well
in
jenkins,
we
largely
moved
to
github
issues.
So
in
this
particular
question
in
this
particular
topic,
the
question
is
where
to
put
it,
because
we
have
so
many
components,
so
we
can
probably
so
organizational
advice.
I
would
rather
keep
it
on
the
terminal
of
cloud
native
seek
or
maybe
under
the
umbrella
of
cdf
interoperability
seek
whatever
is
more
convenient
and
yep
for
task
tracker
yeah.
You
could
just
create
a
new
repository
for
that.
A
A
A
A
A
Yeah,
maybe
jenkins
ex
team
would
be
interested
as
well,
but
the
agency
yeah
they
need
to
regroup
yeah.
If
they
have
some
interest
because
they
look,
they
contribute
a
lot
to
the
client
plugin
plugin,
so
they
could
be
well.
They
need
for
integration
as
well.
So
maybe
they
would
also
be
interested
to
see
the
way
it
evolves.
A
A
A
A
C
C
I
personally
don't
run
a
lot
on
jenkins
right
now,
but
it
really
just
depends
because
I
do
a
lot
of
consulting.
So
I
go
from
client
to
client
and
you
know
you
never
know
what
they're
going
to
be
running.
So
it's
been
a
long
time
since
I've
looked
at
kubernetes
offerings
but
yeah.
I
think
I'd
have
to
go
and
look
at
the
like
the
benefits
of,
and
then
you
know
where
does
that
fit
for
you?
C
You
know,
as
you're,
evaluating
your
options
and
just
having
the
option
to
have
other
pipeline
engines
is
definitely
something
that
is
interesting
and
probably
good
for
the
community,
but,
like
you
said
there
will
definitely
be
edge
cases.
So
you'll
probably
pick
up
some
benefits
from
using
them
as
an
engine,
and
then
you
know
it's
like
well
what
what
do
I
lose
when
I
decide
to
translate
my
existing
jenkins
file
into
one
that
can.
C
Yeah-
and
I
think
you
guys
mentioned
something
about
tech,
talent
is
usually
something
done
in
concurrently
versus
sequential
and
that's
probably
definitely
some
place
that
deep
ins
could
use
some
help
they
have.
You
know
we
have
parallel
stages
to
run
things
concurrently,
but
kind
of
the
ability
to
like
display.
That
is
very
hard.
This
means
like
with
current
pipelines
right
a
lot
of
the
output,
will
be
mashed
together.
So
it's
very
hard
to
follow.
A
A
So
this
is
something
we
can
look
into.
Yeah
currently
pipeline,
visualization
and
jenkins
is
also
a
hard
topic,
so
team
giacomp
is
working
on
the
new
plugin
for
browsing
pipelines,
but
yeah,
currently,
I'm
not
so
sure
about
the
future
of
blue
ocean
or
pipeline
stage
viewer.
So
maybe
it's
topic
that
needs
to
be
brought
up
to
the
authors.
C
Improve
it
and
then
just
pipeline
thoughts
in
general,
regardless
of
the
executor
to
me,
I
feel
like
there
was
for
a
year
or
two
or
three.
There
was
that
kind
of
push
towards
yml
like
when
travis
got
popular
and
then
you
know
get
lab
and
then
github
actions,
but
I
think
we're
going
to
see
that
reverse
I
mean
you're,
seeing
it
in
javascript
and
python,
where
typing
and
things
like
that
are
becoming
extremely
popular
very
quickly.
C
I
think
you're
going
to
see
more
developers
wanting
to
build
their
ci
cd
pipelines
in
a
in
some
kind
of
feature-rich
programming
language
and
not
not
in
batch
or
some
type
of
job
dsl
type
type
language.
Maybe
like
descriptive
pipeline
you're
going
to
see
people
want
to
push
towards,
I
think
more,
like
full
featured
programming,
languages.
A
B
B
B
Yeah,
so
I
think
it's
it's
interesting
to
to
have
a
lot
of
power
and
information
in
your
pipeline
and
metadata
structure
and
support,
but
then
it
becomes
really
like
a
development
job
writing
the
pipeline.
So,
like
writing,
a
text
on
task
but
well
written
with
all
the
input
parameters
and
the
results
and
the
things
done
properly
because
a
development
job
yeah.
So
it's
that's
why
the
catalog
and
the
usability
story.
C
B
B
The
construct
that
you
want,
but
you
you
still
want
the
other
spectrum
where
you
want
people
just
to
even
maybe
say
graphically.
You
have
a
ui
where
the
drop,
the
boxes
and
say:
okay,
this
is
my
pipeline
and
it
connects
things
together
and
it's
very
easy
to
do
so.
I
think
it's
there.
Both
words
exist.
A
B
Has
imperative
in
a
way
of
course,
you
have
some
script,
does
something,
but
it's
declarative
in
the
way
that
you
say
what
what
are
your
inputs?
What
are
your
outputs?
You
know
and
yeah.
That's
one
thing
that
we
are
hitting
in
a
few
places.
Now
a
few
use
cases
I've
seen
that
it's
with
the
limitation
is
get
this
concept
of
pipeline
resources
in
the
beginning
they
could
be
used
as
inputs
and
outputs,
and
you
could
say
this
input
is
a
git
repository.
It
is
output
with
a
container
image
and
so
forth.
C
C
A
D
I
think
this
is
still
in
very
early
stage
and
going
forward.
Maybe
we
are
going
to
design
a
single
interface
web
interface
for
this
for
their
integration.
Yes,
this
sounds
like
the
cubesat
devops
with
jenkins
yeah.
You
know
we
have
a
individual
web
interface
for
jenkins
pipeline
so
which
is
similar
to
the
blue
ocean.
A
A
Yeah
well
eventually,
you
may
need
some
specifics
of
pluggability
but
yeah
having
such
foundation,
I
think,
would
be
nice
for
any
extensible
system
and
yeah.
I
guess
you're
doing
more
or
less
the
same
as
we
discussed
before,
for
example,
for
jenkins
x,
when
genghis
x
was
deciding
what
the
built
engine
to
use,
they
basically
put
multiple
ones
and
on
the
jenkins
side,
we
actually
want
even
drinkers
to
support
multiple
engines.
A
A
A
Probably
not,
then
thanks
everyone,
so
in
20
minutes
we'll
have
a
session
with
levy
about
visual
studio
code
and
development
tools
and
as
we
agreed,
we
postponed
james
valrano's
session
by
one
hour,
so
at
1
pm
utc
we
will
have
the
jinx
file
running
session
and
yeah.
Then
we
will
basically
close
and
yeah
I'll,
take
action
item
to
just
process
all
nodes.
A
Well,
it's
just
a
very
small
summit
this
time.
Well,
we
could
have
prepared
and
announced
it
a
bit
earlier.
So
in
summer
we
had
50
people
participating
and
yeah.
I
think
we
can
return
back
to
the
scale
for
the
next
summit,
but
yeah
for
this
particular
one.
I
just
wanted
to
have
several
focused
discussions,
so
hopefully
we
achieve
these
goals
and
yeah
thanks
a
lot
to
andrea
for
joining
us
thanks.
I
don't
know
honestly
so
yeah.