►
From YouTube: GitLab 13 7 Kickoff - Configure:Configure
A
A
A
The
second
goal
is
to
improve
the
management
of
terraform
states,
maria
run
customer
interviews
in
the
past
month,
so
we
got
some
really
useful
feedback
around
that.
This
is
a
feature
set
that
we
were
planning
for
a
long
time
to
provide
management
interfaces
around
the
gitlab
manager
for
states,
and
we
want
to
move
along
this
path
in
the
current
milestone,
and
the
third
goal
is
to
improve
kubernetes
compatibilities.
We
have.
A
But
let's
get
into
details
a
bit
of
more
interesting
things
we
have
in
our
planning
issues,
actually
the
organization
of
the
issue
itself.
We
are
starting
it
with
the
preparation
work.
This
way
even
engineers
and
others
interested
in
what's
coming
next,
can
easily
find
what
is
to
be
expected
and
everybody
is
invited
to
provide
feedback
in
these
issues.
A
Clearly,
there
are
many
more
issues
that
we
are
working
on
continues,
but
these
are
the
biggest
topics,
some
some
of
those
items
that
definitely
need
a
lot
of
feedback
and
discussion
getting
into
the
issues
that
we
want
to
deliver
are
the
following.
First
of
all,
is
the
enabling
reactive
caching
limits
in
deploy
board.
It
seems
to
be
like
a
super
technical
issue
and
in
a
sense,
it
is
it's
a
long,
outstanding
issue
that
we
want
to
ship.
A
Finally,
in
order
that
we
can
close
it
down-
and
this
might
allow
other
groups
as
well
to
enable
these
reactive
caching
limits
in
their
use
cases,
we
were
the
first
who
wanted
to
try
this
out
and
it
seems
to
work
pretty
well.
So
actually,
it
was
already
shipped
the
feature
in
the
13.6
milestone
and
we
are
just
looking
into
some
feedback
from
that
to
ensure
that
everything
works
there
and
after
that
we
are
going
to
remove
the
feature
flag
all
together
and
it's
gonna
be
working.
A
A
With
this
issue,
you
can
set
up
a
structure
like
our
operation
team
has
today
in
data
from
repositories,
for
example,
where
you
have
an
environment
directory
that
contains
your
production
directory
and
the
environments
directly
contains
staging
directory,
etc,
and
these
production
staging
directories
contain
your
manifest
files
that
that
might
have
actually
multiple
manifest
files
that
describe
the
given
environment,
the
green
cluster,
and
this
feature
allows
support
for
these
setups.
That
we
expect
to
be
the
the
really
user
required
setups.
A
Another
feature
that
we
want
to
work
on,
but
probably
we
might
not
be
able
to
finish-
is
support
for
private,
manifest
repositories,
which
is
again
very
important,
especially
on
gitlab.com.
It
will
be
very
important
today.
We
only
support
public
manifest
projects.
It
might
be
great
for
self-hosted
gitlab
instances,
but
definitely
not
for
private
manifest
repositories.
A
A
Currently
we
have
the
state
listing
available
which
provides
information
to
all
the
users
and
might
be
useful,
especially
if
a
state
file
remains
locked
because
we
showed
it's
already
logged
but
doesn't
add
any
value
behind
this
yet
excel
that
you
see
that
you
have
all
those
state
files
in
your
project,
but
you
can't
do
anything
from
it
from
the
ui
you
can.
You
have
to
fall
back
to
graphql
or
some
other
method
to
manage
the
state
files.
A
With
the
introduction
of
these
actions,
the
users
will
be
able
to
download
the
latest
state
file
at
first
lock
or
unlock
a
state
file
if
it's
already
logged
and
to
remove
a
specific
state
file.
If
you
don't
want
to
have
it,
there
want
to
save
some
space,
there
are
credentials
leaked
or
for
whatever
other
reason,
and
the
final
issue
I
want
to
mention
in
this
summary
is
moving
features
to
core
in
the
case
of
deploy
boards.
A
B
A
B
B
So
this
is
scope
for
the
agent
and
then
we
have
a
follow-up
issue
for
the
manifest
projects
which
is
linked
to
the
agent
details
page.
So
we
want
to
show
the
status
of
the
manifest
project
so
whether
they
have
been
synced
whether
there
has
been
an
error
when
the
agent
tried
to
sync
them,
etc.
So
we
want
to
assist
this
link
surfacing
in
the
ui
this
link
between
manifest
agent
and
also
the
status.
B
This
could
be
on
the
agent
side,
but
it
could
also
be
on
the
manifest
project
side.
So
this
is
to
be
discovered
by
the
design,
explorations
and
finally,
going
back
to
terraform
from,
for
the
first
part,
part
of
the
state
file
design
work.
We
introduced
the
listing
and
the
versions
for
each
terraform
state.