►
From YouTube: GitLab 13.5 Kickoff - Configure:Configure
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
While
we
are
shipping
in
the
current
release,
the
first
version
of
the
multiple
star
form
multiple
versions
of
triathlon
state.
We
don't
intend
to
ship
support
for
that
in
the
ui,
yet
so
it
will
be
more
minimal
version.
There
second
goal
is
to
provide
listing
and
details
page
views
for
the
gitlab
comments
agent,
as
we
ship
the
agent
this
month
clearly
showing
the
available
clusters
that
are
connected.
Why
an
agent
is
a
must-have
feature.
A
A
A
A
As
already
mentioned,
we
would
like
to
provide
a
listing
of
clusters
that
are
managed
by
an
agent,
so
our
users
can
see
that
these
are
the
clusters
that
the
agent
is
attached
to
and
can
get
some
more
information
around
that
we
have
the
details
pages
there
here,
but
that's
definitely
a
stretch
goal.
So
I'm
not
speaking
about
that
an
issue-
that's
not
related
to
our
gitlab's
agent,
but
is
requested,
but
by
quite
a
few
of
our
customers,
is
to
customize
namespaces
for
gitlab
manage
clusters.
A
Here
in
the
past
month,
we
came
up
with
a
relatively
easy
solution
that
fulfills
most
of
the
use
cases
in
this
area.
It
doesn't
allow
full
customization
of
the
new
spaces,
but
it
allows
selection
of
two
namespace
scheming
setups,
one
that
was
used.
That
was
supported
a
few
milestones
ago.
We
gave
up
many
steps
and
the
current
one
as
well,
and
it's
up
to
the
user
to
choose
which
they
prefer
to
have.
A
A
A
B
So,
from
design
perspective,
we're
gonna
focus
on
three
issues.
Let
me
bring
the
list,
so
the
first
item
will
be
multiple
terraform
state
support.
So
this
issue
is
about
providing
a
user
interface
to
show
a
list
of
state
files
versions
linked
to
git
commit
also
to
provide
a
user
interface.
So
a
json
output
of
the
state
file
and
the
list
of
state
file
views
that
can
be
accessed
by
a
project
maintainer.
B
B
Next
issue
is
document
and
review
infrastructures
code
jobs
to
be
done,
so
we
are
using
jobs
to
be
done
in
gitlab
in
order
to
design
effectively
for
the
user
and
regarding
what
the
goal
the
end
goal
of
the
user
is
so
documenting.
The
jobs
to
be
done
for
each
category
is
very
important
towards
our
product
development
and
design.
If
you
want
to
find
out
more
about
the
jobs
to
be
done,
you
can
do
that
handbook
page
and
finally,
we're
gonna
prepare
for
the
infrastructure
as
code
category
maturity
scorecard.
B
So
the
category
maturity
scorecard.
This
is
the
issue
we're
using
category
maturity
scorecards
in
order
to
determine
whether
a
feature
is
minimal.
Viable
complete
or
lovable,
so
in
this
case
we
want
to
test
for
infrastructure
as
code
with
users
a
job
to
be
done
around
terraform
in
this
case,
which
is
our
implementation
for
infrastructure
as
code,
so
that
we
determine
which
of
these
categories
maturity
levels
it
belongs
to.
B
So
this
is
the
design
work
for
13.5
for
any
feedback.
Please
reach
out
to
me
or
victor.
I
would
love
to
hear
your
thoughts.