►
From YouTube: Custom JSON Schema in the Web IDE
Description
In GitLab 13.4 we're releasing Custom JSON Schema validation in the Web IDE. You can see more about this feature in: https://gitlab.com/gitlab-org/gitlab/-/issues/226982
The GitLab release post schema is: https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/schemas/releasepost.schema.json which is defined in: https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/.gitlab/.gitlab-webide.yml
A
Hi,
my
name
is
kai
armstrong,
I'm
the
product
manager
for
the
editor
group
in
the
create
stage
of
the
devops
lifecycle
at
gitlab,
and
I
want
to
talk
about
a
new
feature
that
we've
got
coming
out
in
git
lab
13.4,
which
releases
tomorrow.
So
I'm
going
to
share
my
screen,
we'll
go
through
a
couple
things
of
how
we
got
here
and
what
we've
got
and
then
I'll
demo
off
the
new
feature.
So
let
me
share
this
one.
A
So
in
gitlab
13.2
we
released
real-time
feedback
for
the
gitlab
ci
yml
file
in
the
web
id,
and
so
that
is
based
on
a
json
schema
file
that
defines
sort
of
the
properties
and
fields
that
the
gitlab
ci
file
should
have,
and
then
there's
feedback
that
pops
up
in
the
form
of
these
squiggly
lines
down.
Underneath
that
show
you
that
something's
wrong
and
then
a
message
that
pops
up,
that
tells
you
sort
of
what's
missing
or
what
you
need
to
do
to
fix
that.
A
So
we
thought
about
that
feature
and
we're
like
that's
great.
This
is
really
good
for
file
types
that
are
widely
used
either
in
git,
lab
or
sort
of
in
other
places
that
schema
store
might
present,
or
there
might
be
other
things
that
are
in
schema
store
that
you
want
to
use.
So,
instead
of
extending
those
one
by
one,
we
thought
we
should
extend
this
just
allow
you
to
sort
of
define
what
you
want
and
then
we'll
continue
to
define
sort
of
in
the
base
level.
A
And
then,
when
you
open
the
web,
ide
you'll
get
that
feedback,
and
so
let
me
just
show
you:
this
is
the
www.getlab
repo.
This
is
where
we
do
release
posts
and
so,
as
a
sort
of
proof
point
for
this
james
ramsey
who's,
another
product
manager
here
defined
the
schema
for
release
post
items.
So
let
me
open
up
a
couple
files,
we'll
show
you
the
schema
too.
So
inside
of
this
project
he's
defined
a
schema.
He
wrote
the
schema
file.
A
It
tells
you
what
fields
are
required
sort
of
what
the
description
is,
what
values
are
acceptable
in
the
case
of
where
there
are
values
that
need
to
be
specified
and
it
goes
through
and
it's
a
fairly
lengthy
file.
These
are
sort
of
complicated
arrival.
Maybe
we'll
be
able
to
produce
some
documentation
in
the
future
that
helps
you
can
read
more
of
them
sort
of
these
on
jsonschema.org
and
try
and
understand
what
these
are
when
you're
writing
a
custom
one.
This
is
a
custom
one,
that's
in
our
project,
for
the
release
pose.
A
Now.
If
I
go
to
this
file,
what
I
see
is
this:
is
the
dot
get
lab
web
ide
yaml
file?
This
is
inside
the
project.
It's
inside
the
project,
but
you'll
notice
we're
having
to
reference
this
file
based
on
the
full
raw
url.
So
we
don't
support
relative
linking
so
you've
got
us.
You've
got
to
supply
us
this
file.
I
would
say
the
other
caveat
there
is
that
that
means
it
needs
to
be
a
publicly
available
file.
If
you
were
doing
this
in
a
private
project,
this
may
not
work
as
expected.
A
You'd
need
your
schema
file,
sort
of
publicly
available
at
a
url
that
it
can
be
completely
referenced.
Once
we've
done
that
we
define
what
file
types
it
needs
to
match
against.
So
in
this
case
we're
matching
against
the
release,
post,
unreleased
yaml
files
that
all
product
managers
use
when
they
go
and
draft
a
release
post
item
and
that's
how
we
build
out
our
big
giant
release
post,
so
we've
defined
the
schema.
A
A
I
see
it
here
now
sneak
peek,
but
this
is
all
of
the
fields
that
we
define
when
we
go
through
and
do
this
and
you'll
notice
that
I've
already
got
a
squiggly
line.
I
sort
of
went
and
was
messing
with
this
to
make
sure
I
could
generate
the
proper
errors
and
just
starting
here
where
it
says
available
in.
If
I
hover
over
it,
it
says
tears
the
features
and
available
and
so
for
features
on
only
gitlab.com
it
can
be
free,
bronze,
silver
or
gold
can
be
used
and
it's
a
required
field.
A
So
I
get
all
this
information
about
what's
required
for
this
field
and
then,
when
I
click
here
because
there's
these
quickly
lines,
I
know
there's
an
issue.
I
click
on
and
it
says
the
value
is
not
accepted.
Valid
values
are
core
starter
premium,
ultimate
free,
bronze,
silver
and
gold.
Well,
that's
good,
because
I
I
can
now
see
oh,
I
must
have
just
missed
all
that
which
is
really
helpful,
and
this
is
consistent
sort
of
throughout.
So
if
I
were
to
like
maybe
misspell
this
one,
let
me
get
rid
of
this.
A
A
And
now
we're
expecting
a
string,
so
we
at
least
get
a
little
bit
of
help
there,
and
all
of
this
is
based
on
our
schema.
So
the
more
we
define
in
our
schema,
the
the
better
those
errors
can
be
and
the
more
we
can
learn
about
them.
So
if
I
look
here
stage
all
we
say
is
it's
got
to
be
a
string,
we're
not
matching
sort
of
the
expected
stages
in
here,
although
we
could,
similarly
to
how
we
do
we
say
available
and
we've
defined
in
the
schema.
A
What
that
looks
like
we
could
also
define
in
here
what
the
valid
pieces
for
a
stage
are
so
we'll
continue
to
iterate
on
our
own
schema,
but
I
really
wanted
to
show
off
how
now,
with
custom
schema
if
you've
got
a
file
type.
That
is
something
consistent
that
you
use
on
a
regular
basis
that
you
know
users
would
benefit
from
having
that
additional
validation.
A
So
something
like
a
maybe
a
blog
post
or
a
front
matter:
template
for
a
static
site
or
other
things
like
that,
where
you
could
define
key
fields
that
are
required
for
your
yaml,
then
you
could,
you
know,
draft
a
schema
and
then
you
could
have
that
in
here
and
that
way
the
web
id
can
help.
Those
users
write
that
file,
and
so
we're
really
excited
about
introducing
this,
not
only
for
our
own
workflow
and
the
release
post,
but
to
see
what
our
users
do
with
it.