►
From YouTube: UX showcase: Reusable pipeline components
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
A
So
in
a
large
organization,
there's
typically
an
ops
team
that
manages
things
like
pipelines
and
all
of
the
infrastructure
things
and
ensures
that
all
of
the
workflows
that
the
team
has
set
up
are
efficient,
reliable,
standardized,
compliant
and
so
on
and
of
course,
ideally,
ops
teams
want
to
provide
those
resources
once
and
for
developers
to
just
to
be
able
to
find
those
things
on
their
own,
so
they
don't
want
to
have
to
work
together
on
a
case-by-case
basis,
all
of
the
time
because
that's
inefficient.
A
So
some
examples
of
what
this
looks
like
is
a
pipeline
component
catalog.
So
this
can
be
like
reusable
jobs
that
you
share
with
your
team
and
then,
when
developers
are
working
on
their
project,
they
just
take
those
components
and
plug
them
into
their
pipeline,
and
they
have
all
of
the
necessary
build
tests
and
jobs,
build
tests
and
deploy
jobs
ready
to
go.
Another
example
is
a
terraform
module
registry.
A
If,
if
you
want
to
learn
more
in
general
about
this
team
check
out
the
pajamas
for
infrastructure,
video
and
also
we
have
a
new
research
going
on,
that
erica
will
be
leading
around
the
self-service
shared
resource
library,
so
that
this
goes
beyond
ci
pipelines
and
we're
looking
at
the
infrastructure
resources
as
a
whole.
So
when
it
comes
to
ci
pipeline
specifically,
there
are
two
main
problems.
A
One
ops
teams
want
to
enable
their
developers
to
easily
build
consistent,
reliable,
efficient,
compliant
pipelines
and
developers
want
to
easily
build
tests
and
deploy
their
code,
so
they
can
just
get
back
to
coding,
and
our
customers
are
already
solving
this
problem.
Today
we
talked
to
multiple
customers
who
maintain
libraries
of
reusable
pipeline
components,
and
typically
it
looks
like
either
a
project
repository
or
a
group
with
a
bunch
of
different
projects
and
either
you
store
all
of
your
pipeline
components
which
those
are
defined
as
yml
files
in
a
in
one
project.
A
So
you
just
have
a
bunch
of
different
yaml
files
or
you
have
one
project
per
component.
In
that
case,
you
might
have
also
a
readme,
for
example,
that
provides
some
usage
guidelines
for
that
component
and
the
way
you
use
these
components
is
you
just
plug
them
into
your
pipeline?
So
it's
very
similar
to
importing
a
component
when
you're
coding,
just
like
you,
would
import
a
pajamas
component,
for
example,
in
a
file
you
can
import
a
pipeline
component
in
a
very
similar
fashion
and
different
types
of
wikis
and
doc.
A
Sites
are
typically
used
to
provide
usage
guidelines.
So
if
you
want
to
learn
more
about
that,
we
have
existing
research.
This
was
the
first
problem,
validation,
research,
that
we
ran
around
enterprise,
template
management,
ci,
template
management,
and
this
research
is
currently
ongoing
where
we're
talking
to
more
customers
around
how
they're
solving
this
problem
today,
and
if
you
want
to
learn
more
about
how
competitors
are
solving
this
problem,
there's
a
really
good,
competitive
walkthrough
that
you
can
watch
it's
pretty
short
and
yeah.
A
A
Can
I
zoom
in
anyway,
you
would
be
able
to
open
this,
I'm
afraid
that
it's
a
bit
too
small.
Let
me
know
if
you
can
see
anything
here
or
not,
but
we
want
to
have
one
single
place
where,
as
a
developer,
you
would
be
able
to
find
all
of
the
pipeline
components
that
are
available
to
you.
So
here
you
see
that
we
have
gitlab
components,
community
components
and
partner
components.
A
You
would
be
able
to
filter
your
components
list
by
different
categories
and
whatnot,
and
these
are
public
components,
so
community
components
and
partner
components
are
the
ones
that
other
organizations
and
developers
can
contribute
and
github
components
are
some
of
the
components
you're
already
familiar
with,
for
example,
when
you're,
including
a
sas,
can
configuration
into
your
pipeline
you're,
essentially
including
a
pipeline
component,
so
the
it
will
work
basically
in
the
same
way,
and
if
you
have
private
pipeline
components
that
you
have
access
to,
which
are
the
components
provided
by
individual
organizations,
you
would
also
be
able
to
find
them
here.
A
So
the
idea
here
is
that
this
page
would
be
project
agnostic
and
depending
on
based
on
your
permissions
as
a
user.
You
would
see
all
of
the
templates
that
you
have
access
to
in
this
page
and
you
can
check
out
this
epic
for
more
information
about
our
vision.
This
is
just
a
visionary
mock-up
by
the
way,
so
things
will
not
look
this
way.
A
So
a
bit
about
public
versus
private
pipeline
components,
the
user
experience
will
look
exactly
the
same.
The
only
difference
is
that
the
public
components
are
these
components
that
anyone
has
access
to
like
gitlab
components
or
community
components.
Private
components
are
the
components
that
are
created
like
custom
components
that
are
created
by
a
specific
organization,
and
let's
say,
if
gitlab
creates
their
own
custom
components,
they
will
be
visible
and
accessible
only
to
users
who
have
the
permission,
the
necessary
permissions.
A
A
First,
you
need
to
create
a
pipeline
component
project
with
all
of
the
necessary
files.
Then
you
would
need
to
use
the
github
ui
to
tag
the
component
version
and
release
it
to
the
pipeline
component
catalog,
and
at
that
point
the
component
becomes
available
in
the
catalog
and
the
developers
can
start
using
it.
So
I
will
walk
you
through
some
of
the
designs
that
we
have
for
the
mvc
and
we
want
to
rely
on
what
already
exists
in
the
ui.
A
A
So,
since
you
need
a
project
to
create
your
component,
we
want
to
work
with
the
existing
flow
for
project
creation
and
we
want
to
create
a
template
for
creating
a
component.
So
you
would
create
your
project
from
template
from
here.
You
might
find
the
pipeline
component
template
that
already
has
all
of
the
files
set
up
for
you
and
we
will
pull
the
information
from
the
project
name
and
project
description
to
be
used
as
the
component
metadata
to
show
in
the
ui.
A
So
if
you
call
your
project,
docker
image
build
your
component
in
the
catalog
will
be
called
docker
image,
build
the
description
that
you
add
for
this
project.
It
will
be
used
as
the
component
description
and
so
on.
So
we
want
to
avoid
having
to
to
use
a
separate
metadata
file
in
the
future.
A
We
might
have
that,
but
for
now
the
basic
information
we
can
just
pull
from
the
project
itself
and
we
will
be
adding
some
little
tweaks
to
the
ui
like
showing
notifications
to
to
guide
the
user
a
little
bit
through
that
process,
because
of
course
it's
not
tailored
exactly
to
the
job
of
creating
a
pipeline
component.
But
it
allows
us
to
save
a
lot
of
time.
So
there
is
a
bit
of
a
trade-off
there
in
terms
of
the
user
experience.
A
So
once
you
create
your
project,
it
will
already
have
some
the
files
that
you
need.
The
readme
might
contain
either
the
recommended
readme
section
for
the
component
or
it
might
have
the
instructions
for
customizing
your
component
or
perhaps
both,
and
in
order
for
us
to
know
that
this
is
a
component,
you
will
need
to
go
to
the
project
settings
and
say
that
this
project
is
a
pipeline
component.
A
So
if
you,
if
you
use
the
template,
it
will
be
checked
off
by
default
if
you're
creating
a
project
from
scratch
or
if
you're
customizing
an
existing
project,
which
is
a
common
use
case,
because
we
want
our
customers
who
have
the
pipeline
components.
Already
in
projects,
we
want
them
to
use
our
solutions,
so
they
might
have
to
make
some
tweaks
there,
so
they
would
have
to
go
to
their
project
settings
and
turn
on
the
setting
and
from
there.
In
order
for
you
to
publish
the
component
once
all
of
the
files
are
ready.
A
You
already
collaborate
with
your
team
and
all
of
the
scripts
are
good
to
go.
You
would
need
to
create
a
tag
which
marks
the
version
of
the
component
and,
when
you're,
creating
a
tag,
there's
also
an
option
for
you
to
create
a
release
right
away.
So
you
would
just
release
this
component
version
as
a
ccd
component
and
from
there
it
will
appear
in
the
tags
page
and
the
releases
page
as
a
published
pipeline
component.
A
So
we're
relying
entirely
here
on
the
existing
functionality
for
creating
tags
in
the
github,
ui
and
creating
releases,
and
you
should
be
able
to
do
that
using
the
ui
or
you
can
also
do
that
using
the
command
line.
I
think
we
we
also
provide
those
commands
and
documentation.
So
it's
something
that
we
will.
We
will
need
to
document
all
of
the
instructions,
for
this
flow
will
be
in
the
documentation
so
for
the
mvc.
A
The
user
flow
will
look
like
referencing
docs
and
then
going
through
the
necessary
steps
in
the
gitlab
ui
or
using
the
command
line
and
for
the
catalog
itself
for
the
mvc.
We
want
to
keep
it
super
simple.
So
again,
it's
going
to
be
a
private
pipeline
components.
Catalog,
and
if
you
go
to
this
page,
you
will
find
all
the
components
that
were
made
available
to
you
by
the
organizations
where
you
have
the
right
permissions.
A
So
if
you
have
multiple,
if
you
have
access
to
multiple
different
organizations,
you
would
be
able
to
filter
by
the
namespace.
Perhaps
here
we're
still
exploring
the
details,
but
the
idea
here
is
just
to
try
to
reuse
as
much
of
the
existing
ui
that
we
already
have
in
gitlab.
This
is
very
similar
to
the
projects
dashboard
that
we
have
reuses
the
same
layout
for
the
projects
list,
and
the
component
page
will
have
all
of
the
basic
information
about
the
component.
A
You
would
be
able
to
view
it
in
the
repository
as
well
and
will
provide
the
usage
instructions
and
the
readme
readme
will
be
user
defined.
So
when
you're
creating
your
components,
it's
up
to
you
what
you
put
in
that
readme
and
we
will
need
to
just
provide
certain
guidelines
like
best
practices,
for
what
kind
of
information
you
need
to
provide,
for
example,
in
order
to
use
this
component,
it's
not
enough
in
most
cases
to
just
include
it
in
your
pipeline.
A
You
also
have
to
provide
some
inputs,
which
means
adding
variables
the
necessary
variables
to
your
pipeline
in
terms
of
how
users
are
going
to
access
this.
It's
going
to
live
in
the
cicd
navigation,
so
clicking
the
pipeline
component
will
take
you
to
the
catalog
and
in
the
future.
We
also
want
to
make
it
accessible
from
the
pipeline
editor.
A
I
don't
think
I
have
it
here,
but
in
the
pipeline
editor
we
have.
We
currently
have
a
drawer
for
the
help
information
and
we
want
to
also
have
a
drawer
for
the
components
where
you
would
be
able
to
search
for
the
necessary
component
and
plug
it
directly
into
your
pipeline.
A
Yeah,
so
what
are
the
next
steps
right
now
we're
hashing
out
the
details
of
the
mvc
design
proposal
and
in
15.1
we're
planning
to
run
solution,
validation
for
the
pipeline
components,
mvc
it's
going
to
be
interviews
with
both
external
and
internal
users,
and
we
really
want
to
identify
opportunities
for
dog
fooding.
This
solution
inside
gitlab
we've
already
talked
to
some
of
the
teams
that
might
be
interested,
but
we
haven't
really
taken
any
actionable
steps.
A
So
as
we're
refining
our
vision
for
the
mvc,
I
think
we
will
start
to
plan
what
we're
gonna
do
next.
So
there
are
some
options
available
to
us.
We
could
dog
food
it
or
we
could
release
it
as
a
beta
and
have
some
of
the
customers
who
expressed
interest
in
collaborating
with
us,
use
it
first
yeah.
A
So
if
you
are
interested
in
dog
fooding
this
in
github,
please
let
us
know
you
can
ping
either
me
or
dove
my
product
manager,
and
we
would
love
to
talk
to
you
about
this
yeah.
Let
me
know
if
you
have
any
questions.
Thank
you.
B
Well,
thank
you
so
much
nadia.
That
was
super
awesome.
I
know
you
and
I
have
been
talking
about
this
for
a
while,
but
it's
awesome
to
actually
see
some
of
the
designs
coming
together.
So
thank
you.
I
had
the
first
question,
so
we
have
this
ui
showing
all
of
the
components
I
was
thinking.
This
would
also
be
a
good
entry
point
to
create
a
new
component,
but
I
didn't
see
that
on
the
designs.
A
So
the
users
consuming
the
components
in
most
cases
will
not
be
the
same
users
creating
the
components
I
don't
know
if
we
would
want
to
have
a
cta
on
on
the
actual
catalog
page
to
create
a
component.
Maybe
we
could
surface
it
depending
on
your
permissions,
but
either
way
for
the
mvc.
It's
probably
not
going
to
be
necessary
because
creating
component
involves
you
creating
a
project
and
you
know
maybe
there
could
be
a
link
to
the
docs
somewhere.
A
B
Cool.
Thank
you
my
next
question
or
or
comment.
I
totally
appreciate
that
you're
reusing
as
much
of
like
the
existing
flows
as
possible
for
the
mvc.
I
was
just
thinking.
It
could
be
good
to
explain
when
you're,
creating
that
new
project
that
the
metadata
will
actually
become.
The
component
metadata
like,
if
it's
possible,
to
make
that
change
just
to
inform
the
user
that
they
might
want
to
choose
their
name
carefully,
and
things
like
this.
A
C
All
right,
the
next
question
is
mine.
When
I
first
saw
the
components
I
was
curious
about
how
they
would
be
used.
You
know
if
I
got
one
component
from
one
company
and
another
component
from
another.
You
said
something
about
variables
like.
Is
that
how
these
components
will
be
linked
up
like
you
match
up
inputs
and
outputs,
and
you
hope
that
it
works.
D
So
we're
actually
still
figuring
out
the
details
of
the
syntax
for
how
it
works.
There's.
E
I
think
one
of
the
main
things
is
is
that
if
this
is
mostly
stuff
that
can
already
be
done
manually
like
on
your
end,
you
can
create
these
files
and
you
can
get
things
to
jobs
and
things
to
talk
to
each
other
manually.
E
So
it's
more
just
to
put
a
place
for
people
to
find
all
that
information
in
one
place
and
the
variables
will
be
more
to
configure
them
so
that
they
run
the
way
you
want,
but
generally
you're,
not
having
includes
or
components
talk
to
each
other
very
much
if
at
all,
and
if
you
are
doing
something
like
that
now
like
it,
it's
going
to
be
pretty
manual
even
now
like
more
so
than
normal.
So
I
think
it's
generally.
How
do
I
make
this?
One
scanner
do
what
it's
designed
to
do
and
not
really.
E
C
Right
cool,
then
that
makes
my
next
question
kind
of
like
I
don't
I
don't
know
if
it's
applicable,
but
when
I
heard
components
and
like
joining
things,
I
was
like,
oh
with
inputs
and
outputs
you
kind
of
like
in
the
at
the
end.
It's
like
a
pipeline,
so
I
was
like.
Oh
did
these
things
kind
of,
like
lock
up
together,
like
a
like
a
megazord,
is
that
cool?
I'm
gonna
get
this
this
and
then
they're
cool.
This
is
how
it's
going
to
run,
and
I
can
move
blocks
around
like
that.
A
It's
definitely
going
to
be
text
for
the
first
people
future,
so
to
clarify
we're
not
changing
any
functionality
for
the
ml
syntax,
we're
relying
entirely
on
the
existing
includes
syntax.
A
For
this
feature,
the
only
thing
that
we're
doing
is
providing
certain
guidelines
for
how
to
create
your
component
in
a
way
that
we
can
pull
the
information
and
show
it
all
nicely
in
the
ui
for
your
developers
to
use,
but
we're
relying
entirely
on
the
existing
syntax
logic
and
regarding
the
visual
builder,
I
don't
know
if
I'm
lucky,
I
will
live.
A
One
of
the
one
group
one
engineer
groups
working
on
this
janius
is
working
on
a
visual
builder
for
pages
and
that
visual
builder
is
generic
enough
to
work
for
all
kinds
of
pipelines.
So
I
think
we
will
try
to
make
it
part
of
the
workflow.
But
I
it's
not
going
to
be
like
a
drag-and-drop
builder
that
you're
imagining
it's
going
to
be
more
like
a
form
where
you
can
provide
certain
inputs,
which
would
already
be
very
helpful.
So
hopefully
we
can
do
something
like
that.