►
From YouTube: GitLab Catalog - Roadmap
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
Right,
hi,
everyone.
This
is
Dr
hoskovitz
and
in
this
video
I'm
going
to
explain
what
is
the
roadmap
and
what
is
the
needed
work
for
the
cicd
catalog
in
order
to
move
it
from
experimental
which
it
is
today
and
to
Beta.
A
So
the
roadmap
that
I'm
going
to
describe
is
actually
available
in
the
category
Direction,
underneath
the
one
you
plan
in
this
table,
I'm
not
going
to
cover
all
the
points,
because
it's
an
extensive
list
and
I
want
to
just
explain
what
is
the
work
that
we
need
to
do,
probably
until
the
end
of
the
year
and
first
thing.
First,
what
we've
already
complete,
we've
already
delivered
the
input
interpolation
into
input.
A
Interpolation
is
the
way
to
pass
parameters
to
to
a
component
we've
also
released,
and
the
component
is
experimental
and
number
three
is
something
that
we
just
released.
We
are
about
to
release,
which
is
the
cicd
component
catalog,
just
the
index
page,
which
is
what
I've
explained
in
the
first
recording
that
I've
shared
earlier
today,
and
so
what
is
left
for
us
to
do
in
order
for
us
to
be
able
to
move
the
cicd
component
catalog
from
experimental
that
it
is
today
and
to
Beta
the
first
thing.
A
First,
actually,
I
want
to
start
with
the
with
number
five
and
is
delivered
the
component
catalog
Details
page
today.
What
we've
released
is
just
the
index
page,
which
will
provide
you
with
with
links
to
the
location
of
the
component.
Every
component
that
you
publish
to
the
catalog
will
be
available
in
the
catalog
and
when
you
click
on
it,
you'll
be
able
to
access
that
Repository.
A
The
next
thing
that
we
have
is
the
detail
page
and
the
detail
page
actually
gives
you
more
information
about
a
specific
component
like
once.
You
identify
the
components
that
you
want
to
use.
Okay,
you
solve
the
discoverability
problem
in
the
detail.
Page
you
get
more
information
about.
What
is
component
is
all
about.
What
is
doing
what
are
the
requirement
inputs?
What
are
the
requirement
parameters
if
there
are
outputs,
then
it
will
have
like
outputs
and
more
so.
A
The
next
thing
that
we
want
to
do
is
restructure
and
quality,
restructure
components
and
we're
actually
doing
many
things
here.
There
is
like
a
full-blown
epic,
as
you
can
see
here,
and
save
those
issues
to
complete,
and
basically
this
epic
aim
to
solve
several
things
which
I'm
going
to
explain.
First
of
all,
if
you
remember
when.
A
In
the
first
in
my
first
recording
I
show
you
a
a
project
that
already
consists
out
of
a
component
and,
as
you
can
see,
this
component
has
a
very
unique
folder
structure
and
a
unique
naming
convention.
And
if
we
look
at
component
on
the
actual
content,
there
is
no
real
difference
between
a
component
and
a
template.
A
You
can
actually
say
that
this
component
is
from
the
type
of
template
and
I'm
talking
about
a
CI
CD
template
that
we
all
know
so,
since
there
is
no
will
different
in
the
actual
component
just
for
the
way
to
consume
the
component.
There
is
no
reason
for
a
component
to
look
to
not
look
similar
to
a
template,
so
the
first
thing
that
we
want
to
do
is
to
make
components
very
similar
to
templates.
Why?
A
Because
we
know
that
users
have
dozens,
sometimes
hundreds
of
templates,
and
we
want
to
make
sure
it's
easier
for
them
to
convert
form
a
form,
a
template
to
a
component.
So
let's
try
to
make
them
very
very
similar
to
each
other.
We
know
they
could
not
be
like
one
to
one,
but
still
there
are
many
things
that
we
can
do
to
make
it
very
very
similar
to
com
to
components,
and
this
is
the
first
thing.
A
The
second
problem
that
we
want
to
that
we
want
to
do
is
today.
We
highly
rely
on
the
author
of
a
component
and
to
add
the
details
and
all
the
details
will
exist
in
the
readme
MD,
which
is
great,
but
we
know
that
if
we
are
relying
on
the
customer
on
the
user,
there
is
high
probability
for
either
the
component
not
to
be
up
to
date.
With
the
latest
improvements.
A
Maybe
there
could
be
like
some
some
errors
that
the
users
will
do
so
we
know
that
there
is
a
lot
of
metadata
that
we
can
retrieve
automatically
from
a
component
and
surface
it
in
the
catalog
things
like
inputs,
default,
values,
descriptions
and
more.
Those
are
things
that
we
can
actually
surface
in
the
catalog
automatically,
and
this
is
this
is
one
of
the
things
that
this
epic
aim
to
to
resolve,
basically
eliminating
the
need
for
manual
work
in
order
to
make
sure
that
the
component
is
up
to
date.
A
Still.
There
is
a
problem
here,
because
there
are
cases
where
I
will
have
a
component
in
my
project,
but
I
don't
want
that
component
to
to
be
surface
in
the
in
the
catalog
I
want
to
validate
it.
I
want
to
test
it.
I
want
to
make
sure
it
works
as
expected,
and
only
then
I
want
to
make
sure
it
will
appear
in
the
catalog,
so
other
users
could
use
it,
and
so
this
is
also
some
of
the
one
of
the
Improvement
that
we
want
to
add
to
the
catalog.
A
It
will
not
be
enough
to
switch
the
toggle
to
make
a
project
a
catalog
resource
users
will
need
to
proactively
release
a
component
and
put
the
release
of
a
component.
They
could
also
test
and
validate
the
component
automatically,
and
only
then
the
component
will
be
surfaced
in
the
in
the
catalog.
So
those
are
the
three
things
that
we
want
to
to
add
or
the
Improvement
that
we
want
to
add
to
the
to
the
to
the
catalog,
and
this
is
what
is.
A
This
is
in
in
number
four
number
four,
and
the
last
thing
that
I
want
to
discuss
is
the
input
interpolation
input
is
the
population
is
I
think
this
is
the
foundation
of
a
of
a
component.
It
really
make
the
component
highly
reusable
and
templatize
the
the
component
of
componentized
template
and
by
basically
there
is.
We
still
have
a
lot
of
work
right
now.
The
input
only
only
support
only
supports
string
with
the
inputs,
and
we
have
like
many
improvements
that
went
to
the
to
the
input.
A
We
want
to
allow
user
to
also
pass
an
array
and
also
specify
variables
in
the
input,
and
because
we
do
believe
that
with
inputs,
we
can
eliminate
many
many
of
the
problems
that
we
have
today
with
variables.
Variables
is
the
common
way
for
user
to
pass
parameters
to
a
template.
While
we
believe
that
inputs
should
be
the
going
forward
path
because,
as
I
mentioned,
it
will
eliminate
many
problems
that
we
have
to
do.
A
We
have
today
with
with
variables,
so
we
have
a
full-blown
epic
with
different
improvements
that
we
want
to
add
to
inputs.
Obviously
we
won't
do
it
at
one.
We
will
not
do
it
at
once.
We
will
incrementally
add
more
and
more
capabilities
around
inputs,
yes
and
I
think
this
is
more
or
less
what
I
wanted
to
cover
today
in
what
next
for
the
cicd
catalog.
If
you
have
any
additional
questions
or
some
things
that
are
not
clear,
please
let
us
know
and
hope
you
find
this
useful
and
thank
you
and
bye
bye.