►
From YouTube: Jenkins UX SIG Meeting 3 March 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
everyone:
this
is
the
jenkins
user
experience
special
interest
group.
Let's
look
at
the
agenda
for
today,
so
proposed
topics
included
a
request
from
chris
kilding
to
talk
about
multi-branch
experiences
since
chris
is
not
here.
I
would
defer
this
until
later.
Unless
someone
else
has
topics
they'd
like
to
cover
on
it
and
then
the
on
the
other
topic
I
had
was
pipeline
visualization
plug-in
demo.
That
was
done
at
contributor
summit
and
talking
further
about
it.
Are
there?
Are
there
other
topics,
you'd
like
to
add
to
this
discussion
today.
A
A
A
I
propose
we
not
go
through
it
again,
just
feel
free
to
click
that
link.
It
will
take
you
right
into
the
video
at
the
exact
time
where
tim's
demo
starts,
you
can
watch
it
and
be
amazed
at
so
what
it
does.
If
I
understand
correctly,
is
it
extracted
a
portion
of
blue
ocean
into
a
separate
plug-in
that
does
not
require
blue
ocean?
Did
I
understand
that
correctly
that
blue
ocean
is
not
required,
and,
and
yet
it's
it
works,
and
it
shows
a
visual.
A
B
B
What
is
what
is
the
prototype,
plugin
hosting
request?
Is
it
something
about
having
the
plugin
published
on
plugins.chankin.org.
A
B
Okay,
I
think
it's
too
er
my
understanding
of
the
felix
and
then
timsha
explanation
are
that
it's
a
bit
early,
it's
a
kind
of
proof
of
concept.
Oh
so.
C
C
See
it
should
be,
I
would
try
to
confirm
this.
B
It's
a
feature
that
was
seen
as
a
age
case
for
many
years
in
jenkins.
The
goal
is,
when
you
define
a
multi
branch
pipeline.
Your
use
case
is
hey
hello
jenkins.
Can
you
watch
this
repository
and
do
your
stuff
meaning
watch
for
branches,
pull
requests
if
you
have
if
it's
recognized
as
a
compliant
implementation
like
github,
for
instance,
and
you
have
to
specify
one
field
or
one
setup
on
configure
code,
which
is
the
location
of
the
jenkins
file
which
describes
the
pipeline
associated
to
that
multi-branch
job.
B
The
main
example
I
have
in
mind
is
one
main
workflow,
so
one
main
pipeline,
which
goal
is,
for
instance,
to
link
the
name
chart
and
to
deploy
it
to
production
and
that
pipeline
might
have
suitabilities
like
okay.
If
it's
a
pull
request,
then
you
don't
deploy
to
production,
you
only
lint
and
you
you
output
d
for
whatever.
So
this
is
what
we
can
do
in
jenkins
and
you
have
a
second
workflow
which
is
hey
every
day
at
one
o'clock
in
the
night
during
the
night.
B
So
technically
it's
not
a
blocker.
However,
in
terms
of
user
experience,
it's
really
hard
because
you
start
to
have
a
jenkins
file,
which
is
already
a
tedious
syntax.
When
you
come
from
yaml
world,
when
you
want
descriptive
and
everything
is
done
to
say,
if
you
want
something
complex,
you
need
to
move
to
scripted
imperative.
B
B
So
here
that's
a
request.
I've
seen
already
but
was
considered
as
an
age
case,
and
I
have
no
idea,
I'm
sure
that
topic
has
been
blocked
most
of
the
time.
This
could
be
really
an
interesting
value.
Why?
Now,
because,
with
the
rise
of
github
actions
and
the
use
case
that
it
started
to
use,
I
tend
to
see
this
use
case
done
by
us
as
a
community
on
our
own
repository
on
github
actions,
which
means
there
is
a
user
needs
that
could
be
addressed.
D
Yeah,
I
personally
would
agree.
I
think
it
would
be
a
great
improvement.
I've
also
used
github
actions
and
having
the
ability,
as
damian
described,
to
have
two
different
files.
Definitely
improves
user
experience,
since
it
clarifies
what
which
what
is
between
which
file
right
what
is
being
done
in
which
file.
So
it
you
know,
defines
two
separate
workflows.
You
can
focus
on
one
or
the
other,
so
yeah,
I
agree,
and
I
think
it's
is
definitely
an
user
experience
thing
right.
So
yeah
100
agree
on
that.
A
And-
and
I
think
I
understand
the
the
concept
you're
you're-
sharing
there,
because
I've
I've
used
exactly
this
technique
in
the
past
to
construct
multiple
in
case.
In
my
case,
I
was
constructing
multiple
multi-branch
jobs.
That
pointed
at
the
same
repository
because
I
wanted
to
test
different
different
branch
provider
implementations.
But
it's
the
same
technique
right
it
is.
It
is
perfectly
valid
to
have
the
problem
is,
then
we
have.
A
B
B
B
A
Okay
yeah,
so
I
was.
I
was
assuming
that
some,
my
simple-minded
user
experience
assumption
was
if
the
path
to
the
jenkins
file
were
declared
as
an
asterisk
inside
a
directory.
Would
that
then,
from
the
user
experience
be
okay?
That's
enough.
It
says
now
create
one
job
for
every
file
in
that
directory
and
but
but
I
don't
know
if
that
makes
any
sense,
because
aren't
there
more
cases
where
they
may
say,
I
need
different
permissions
for
this
or
I
need
different
different
configuration.
I
want
a
different
pipeline
library
loaded
by
implicitly
for
this
thing.
B
B
I'm
not
sure
if
no,
I'm
not
sure,
if
the
view
could
help
on
that,
because
we
already
have
three
tabs
on
the
multiband
job,
you
have
the
the
branches,
the
pull
request,
eventually
the
tags,
if
you
have
set
up
your
job
specifically
with
this
so
having,
I
don't
know
a
tab
that
lists
the
different
pipeline
date.
Exits,
maybe
not
sure,
haven't
talked
that.
Yet
that's
that's
a
good
point.
B
A
Looks
good
okay,
I
propose
we
call
an
end
for
today's
session,
we'll
meet
again
in
two
weeks
right
see.
You
then
see
you
then
bye.