►
From YouTube: GitLab 13.7 Monthly (November) Release Kickoff
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
A
C
Thanks
dude
really
excited
to
talk
about
what
we
have
coming
here
in
13.7
for
the
enablement
section.
I
think
anybody
can
stop
sharing.
I
can
get
going
here.
One
quick
note
is
that
you
know
we
can't
highlight
everything
that
we
have
arriving
in
this
release
and
there's
so
many
good
things
that
I
encourage
you
to.
Please
take
a
look
at
the
group
videos
that
we
have
linked
on
this
page.
C
C
This
has
been
a
pretty
major
request
for
public
sector,
as
well
as
also
other
aspects
of
people
who
utilize
openshift
and
we're
making
some
major
progress
here
in
this
release,
we
are
working
to
utilize
our
helm
chart
as
the
internal
kind
of
templating
engine.
Since
we
know
it,
we've
been
a
lot
of
time
onto
about
two
years
and
allow
us
to
accelerate
delivery
of
this,
as
opposed
to
having
to
rebuild
all
that
templating
logic
in
the
operator.
C
So
we're
doing
that
first,
with
the
email
going
and
then
we'll
fan
out
and
tackle
all
the
other
charts
and
we'll
also
work
on
a
couple
other
details
around
things
like
submission
of
images,
for
certification
to
red
hat,
to
get
that
ball
going
as
well.
So
a
lot
of
progress
here
and
it'll
be
very
exciting
to
have
an
operator
which
will
work
on
both
kubernetes
and
openshift,
but
also,
of
course,
is
required
for
openshift.
So
great
news.
C
There
we're
also
working
to
close
a
key
gap
of
functionality
for
the
kubernetes
employment
of
gitlab,
and
that
is
to
offer
support
for
pages,
with
application
changes
being
done
largely.
We
can
now
go
ahead
and
start
to
incorporate
this
into
the
cloud
native
kind
of
architecture,
so
we're
building
a
pages
container
in
this
release.
That
will
then
enable
us
to
make
the
helmet
chart
changes
to
deploy
it
in
the
near
future
as
well
so
really
exciting.
This
has
been
a
highly
demanded
aspect
of
our
commercial
point
of
git
lab.
C
Similarly,
also
the
I
think
the
last
remaining
gap
is
service
like
hooks
and
so
working
to
add
support
for
that
as
well.
So
if
you
want
to
use
a
custom
hook
for
perhaps
doing
some
more
detailed
secret
scanning
pre-push,
you
can
now
do
that
after
13.7,
with
custom
git
hooks
and
so
excited
to
have
that
gap
closed
as
well,
so
overall,
very
exciting,
we're
also
moving
on
to
the
uses
and
usability
and
have
recently
launched
in
13.6
a
updated
navigation
experience
in
search
and
global
search,
and
so
you'll
now
get
a
left.
C
C
Moving
on
towards
single
platform
aspects,
we
are
working
to
enable
package
valve
verification.
This
is
the
first
verification
content
type
using
our
self-service
framework
and
so
we'll
be
adding
support
to
give
admins
the
confidence
that
their
content
was
replicated
correctly
and
also
building
the
framework
out
so
that
we
can
add
additional
content
types
verification
more
quickly
in
the
future,
so
allow
us
to
accelerate
the
progress
here
on
a
verification
and
we're
also
working
to
make
improvements
to
the
overall
memory
consumption
by
reducing
consumption.
C
So
we're
getting
a
pretty
big
spike
of
investigation
of
available
options
that
we
have.
You
can
see
this
going
on
right
now,
we'll
look
to
wrap
this
up
at
the
end
of
the
week.
We'll
then
go
through
and
kind
of
rate
these
based
on
impact
and
on
effort,
and
we'll
pick
a
few
of
these
for
the
net
seven
to
go
ahead
and
execute,
and
so
looking
forward
to
the
benefits
of
that
and
finally,
we're
also
looking
to
improve
how
we
do
data
migration
testing.
C
These
migrations
work
on
production
like
data
also
as
well,
and
that
we
can
have
less
need
for
these
rollbacks
in
the
event
that
we
have
to
do
that.
So,
overall,
some
great
content
there
from
enablement
a
super
express
release
and
I'll
pass
it
over
to
dev.
To
talk
about
all
the
great
things
coming
from
the
dev
section,
eric.
D
Thanks
josh,
that
was
great.
I'm
really
excited
for
all
that
stuff.
I'm
going
to
highlight
quickly
what
we're
going
to
focus
on
in
the
desk
section
for
13.7
and
as
usual,
we
have
two
themes.
Our
first
theme
is
kind
of
new
and
competitive
features,
and
our
second
theme
is
usability,
and
so
we'll
start
with
some
of
our
competitive
features
and
move
on
from
there.
D
The
first
feature
I
want
to
highlight
is
what
we're
calling
provisioned
accounts.
Provisioned
accounts
is
largely
an
account
that
is
essentially
tied
and
scoped
to
a
specific
group.
This
is
important
because
on
gitlab.com
organizations
want
more
control
over
the
users
and
what
they
can
and
can't
do
within
the
kind
of
the
confines
of
their
gitlab
experience
on
gitlab.com.
D
If
you're
running
a
self-managed
instance,
you
have
that
today,
and
so
we've
been
struggling
with
how
to
make
this
work
with
respect
to
accounts
that
already
exist
and
personal
accounts,
and
it's
just
not
a
great
solution.
So
one
thing
we're
going
to
begin
iterating
towards
is
this
concept
of
a
provisioned
account
and
what
we're
going
to
start
with
on
an
mvc
is
if
an
account
is
just
in
time
provision
using
saml
on
a
specific
group.
D
D
The
next
thing
that
I
want
to
highlight,
one
of
our
plan
teams
is
going
to
start
working
on
is
epic
boards,
so
we
just
finished
up
our
epic
swim
lane
work
in
13.6
and
now
we're
going
to
move
on
to
epic
board.
So
this
is
the
ability
to
view
and
manipulate
boards.
Sorry
epics
on
a
board
just
like
you
would
on
an
issue
board
and
then.
D
Moving
on
to
some
of
the
great
usability
improvements
that
we
have,
I
want
to
highlight
one
that
is
going
to
separate
filtering
users
from
sorting
users.
So
if
you
go
to
the
members
list
today,
the
sorting
and
filtering
options
are
in
the
same
drop
down
and
it's
hard
to
just
find
them
and
so
we're
working
through
the
design
today.
But
it
could
potentially
look
like
a
common
gitlab
pattern
across
the
application,
where
you
see
a
filter
bar
at
the
top
of
your
member
list.
So
you're
really
excited
for
that
improvement.
D
D
We
think
it
makes
more
sense
to
view
this
horizontally,
and
so
what
we're
going
to
do
is
to
make
this
the
experience
defaulted
to
on
which
lets
us
do
a
few
things.
It
provides
a
more
intuitive
experience,
moving
from
left
to
right,
which
is
how
most
people
view
the
flow
of
work.
But
then
it
also
allows
us
to
move
specific
information
and
charting
above
the
fold.
So
you
don't
have
to
scroll
down
to
see
that
information,
so
really
nice
usability
change.
D
I'm
looking
forward
to
the
next
one
is,
is
simple
but
important:
we're
going
to
provide
a
sorting,
sorry,
a
filter
list
by
blocking
issues,
so
you
can
sort
the
the
issue
list
by
the
number
of
issues
that
that
particular
issue
is
blocking
and
that's
a
lot
of
the
instances
of
the
word
issue
there.
But
this
will
really
help.
You
understand
how
many
issues
do
you
have
that
are
block
blocking
a
specific
issue
and
then
be
able
to
just
quickly
grok
and
understand?
D
If
you
were,
you
know,
working
in
a
github
repository,
so
we're
gonna
make
this
a
better
experience,
because
we
have
a
lot
of
users
that
are
using
gitlab
to
host
jupyter
notebooks,
we're
also
going
to
make
a
change
to
the
diff
view
for
mergerquest
file
ordering
today
we
have
a
really
inconsistent
and
weird
file
ordering
that
happens
when
you're
on
the
diff
view
and
to
just
highlight
this.
What
I'm
going
to
do
is
call
your
attention
to
this
bootstrap
migration
file,
which
is
actually
part
of
the
stylesheets
directory,
not
the
framework
one.
D
D
We
also
have
a
great
feature
inside
of
gitlab,
which
is
the
apply
suggestions
feature
so
as
a
code
reviewer,
you
can
make
a
suggestion
and
then
the
original
author
of
the
merge
request
can
go
back
and
apply
that
suggestion
super
easily.
But
you
can't
modify
the
commit
message.
We
just
give
a
default
commit
message
and
in
projects
where
the
commit
messages
have
specific
style
guidelines.
D
Lastly,
I
want
to
highlight
just
a
few
really
great
improvements
coming
to
our
jira
integration,
so
the
first
of
these
is
the
experience,
if
you're
in
jira
but
coming
from
gitlab,
and
we're
going
to
really
make
that
experience
a
lot
better
by
essentially
sending
build
information
through
our
jira
connect
app.
So
this
will
be
pipeline
information
that
you'll
be
able
to
view
inside
of
jira
if
you've
installed
our
jira
connect
app
through
the
jira
marketplace
or
the
atlassian
marketplace,
and
the
second
one
is
we're
also
going
to
send
deployment
information.
D
So
it's
just
make
that
the
integration
that
experience
much
much
better
if
you're
using
our
jira
connect
app,
which
I
would
highly
recommend
you
check
out
if,
if
you're,
using
both
of
these
tools
together,
the
second
improvement
we're
going
to
make
is
the
experience
of
jira
inside
of
git
lab
a
few
releases
ago.
We
shipped
the
ability
to
view
jira
issues
inside
of
gitlab,
and
then
we
also
ship
the
ability
to
authenticate
with
your
atlassian
user
as
well.
D
So
we
want
to
essentially
marry
those
two
experiences
together
and
give
you
more
information
about
your
jira
issues
inside
of
gitlab.
If
you've
authenticated
with
your
user,
so
the
first
step
in
that
process
is
to
add
the
issue
detailed
view
list
from
the
jira
issue
list
right
inside
of
gitlab.
So
you
can
view
the
issue
details
of
a
jira
issue.
E
E
My
name
is
kenny
johnson,
I'm
covering
the
ops
section
today
for
our
13.7
kickoff.
As
a
reminder,
the
op
section
includes
eight
different
groups
covering
five
stages:
verify
package,
release,
configure
and
monitor
I'm
going
to
jump
into
our
first
theme
for
today,
which
is
going
to
be
usage
and
usability.
E
Just
one
specific
thing
to
highlight-
and
I
want
to
emphasize
the
importance
of
this
type
of
work
from
within
gitlab
gitlab
is
a
single
application
for
your
entire
devops
platform.
We
know
that
many
of
our
users
are
currently
source
control
users,
so
they
use
our
core
git
and
repository
capabilities,
and
we
really
want
to
encourage
them
to
adopt
this
combination
of
source
control
and
ci.
So
we're
working
on
an
improved
pipeline.
E
Editor
experience
in
our
newly
created
pipeline
editor
team,
there's
a
three-year
vision
that
the
team
has
been
working
on
as
a
result
of
a
bunch
of
research
that
has
been
done
into
how
users
adopt
and
add
ci
to
their
existing
gitlab
instances,
and
so
we've
created
some
mocks
for
long-term
vision
that
include
a
home
page
to
see
what
kind
of
templates
you
can
have
and
how
to
get
started.
Ability
to
visually
edit,
your
ci
yaml,
by
adding
different
values
here
on
the
you
can
see
on
the
right
side
and
an
embedded
editor.
E
The
next
theme
I
want
to
talk
about
is
new
markets
and
josh
touched
on
the
open
shift
market
and
the
importance
of
it
for
git
lab
the
runner
team,
and
the
runner
is
the
core
execution
engine
for
gitlab.
Ci
is
also
going
to
be
working
on
an
operator
to
enable
the
runner
to
work
in
openshift
environments,
so
they'll
be
working
on
that
in
137
as
an
mvc,
with
a
planned
kind
of
full
ga
at
the
start
of
the
year,
we're
also
working
on
on-call
schedule
management.
E
So
the
monitor
team
is
going
to
be
working
on
the
initial
mvc
for
schedule,
management
that
includes
the
ability
to
create
an
initial
schedule,
assign
specific
users
to
time
periods
during
that
schedule
and
then
know
that
when
alerts
come
in,
they
will
automatically,
in
this
case,
we're
starting
with
email,
email,
those
users
with
options
to
add
additional
escalation
policies
and
communication
policies.
As
we
build
it
out.
E
A
really
great
mvc
that
showcases
our
kind
of
single
platform's
ability
to
add
value
in
new
places
that
you
might
have
existing
tools
or
might
not
have
existing
tools
and
have
homegrown
solutions
that
the
ease
of
having
gitlab
be
your
one.
Application
for
single
data
store
and
single
authentication
mechanism
makes
it
really
easy
to
get
started
with
these
critical
devops
functions.
E
The
next
category
that
I
or
theme
that
I
want
to
talk
about
is
single
platform,
and
eric
mentioned
in
when
talking
about
analytics
the
importance
of
dora,
4
and
other
operational
metrics
to
quantifying
how
successful
your
devops
transition
is
and
how
successful
your
adoption
of
devops
is
so
in
1307,
our
release
team
is
going
to
be
working
on
adding
a
chart
to
our
ci
cd
dashboard.
That
already
includes
pipeline
metrics
for
deployment
charts.
E
So
this
will
show
you
deployment
frequency
right
here
within
our
tool
based
on
you
know,
you've
orchestrated
deployments
with
your
gitlab
ci
cd,
we're
going
to
be
keeping
track
and
give
you
a
good
metric
of
how
frequently
and
at
what
time
periods
your
application
is
getting
deployed.
This
is
a
great
step
towards
providing
visibility
across
your
platform
into
how
successful
are
you
in
adopting
devops
by
counting
one
of
these
critical
metrics,
which
is
deployment
frequency?
E
The
last
topic
that
I
wanted
to
touch
on
is
actually
less
of
a
theme
and
more
of
an
announcement.
I
wanted
to
highlight
that
on
november,
2nd
docker
hub
began
forcing
rate
limits
to
pull
packages
from
the
from
docker
hub
that
they
had
previously
announced,
and
we've
immediately
noticed
that
users
were
concerned
about
what
happens
when
they
encounter
those
limits.
Will
that
stop
their
work
and
so
across
a
number
of
different
teams?
E
Gitlab
has
been
prioritizing
work
to
enable
some
level
of
security
that
we
can
in
some
sense,
if
you
get
blocked
by
that
rate
limit
that
we
can
still
allow
you
to
operate
your
devops
platform.
Those
include
in
ci
allowing
you
to
define
the
pull
policy
for
each
image.
So
maybe
you
can
say
only
pull
a
new
image
from
docker
if
it's
not
present
locally.
That
will
enable
you
to
not
always
hit
the
docker
api
and
account
for
your
rate
limits.
We're
also
going
to
be
enabling
this
via
the
runner.
E
So
that
is
also
work
that
the
runner
team
is
doing
and
our
package
team
is
working
on,
enabling
the
dependency
proxy
to
specifically
be
able
to
pull
images.
The
function
of
the
dependency
proxy
is
to
allow
a
layer
so
that,
if
docker
hub
or
you
have
some
other
repositories
aren't
available
that
you
can
still
pull
images,
but
it
does
require
some
metadata
being
fetched
from
docker
hub
that
we're
going
to
enable
that
you
can
still
pull
images
through
the
dependency
proxy,
even
when
docker
hub
is
unavailable.
E
So
that's
a
quick,
reactionary
thing
that
we've
been
doing
across
a
number
of
groups
within
the
op
stage
in
response
to
what
has
been
a
pretty
big
industry
news
about
docker,
hub's
new
rate
limit
policy,
as
always
tons
of
videos.
Please
check
them
out
from
each
individual
group.
What's
that,
I
will
hand
it
off
to
david.
B
B
Since
our
last
update,
we
actually
renamed
the
section
it
used
to
be
named,
secure
and
defend
it's
not
named
sec.
The
reason
for
that
is
gitlab
is
focused
very
heavily
on
devsecops,
and
now
you
have
kenya's
ops.
Eric
has
dev
and
my
team
is
sex,
so
it
works
very
well
together
for
static
analysis.
The
team
is
focusing
on
support
for
modern
repos
for
sas.
B
This
is
actually
improving
the
current
functionality.
That's
there
we're
seeing
a
trend
within
the
our
customers,
who
are
wanting
to
do
security
scanning
that
they're
moving
more
often
to
mono
repos
and
with
this
we'll
be
able
to
still
identify
what
scanners
would
need
to
run
and
get
those
kicked
off
based
off
what
we
detect
in
the
monorepo
from
dynamic
analysis,
they're
focused
on
extending
the
site
profile,
they're
actually
doing
two
improvements
to
it.
The
first
is
adding
support
for
api
scanning,
so
this
is
bringing
dash
api
to
dashed
on
demand.
B
The
other
area
they're
looking
to
do
is
extend
the
authentication
support
as
well
as
add
in
support
for
request
headers
and
when
we
first
started
giving
you
updates
related
to
the
on-demand
scans
and
the
profiles
we
started
with
just
up
here,
having
the
name
and
the
target
site
and
over
the
last
several
releases
they've
been
iterating
to
add
an
additional
item.
So
here
at
the
bottom,
you
can
see
support
for
authentication
and
then
additional
headers
as
needed,
so
very
excited
to
see
this
becoming
to
full
fruition
from
the
fuzz
testing
side.
B
A
B
This
work
is
bringing
the
output
of
the
scanner
into
our
security
report
format
and
that
will
then
make
it
auto-populate
out
into
those
views.
Here's
a
screenshot
of
what
that
would
look
like.
So
here
you
can
see
we
are
on
the
security
dashboard
and
we
chose
to
look
at
this
vulnerability
that
was
identified
and
it
brings
us
to
our
standalone
vulnerability
page.
We
can
get
all
the
information
related
to
headers
that
were
sent
responses
expected
the
artifacts
collected
and,
of
course,
information
as
to
what
the
vulnerability
is
and
how
to
remediate
it
and
then.
B
Finally,
the
threat
insights
team
has
focused
on
some
really
nice
improvements
to
the
vulnerability
management
experience.
The
first
is
finishing
up
the
support
for
jira
issues
being
able
to
be
attached
to
those
stand-alone
vulnerability
pages
so
again,
you'd
be
able
to
come
in
here
and
actually
directly
create
an
issue
within
jira.
B
This,
of
course,
is
building
off
of
the
work
that
is
being
done
by
eric's
team,
but
this
is
going
to
allow
you
to
track
your
vulnerabilities
across
both
platforms
as
you're
using
jira
for
some
of
those
functionalities,
and
the
final
item
is
including
support
for
special
references
for
vulnerabilities.
So
today,
when
you're
looking
on
an
issue
or
merge
requests,
you
can
always
do
like
a
tilde
and
then
type
in
information
for
your
label
and
then
that'll
reference
out
to
that
label.
B
Here
you
can
see
we'll
be
doing
the
same
thing
for
vulnerabilities,
you'll,
type,
vulnerability,
colon
and
then
the
vulnerability
id
it'll
also
auto
match
so
we'll
start
identifying
ones
that
are
available.
The
one
thing,
the
team's
doing,
which
I
think
is
very
cool.
You
can
actually
reference
vulnerabilities
across
projects
as
long
as
you
know,
the
name
space
so
you'll
be
able
to
after
the
call
and
put
in
the
name,
space
and
the
project
and
then
be
able
to
see
those
vulnerabilities
and
interconnect
them.
B
B
B
With
this
change.
We
move
the
container
scanning
category
over
to
help
enable
scanning
of
containers
in
production,
and
then
we
did
add
a
new
category
called
security
orchestration,
which
I
want
to
tell
you
about
today.
It's
very
exciting,
so
the
security
orchestration
category
is
focused
on
allowing
you
to
manage
your
policies,
whether
that's
scanning
or
schedule,
as
well
as
doing
it,
both
in
development
and
in
production,
and
the
first
focus
is
taking
those
das
profiles.
B
So
the
first
screenshot
here
you'll
see,
will
be
a
policies
option
and
a
list
of
policies
you're
already
using
the
policy
manager
today
for
your
container
security
options,
but
you'll
now
be
able
to
actually
create
policies
that
are
related
to
bad
scan
execution.
So
when
you
click
on
a
item,
it's
going
to
open
up
a
slide
out
here
and
you
can
see
you
can
edit
this
policy
or
at
the
scan
profile,
that's
being
used
and
then
we're
creating
a
new
profile.
B
It
looks
very
similar
to
that
experience
for
container
host
security,
where
you'll
be
able
to
set
the
scan,
execution,
information
or
the
schedule,
and
then
the
role
is
an
if
then
type
functionality.
So
here
you
can
see
we're
saying
you
know,
scan
the
default
branch
daily.
We
can
select
the
time
and
then,
if
we
don't
have
a
profile,
it's
going
to
tell
us.
We
need
to
create
a
scan
profile,
so
we
can
actually
then
use
the
policy,
and
then
you
can
select
it
to
run.
B
The
first
step
will
be
das
at
the
project
level,
but
we
will
be
bringing
gas
up
to
the
group
and
instance
level.
We'll
also
then
be
incorporating
the
rest
of
the
scanners
over
the
next
several
releases.
So
with
that,
as
always,
please
check
out
the
direction
pages
for
a
lot
more
information.
I
just
scratch
the
surface
on
all
the
great
things
that
the
team
is
doing
today
and
with
that
I'll
hand
it
back
over
to
noob.
B
A
You
david,
that
is
an
amazing,
amazing,
amount.com
stuff.
Coming
in
this
release,
I
made
a
few
notes
about
things
that
I
specifically
am
looking
forward
to.
Openshift
support,
obviously
search
faceting
enablement.
I
think
this
will
be
a
game
changer
for
people
looking
and
searching
on
the
gitlab
platform.
Provisioned
accounts
will
continue
to
help
with
our
enterprise,
customers
and
large
customers.
A
I
have
to
slip
this
joke
in
epic.
Boards
will
be
epic
right
and
then
responding
to
docker
hub
limits
and
being
mindful
of
what
our
users
are
facing:
on-call
schedule,
management
and
all
the
updates
on
second
product
stages.
This
is
unbelievable
work.
I
also
want
to
leave
the
team
with
one
final
change
that
we
are
making,
which
is
that
we
are
moving
toward
working
by
default
product
principle.
A
We
know
this
is
hard
and
we
welcome
your
feedback
and
inputs
on
how
we
make
this
happen,
and
the
caveats
are
the
cultures
that
we
need
to
face.
What
we
essentially
want
to
do
is
the
ability
to
have
features
on
by
default,
but
also
set
up
by
default,
so
that
we
can
responsibly
make
these
features
work
in
your
environments,
without
disrupting
regular
flow.
With
that,
thank
you.
Everyone
and
we'll
see
you
again
next
month,
bye.