►
From YouTube: Monthly Release Kickoff 13.6
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
First,
you
can
follow
along
with
us
on
direction.
Kickoff
page,
you
will
notice
videos
and
issues
for
almost
everything
we're
gonna
talk
about
today.
Second,
you
will
notice
a
feedback
link
here.
It's
a
really
short
survey.
It
will
take
you
less
than
two
minutes
and
we
encourage
everybody
to
participate,
so
we
can
make
this
process
better
for
everyone
involved.
B
A
C
A
Make
it
into
13.6,
but
we
really
try
to
make
them
in
that
1306
time
frame
and
fourth,
you
will
notice
that
usability
and
improvements
in
user
experience
to
drive
monthly,
active.
A
Over
iacv
drivers
and
dog
fooding,
this
was
a
significant
change
we
made
about
two
months
ago
and
we
are
seeing
very
significant
movement
in
how
we
prioritize
internally,
with
that,
I'm
gonna
lay
out
the
sequence
today.
So
we'll
start
off
with
the
dev
section,
led
by
eric
we'll
cover
manage
plan
and
create
stage
followed
by
kenny,
who
is
the
leader
of
these
ops
section
and
we'll
cover
verify
package,
release,
configure
and
monitor
stage
followed
by
secure
and
defense.
C
Rick
all
right
thanks
to
noop
I'll,
go
ahead
and
share
my
screen
and
get
started
all
right.
So,
as
always
in
the
dev
section,
we
have
grouped
some
of
our
items
into
themes
and
we've
got
two
big
themes
for
today.
The
first
theme
is
new
or
competitive
features,
and
then
the
second
theme
is
usage
and
usability,
and
so
we'll
go
ahead
and
get
started,
and
the
first
thing
I
want
to
highlight
is
that
we're
finally
going
to
focus
and
ship
an
mvc
on
what
we're
calling
saml
group
sync.
C
If
you
remember
a
few
releases
ago,
we
took
on
official
support
of
a
vs
code
extension,
and
so
what
this
will
look
like
is
basically
two
two
use
cases
as
a
reviewer
inside
of
vs
code
and
then
as
a
contributor
as
a
merge
request
author.
So
as
a
reviewer,
we
want
you
to
be
able
to
do
your
branches
through
vs
code.
Without
actually
checking
out
the
branch
submit
comments
back
to
the
mr
author
and
then
have
those
comments
propagate
back
to
the
gitlab
application
as
well,
and
then
as
a
contributor.
C
As
an
mr
author,
we
want
you
to
be
able
to
access
that
feedback
right
inside
vs
code
in
context,
so
you
can
make
changes
and
respond
to
those
comments
as
well
and
then,
of
course,
we'll
also
propagate
all
of
those
comments
back
into
the
gitlab
application.
So
you
have
a
consistent
experience,
no
matter
where
you're
looking
at
that
merge
request
either
inside
of
vs
code
or
inside
of
the
gitlab
interface.
C
And
then
our
last
big
new
feature
is
our
giddily
cluster
variable
replication
factor.
We've
been
working
on
this
for
for
quite
some
time,
but
basically
this
is
the
ability
to
set
a
variable
replication
factor
for
a
specific
repository
and
have
it
replicated
that
many
times
throughout
your
gilly
cluster.
This
will
really
help
to
manage
storage
cost
so
that
you
can
have
a
a
big
giddily
cluster,
but
have
a
specific
number
of
replication
factors
that
are
variable
dependent
on
how
important
or
how
fault
tolerant
a
specific
repository
needs
to
be.
So.
C
C
One
other
really
nice
improvement.
We're
going
to
make
is
we're
going
to
separate
the
new
group
and
project
creation
button
out
from
one
another.
It's
often
really
hard
to
find
where
you
need
to
click
to
make
a
new
subgroup.
You
actually
have
to
do
it
via
this
drop
down
right
next
to
new
project.
It's
not
very
intuitive!
So
we're
just
going
to
separate
that
out.
You
can
see
the
mock
up
here.
C
So
if
you
want
to
make
a
new
subgroup,
you
can
very
easily
right
there
on
the
group
overview
page
in
merge,
request
analytics,
which
is
a
great
feature
to
help.
You
understand
your
average
project
throughput
and
how
many
merge
requests
per
engineer.
You're
shipping
we're
also
going
to
add
a
new
container
on
that
graph,
which
is
the
mean
time
to
merge.
So
you
can
understand
the
average
amount
of
time
between
mr
opened
and
mr
merged
for
your
team's
throughput
and
then
we're
also
going
to
iterate
on
iterations.
C
Our
iterations
feature
is
the
feature
that
allows
a
lot
of
our
agile
teams
to
manage
their
sprints
inside
of
gitlab,
and
we
want
to
allow
the
iterations
to
be
more
tightly
coupled
together
with
our
issue
boards
feature,
so
we're
going
to
allow
you
to
make
an
iteration
issue
board
list
and
that'll
look
pretty
similar
to
making
any
other
list
inside
of
the
product
like
a
label.
Assigning
milestone,
be
right
here,
iteration
to
be
able
to
make
a
board
list
based
on
that
iteration.
C
We're
also
going
to
make
an
improvement
to
scope
a
board
to
the
current
iteration.
Now
the
way
the
feature
works,
you
can
only
have
one
iteration
be
current
at
a
time.
So
it's
just
a
simple
check
box
to
scope
your
board
to
the
current
iteration,
which
allows
you
to
filter
your
board
and
then
check
that
box
to
just
understand
the
issues
that
are
in
that
iteration.
C
We're
going
to
make
one
more
small
but
important
improvement
to
the
board
list
as
well,
which
is
to
remove
the
board's
upsell
list.
This
is
a
column
that
you
get
when
you
are
a
free
user
and
you
go
to
the
boards
for
the
first
time.
We
ask
you
to
upgrade
your
plan.
It
looks
really
poor.
It's
a
bad
experience.
C
C
This
improvement
will
display
which
approval
rules
match
a
given
reviewer,
so
you
can
very
easily
understand
who
to
assign
that
to
from
a
reviewer
perspective
in
order
to
get
your
mr
approved
and
ultimately
merged,
and
then
we're
also
going
to
provide
a
nice
improvement
to
multi-line,
merge,
request
comments,
which
is
the
ability
to
click
and
drag
your
cursor
over
the
block
that
you
want
to
comment
on.
So
this
will
look
something
like
this,
which
is
a
much
more
intuitive
experience
than
you
have
today,
to
provide
a
multi-line
comment.
C
Three
other
things
I
want
to
highlight
very
quickly.
We
recently
moved
navigation
and
settings
ownership
into
the
devs
section,
so
we're
going
to
work
on
two
small,
but
very
important
improvements
there.
The
first
one
is
we're
going
to
persist,
frequently
used
groups
and
projects
in
your
top
navigation
across
devices.
C
The
second
one
is,
we
have
a
whole
bunch
of
really
amazing
features
inside
of
gitlab,
but
sometimes
a
specific
group
or
project
is
used
for
a
very
specific
use
case.
We
want
to
have
the
ability
to
remove
left,
sidebar
navigation
menu
items
based
on
your
use
case.
You
can
already
do
this
today
for
some
menu
items,
but
not
all
so.
C
This
epic
is
essentially
making
that
experience
consistent
for
all
menu
items,
and
then
our
last
item
I
want
to
highlight
is
that
we're
going
to
make
some
really
nice
ux
improvements
to
our
jira
connect
app
our
jira
connect
app
is
the
application
that's
shipped
with
git
lab
that
connects
your
gitlab.com
projects
or
namespaces
to
your
jira
project
and
right
now
our
success
rate
for
installation
is
rather
poor.
There's
probably
a
few
reasons
for
that,
but
one
of
them
is
that
our
experience
is
actually
rather
bad.
C
Our
air
messages
are
rather
bad
and
we
don't
provide
a
great
way
to
actually
help.
You
select
your
namespaces
to
connect
in
that
application,
so
we're
going
to
provide
that
and
make
that
experience
better
and
hopefully
drive
this-
that
success
rate
up
with
respect
to
linking
your
jira
and
gitlab
instances
together.
D
Awesome
thanks
eric,
so
many
cool
and
exciting
improvements
as
a
heavy
user
of
gitlab,
I'm
excited
about
the
finding
by
last
name,
and
even
the
one
about
groups
and
projects
is
just
a
cognitive
load
that
I'd
never
even
realized.
I
was
carrying
so
super
excited
about
all
those
items.
Thanks
eric
I'm
gonna
share
my
screen.
My
name
is
kenny
johnson,
I'm
covering
the
op
section
covers
five
stages:
nine
product
groups
as
anup
and
eric
have
mentioned
tons
of
really
exciting
features
that
are
in
the
individual
groups.
Videos
please
check
those
out.
D
I'm
super
excited
to
share
just
a
small
sliver
of
the
items
that
I'm
excited
about
in
13.6
covering
three
key
themes.
First
theme
is
usage
and
usability,
and
I'm
going
to
cover
two
very
highly
popular
issues
from
the
verify
stage.
Let
me
jump
to
the
first
one,
I'm
going
to
start
actually
in
our
docs.
So
if
you're,
a
user
of
git
labs
ci,
you
may
have
jobs
that
include
a
before
or
after
script,
or
maybe
you
use
it
in
your
default
job.
D
This
enables
you
to
run
a
specific
script
after
the
completion
of
a
job,
but
as
if
you
notice
in
our
description
in
the
docs,
it
says
if
the
job
fails,
we'll
run
the
script
or,
if
it
completes
we'll,
run
the
script.
D
But
if
it's
times
out
or
cancels,
we
won't
so
in
13.6
we're
going
to
be
adding
the
support
for
if
a
job
is
canceled
or
timed
out
in
your
pipeline,
we
will
ensure
that
that,
after
script
runs
super
useful
feature
that
ensures
completion
of,
like
maybe
there's
a
clean
up
task
in
one
of
your
jobs
that
you
need
to
ensure
gets
executed,
regardless
of
the
results
of
the
pipeline
or
the
result
of
the
job.
The
second
really
highly
requested
issue
is
actually
also
I'm
going
to
start
with
the
docs.
D
If
your
job
fails,
if
the
script
in
your
job
fails
with
anything
other
than
an
exit
code
of
zero,
we
consider
that
a
failed
job
and
presented
as
such
in
your
pipeline
view
in
13.6.
We're
going
to
be
able
to
allow
you
to
configure
what
error
codes
result
in
what
output
from
that
job,
specifically,
so
you
can
define
which
ones
result
in
success,
warning
or
cancelled
right
here
in
your
gitlab
ci
yml
again.
D
D
We're
going
to
be
adding
the
ability
to
configure
directly
in
the
ui
in
this
kind
of
integrated
place
where
you're.
Looking
at
the
specific
environment
you
can
see
which
pods
are
in
canary
versus
successfully
running
the
stable
branch
and
alter
the
weight
right
here
in
your
ui
and
we'll
obviously
confirm
that.
That's
in
fact
what
you
want
to
do
before
doing
it,
but
it's
a
super
cool
way
for
us
to
continue
to
evolve
our
capabilities
around
advanced
deployments
which
allow
you
to
more
progressively
and
more
rapidly
deploy
your
application
to
production.
D
The
next
new
market
item
that
I
wanted
to
talk
about
is
in
our
monitor
stage,
and
this
is
about
enabling
you
to
continue
to
bring
your
alerts
to
get
lab
so
that
you
can
then
do
incident
management
and
incident
response
in
gitlab.
Alongside
the
same
application.
That
stores
who
wrote
your
code,
what
pipelines
were
run
et
cetera,
really
powerful
capability
to
have
these
two
components
integrated
and
in
13.6
we're
going
to
be
adding
the
ability
to
configure
multiple
alert,
ingestion,
endpoints
or
integrations
within
gitlab.
D
We'll
have
some
standard
ones
like
prometheus
and
ops
uni,
but
also
you'll
be
able
to
configure
the
http
endpoint
for
any
external
service,
including
being
able
to
map
the
specific
git
lab
keys
to
the
payload
of
that
alert.
This
is
really
important
for
organizations
large
organizations
who
have
existing
alert
infrastructure
and
want
to
send
those
alerts
so
that
they
can
triage
the
alerts
and
then
create
incidents
from
them
right
within
their
gitlab
ui,
where
their
developers
and
operators
are
already
interacting.
D
But
if
you
think
about
you,
if
you
were
using
separate
tools
other
than
git
lab
to
manage
both
something
unique
like
review
apps
that
is
unique
to
gitlab,
but
also
your
pipelines,
it
would
take.
You
know
multiple
release
cycles
from
both
of
those
tools
for
there
to
be
a
handy
integration
so
that
you
could
have
when
your
pipeline
was
generating
in
a
kind
of
child
pipeline
environment,
a
review
app
that
that
gets
spit
out
into
merge
requests
wherever
you're
doing
your
merge
request.
D
This
is
the
kind
of
thing
that
we
can
easily
fix,
because
we
have
a
single
application,
because
we
have
a
single
data
store
because
we're
approaching
it
from
the
perspective
of
users
who
are
using
a
single
single
tool
and
then
the
second
one
that
I
really
want
to
highlight
is
our
terraform
state
file
display.
So
git
lab
and
git
lab
in
the
last
couple
of
releases,
you've
been
able
to
attach
your
gitlab
terraform
state
to
gitlab
and
have
gitlab
manage
that
state.
D
The
way
you
manage,
that
is
through
gitlab
tools
like
merge,
requests
and
pipelines,
and
so
when
we're
displaying
that
current
status
of
the
state,
we
get
to
showcase
a
lot
of
cool
things
like
what
was
the
most
recent
pipeline
that
affected
this
managed
terraform
state
file,
this
definition
of
your
infrastructure.
What
is
the
recent
commits
and
branch
that
did
that?
Who
are
the
triggers
of
that
pipeline?
D
All
of
these
kinds
of
things
are
about
bringing
a
single
view
of
this
artifact
known
as
your
terraform
state,
your
infrastructure
state
all
under
one
roof,
so
everyone
can
see
the
interconnected
ways
in
which
that
has
been
adjusted
recently.
So
those
are
two
really
great
examples
of
the
value
of
a
single
platform
that
I'm
really
excited
to
showcase.
With
that,
I
will
hand
it
over
to
sam
to
talk
about
secure
and.
B
Defend
all
right
thanks,
so
much
k
sounds
like
there's
a
lot
of
great
stuff
coming
up
in
ops.
I'm
really
excited
about
the
the
build
status
and
the
exit
code,
customization,
and
so
for
those
who
don't
know
me.
I'm
sam
kirk,
my
principal
product
manager,
here
at
gitlab
and
today,
I'm
going
to
talk
to
you
about
secure
and
defend
some
of
the
things
we're
focusing
on
that.
B
We
hope
to
ship
in
13.6,
as
well
as
some
of
the
things
that
we're
focusing
on
doing
our
design
and
some
foundational
work
for,
but
really
the
the
themes
that
we're
focusing
on
are
usability
making.
Sure
our
product
is
easy
for
you
to
use
and
get
value
out
of,
as
well
as
the
single
application,
because
using
everything
in
the
same
place
gives
you
more
value.
B
And
so,
with
that
in
mind,
let's
take
a
look
at
the
first
thing,
and
that
is
we're
going
to
be
improving
the
mr
experience
for
users
that
are
on
core
and
still
want
to
use
scanners
like
sas,
and
so
we
know
that
today
it's
difficult
to
go
through
and
click
all
of
the
different
artifact
downloads,
one.
At
a
time,
so
what
we're
going
to
do
going
forward
is
put
all
those
results
in
a
single
place.
In
your
merge
request,
widget
you'll
have
to
do
a
single
click.
You'll
get
all
those
artifacts
all
at
once.
B
B
You
have
to
add
things
to
your
ci
files,
and
so
what
we're
going
to
do
is
enable
the
configuration
screen
for
security
and
compliance
for
all
users
going
forward,
and
if
you
click
into
that,
if
you're
a
core
user
you're
going
to
see
this
enable
via
merge
request
button,
this
is
going
to
help
you
walk
through
the
steps
you
need
to
add
sas
to
your
applications
and
again
save
you
a
whole
bunch
of
time.
Save
you
some
of
those
friction
points
with
having
to
do
all
this
manually
by
yourself
with
das.
B
B
What
we're
going
to
be
doing
to
help
make
that
easier
to
deal
with
is
actually
grouping
those
all
into
a
single
item.
So
even
if
a
finding
is
reported
10
different
times,
you
only
have
to
click
one
time
to
dismiss
it
or
resolve
it
or
do
whatever
you
want
to
do
with
that.
Finding,
rather
than
doing
it
10
times.
B
For
fuzz
testing
we're
going
to
be
focusing
on
re-symbolicating
our
crash
results-
and
I
know
that's
a
scary
sounding
word,
but
what
it
really
means
is
just
making
the
results
human
readable.
What
you
would
see
today
from
your
fuzzing
crash
results,
is
a
stack
trace
like
this.
It's
not
going
to
be
easily
understandable
and
actionable,
but
we're
going
to
be
making
this
human
readable
by
adding
things
like
the
file
name
and
the
file
line
number
directly
into
those
crash
results.
Your
devs
can
immediately
see
where
the
problem
is
and
start
taking.
B
We're
also
going
to
be
working
on
implementing
what
we
call
our
fuzzing
corpus
registry.
Today,
you
have
to
manage
your
corpus
objects
directly
in
your
git
repo,
which
is
time
consuming
and
difficult.
So
I'm
showing
a
prototype
of
how
we
plan
to
address
this.
Where
this
corpus
registry
will
actually
house
all
of
the
corpus
objects
attached
to
your
project,
you'll
be
able
to
see
their
names
different
pieces
of
metadata
about
them.
You
can
download
them
to
look
at
them
locally
or
delete
them.
B
We're
also
focused
on
enabling
open
api
v3
support
with
this
release
as
well.
Today
we
support
v2,
open
api
or
swagger
files
for
api
fuzzing,
and
so
we
want
to
make
sure
that
if
you
have
a
v3
file,
you
can
use
that
file
directly
going
forward
rather
than
having
to
either
downgrade
or
make
the
decision
not
to
use
api
fuzz
testing.
B
One
of
the
other
things
we're
focusing
on
this
release
is
some
design
work
around
how
you
could
link
jira
and
gitlab's
vulnerability
management
systems
together
so
going
forward.
What
you'll
start
to
see
is
a
bar
down
here
at
the
bottom
of
each
individual
vulnerability
object
with
related
jira
issues,
you'll
be
able
to
create
a
link
between
those
two
systems,
and
so
in
this
example,
we
see
sec123
here
is
linked
to
this
gitlab
vulnerability,
so
that,
regardless
of
the
type
of
processes
you
have
in
place,
you'll
be
able
to
use
both
systems
more
effectively
together.
B
In
a
similar
vein,
we
know
that
users
can
get
vulnerabilities
reported
from
places
besides
our
own
scanners,
such
as
from
a
user
manually,
finding
something
or
a
third
party
penetration
test,
and
so
we're
working
on
figuring
out
how
we
can
best
allow
you
to
manually
enter
those
vulnerabilities
into
git
lab
the
concept
design
that
I'm
showing
here
right
now
will
allow
you
to
add
description.
Information
give
it
a
name,
add
various
pieces
of
metadata
so
that
you
can
manage
these
vulnerabilities
just
like
you
would
any
of
the
other
results.
B
You'll
get
from
get
lab's
own
scanning,
and
so
those
are
the
high
level
things
that
we're
focusing
on
with
secure
in
this
coming
iteration.
So
I
want
to
switch
gears
and
talk
a
little
bit
more
about
defend
now,
and
so
one
of
the
things
we've
learned
from
working
with
customers
and
users
with
defend
is
that
it
can
be
difficult
to
find
the
individual
results
that
all
of
our
sensors
are
reporting.
B
So
we're
going
to
be
starting
to
work
towards
what
we
call
the
project
level
alert
dashboard
to
help
you
understand
and
more
easily
manage
all
of
those
findings.
I've
got
a
small
demo
application
here.
This
is
a
concept
demo,
where
the
various
gitlab
sensors
will
report
results.
They'll
be
immediately
shown
this
unreviewed
column
rather
than
in
a
very
long
log
file.
Your
team
can
then
look
at
those
results
and
mark
them
as
under
review.
E
Thanks
sam
some
great
features,
so
let's
talk
about
the
highlights
that
we're
working
on
here
in
13.64
enabling-
and
we
group
them
into
a
few
themes-
let's
jump
in
with
features
and
customer
requests
here
and
the
big
one
that
we're
working
on
in
this
area
is
supporting,
deploying
gitlab
server
on
openshift.
E
We
are
working
on
a
few
issues
here.
The
two
big
tracks,
we're
working
on
number
one-
is
validating
that
we
can
use
the
helen
chart
as
the
inners
of
the
operator
to
leverage
much
of
that
learning.
We
have
over
the
past
few
years
of
deploying
git,
lab
and
kubernetes
and
proving
that
out
as
well
as
also
taking
an
image
or
two
and
submitting
them
for
certification
to
red
hat.
Both
these
will
allow
us
to
better
understand
the
scope
of
effort
in
front
of
us
and
better
than
schedule
the
following
iterations
after
this.
E
E
The
key
here
is
that
sometimes
you
of
course
want
to
have
a
failover
between
your
primary
and
your
secondary,
and
so
to
do
this,
you
want
to
make
sure
that
your
secondary
has
all
the
content
of
your
primary
and
it
can
take
a
minute
or
two
depending
on
the
latency,
between
the
two
instances
to
that
to
happen,
and
so
we
want
to
go
ahead
and
allow
an
admin
to
set
a
primary
into
read-only
mode.
Allow
all
that
replication
to
finish
and
then
promote
the
secondary.
E
This
is
particularly
important
if
your
primary
is
degraded
for
some
reason
and
might
not
be
performing
as
well
as
you'd
hoped,
we'll
automate
this
likely
in
the
future,
but
for
now
we
want
to
introduce
it
as
a
cli
option
so
that
you
can
address
this
use
case
in
a
smaller
iteration
running
out
the
feature
requests
here.
We
are
also
working
to
finish
up
the
effort
to
break
out
ldap
credentials
and
into
and
out
of
the
gitlab
rb
configuration
file.
This
is
the
common
configuration
file.
E
E
E
This
will
allow
us
to
share
more
of
that
shared
libraries
and
reduce
the
overall
memory
consumption
as
we
continue
to
grow
the
number
process
to
handle
increased
number
of
requests,
and
similarly
with
that,
we're
also
looking
to
take
advantage
of
the
ruby,
2.7
improved
government
collection
system,
which
will
also
help
to
ensure
we
can
continue
to
share
more
of
that
memory
going
forward
as
the
process
lives
and
processes
requests.
So
these
work
in
tandem
to
provide
a
good
experience
for
our
users.
E
Last
I'd
like
to
touch
on
the
single
platform
improvements
we're
making
as
well
and
the
key
one
here
is
that
we
are
working
towards
adding
or
really
shifting
much
of
the
filtering
options
in
search
over
to
the
left
hand
sidebar.
So
we've
been
working
on
adding
things
like
filtering
on
status
and
confidentiality
and
right
now,
they're
kind
of
a
second
row
here,
underneath
issues
and
murder
quests
and
things
like
that
and
I'll
shift
them
down
to
left
fastening,
to
provide
a
more
modern,
feel
and
it'll.
E
Give
you
more
control
in
searching
and
exploring
what
you're
looking
for
across
all
the
content.
That's
indexed
on
gitlab
so
really
excited
about
this,
and
we're
also
looking
to
continue
to
add
additional
filtering
options
here
in
the
near
future.
As
we
look
to
move
more
and
more
of
this
over
to
left-hand
rail
fastening,
as
opposed
to
having
these
tab
views
up
top.
A
Thank
you,
josh
13.6
is
turning
out
to
shaping
up
to
be
an
amazing
release.
It's
a
highlight
of
my
month
to
do
these
kickoff
calls.
As
always,
we
encourage
everyone
to
take
the
survey
if
you,
if
you
can
to
help
us
improve,
engage
with
us
on
the
issues
and,
of
course,
contribute
code
and
improvements.
As
you.