►
Description
A walkthrough with https://gitlab.com/cwoolley-gitlab of the architectural spike of the Remote Development feature showing how you can provide a Devfile to a workspace via an associated Project repository. See the Merge Request https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110601 and associated Merge Requests for more details.
A
You
can
see
here
there's
a
new
radio
which
is
Dev
file
Source.
You
could
either
enter
a
Dev
file
as
a
text
field
like
you
could
before,
or
you
can
pick
to
select
a
project
containing
a
Dev
file
and
you
can
see
there's
a
drop
down
here
with
two
projects
in
it.
These
are
all
of
the
projects
which
exist
under
the
group
hierarchy
of
which
the
workspace
is
part
of
so
we'll
go
ahead
and
pick
that,
and
this
will
automatically
update.
A
Also,
this
has
been
changed
from
Apollo
polling
to
graphql
subscriptions,
so
the
update
should
be
faster
and
it
is
also
easier
to
debug.
So
you
can
see
this
workspace
is
already
running
and
if
you
look
at
the
dev
file
that
I
used
to
distinguish
it
from
the
default
text
that
we
plug
in
for
the
text
field,
it
just
had
a
an
invalid
get
remote
that
it
was
going
to
check
out.
So
you
can
see
this
is
the
remote
Dev
project
under
the
remote
Dev
group.
A
There's
a
new
field
here
for
project
name
and
also
just
here
you
can
see
if
it
has
the
dev
file,
because
it's
triggered
by
asynchronous
workers
and
worker
queues
to
update
the
dev
file
from
the
project.
We'll
talk
more
about
that
in
a
minute.
So
if
we
open
up
this
workspace,
we'll
see
that
it
indeed
is
running
but
has
an
error.
A
So
we
have
this
project
clone
errors.log.
You
can
see
here
Yep.
This
is
an
invalid
repo,
I
couldn't
clone
it.
So
let's
go
in
and
edit
that
project,
but
instead
of
editing
it
through
the
UI
I'm
going
to
go
ahead
and
edit
it
through
to
get
command
line.
So
you
can
see
I
have
the
repo
here
with
the
dev
file
and.
A
A
Just
had
to
reboot
my
machine
because
QuickTime
wasn't
working
so
here's
my
editor
I'm
going
to
take
this
out
and
make
this
a
valid
Dev
file
with
a
valid
remote.
So
here
we
go,
we're
gonna,
add
that
update
Dev
file
and
in
the
GDK.
You
have
to
give
it
a
second
before
you
push
or
it
will
fail.
So
we'll
do
that
now
we
push
that-
and
we
can
see
over
here
if
we
go
back
to
our
workspace,
if
we
were
to
just
edit
it
and
click
over
here.
A
As
the
text
you
can
see,
this
is
now
showing
the
current
state
of
it,
which
doesn't
have
the
invalid
part
anymore,
and
the
problem
is
we're
not
automatically
restarting
this.
That's
a
an
unanswered
question
of
what
we
want
to
do
if
you
update
the
config
or
Dev
file
for
a
running
work
space.
So
for
now,
let's
just
go
ahead
and
request
a
restart
for
this
one,
so
it
will
pick
up
that
Dev
file,
while
that's
doing
I'll
point
out
a
couple
of
other
things.
We
now
have
this
calculated
displayed
State.
A
This
is
what
would
eventually
be
displayed
to
the
user,
whereas
this
actual
the
desired
state
in
actual
stator
more
for
helping
debugging
the
spike
Because,
the
actual
values
of
the
underlying
enumerations.
So
you
can
see
since
we
requested
it
to
restart.
It's
automatically
stopped
the
workspace
and
then
now
it's
restarting
it,
and
if
we
come
over
here,
we
can
see
the
the
ttyd
workspace
when
it
was
restarting.
We
lost
the
connection
to
it
and
over
here
yep,
it's
already
running
again,
so
we'll
hit
enter
to
reconnect
to
this
workspace.
A
The
repo
is
successfully
checked
out
with
the
URL
that
is
valid,
so
there
we
go.
Let's
just
let's
go
ahead
and
terminate
this
workspace
to
clean
everything
up
you
can
see.
We
now
have
a
active
in
the
terminated
tab.
Lots
of
other
terminated
workspaces
that
I
have
locally
and
here's
a
place
where
we're
calculating
a
different
displayed
State
than
the
actual
running
state,
because
the
dev
workspace
operator
doesn't
directly
support
the
terminated
State
and
in
a
few
more
seconds
you
should
see
this
workspace
get
terminated
and
disappear,
and
there
it
goes.