►
From YouTube: 14.1 Monthly Release Kickoff (Public Livestream)
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
In
just
one
day,
we
will
be
releasing
14.0
a
major
release.
I'm
extremely
excited
about
the
amazing
capabilities.
14.0
has,
for
instance,
merge
request,
merge,
requests
and
vs
code,
epic
boards,
visibility,
markdown
editor
for
wikis,
improved
container
scanning
and
new
user
interfaces,
and
today
we'll
talk
about
14.1
slated
for
july
22nd.
A
A
We
also,
by
the
way,
did
a
big
refresh
to
our
deployment
direction,
place
so
check
that
out
and
give
us
feedback
today,
we'll
start
with
kenny
johnston,
senior
director
of
product
for
ops,
followed
by
josh
director
of
enablement
and
then
senior
director
of
second
deaf
sections,
david
di
santo.
Take
it
away
kenny.
B
Awesome,
thank
you
anup
yeah
tomorrow,
at
14.0
release
day,
it's
also
the
first
day
of
summer.
So
looking
forward
to
that
yeah.
As
a
new
mentioned
in
the
op
section,
we
have
verified
package,
released,
configure
and
monitor
stages
and
we've
combined
release
configure
and
monitor
into
a
new
deployment
direction.
So
you
can
find
all
of
that
linked
in
our
direction
page.
B
I
want
to
start
by
highlighting
a
couple
of
issues
that
were
working
in
the
ops
section
in
the
pipeline
authoring
group,
where
both
issues
are
going
to
concentrate
on
this
primary
use
case
that
we've
identified
with
our
users,
which
is
in
organizations
that
have
many
teams
working
and
building
applications
together
and
creating
ci
cd
pipelines.
They
want
to
share
their
pipeline.
B
They
want
to
share
the
code
that
creates
the
pipeline
that
they've
defined
in
their
gitlab
ci
yaml,
and
we
have
a
bunch
of
ways
for
you
to
do
that
today,
but
we
want
to
make
that
easier
for
you.
The
first
way
we're
going
to
make
that
easier
is
by
allowing
you
to
conditionally
include
ci
ymo
templates
into
your
pipeline
for
your
project.
So
today
this
is
possible.
You
can
do
it.
B
Many
users
do
this
by
creating
dynamic
pipelines,
so
they
have
a
pipeline
that
kicks
off
and
dynamically
creates
a
new
pipeline
based
on
the
right
templates
for
their
project.
You
know
their
project
specific
configuration,
but
we
want
to
make
that
a
lot
easier
by
just
allowing
you
to
define
specific
conditional
logic
that
determines
whether
or
not
a
template
is
included
in
your
ci
pipeline.
B
This
is
a
highly
requested
issue
with
51
upvotes,
and
it's
something
that
we're
really
excited
to
deliver
to
improve
that
experience
of
managing
various
components
of
your
pipeline
centrally
and
having
them
included
conditionally.
The
next
thing
we're
going
to
be
working
on
is
actually
a
really
simple
mvc.
That's
the
first
step
towards
us
providing
a
better
template
experience
when
editing
your
pipeline.
So
if
you'll
recall,
we
had
have
presented
a
vision
for
what
we'd
like
where
we're
headed
with
our
pipeline
builder.
B
B
The
include
logic
directly
into
your
pipeline
definition
right
here
within
that
editor
experience
that
as
an
mvc
we're
first
going
to
be
using
this
just
the
standard
git
lab
repository
view
of
those
pipelines
so
that
when
you
click
on
an
individual
one,
you
can
grab
the
snippet
that
says:
here's
how
you
include
it
and
include
it
into
your
template.
So
those
are
both
really
great
features
that
we're
working
on
to
improve
a
known
user
experience
that
we
hope
will
drive
adoption
of
gitlab
ci.
B
The
next
issue
I
wanted
to
highlight
is
another
highly
upvoted
issue
that
we've
been
working
on
and
that's
using
a
variable
inside
of
another
variable.
So
this
is
important
when
you
want
to
add
more
complex
logic
to
how
your
pipeline
gets
executed
and
what
is
executed
in
the
the
specific
job
that
the
runner
is
picking
up.
What
we're
going
to
be
doing
is
allowing
you
to
reference
a
previously
defined
variable
in
a
variable
that's
later
defined,
so
you
can
see
this
example
you're
referencing
variable
1
when
defining
variable
2..
B
This
allows
for
more
complex
logic
within
your
ci,
within
your
jobs,
as
defined
in
your
ciemo.
We're
really
looking
forward
to
adding
this
in
14.1.
B
The
next
feature
that
I
wanted
to
highlight
is
really
about
improving
the
adoption
of
our
dependency
proxy,
so
the
dependency
proxy,
if
you're
not
familiar,
allows
you
to
reference
external
package
registries
from
within
gitlab
all
at
one
kind
of
single
endpoint,
so
that
your
developers
don't
have
to
know
whether
or
not
the
specific
package
they're
looking
for
is
posted
in
gitlab
or
hosted
in
a
central
package
registry
like
a
npm
or
something
like
that.
B
We
want
to
make
this
easier
by
allowing
you
to
use
deploy
tokens
that
are
available
at
the
group
level
when
interacting
with
your
dependency
proxy
and
then
the
last
issues
that
I
want
to
highlight
is
our
continued
improvement
in
our
incident
management
capabilities,
which,
starting
today,
we're
actually
utilizing
for
all
gitlab.com
incidents
internally,
which
I'm
really
excited
to
hear
about.
But
we're
going
to
be
continuing
to
add
on
to
escalation
policies
by
shipping
additional
parts
of
our
mvcs
in
14.1,
as
well
as
allowing
you
to
manually
trigger
escalation
policies.
B
So
this
would
be
if
you
manually,
created
an
incident
and
instead
of
wanting
to
trigger
an
escalation
based
on
the
alerts
status,
so
a
specific
alert
that
might
have
come
in
you
say
well,
I
manually
created
this
and
I
want
to
immediately
page
the
appropriate
escalation
policy
personnel.
You
can
do
that
with
a
quick
action
or
you
can
do
that
manually.
I
want
to
show
you
how
you
can
do
that
here
in
this
mockup,
where
you
can
adjust
the
escalation
policy
manually
and
that
will
immediately
page
them.
B
C
Thanks
kenny,
those
are
super
exciting.
I
can't
wait
for
the
new
ci
builder,
also
the
instant
management
functionality
it's
great
to
see.
It
continue
to
improve
I'll
talk,
of
course,
about
our
enablement
functionality
and
we'll
get
things
started
with
adoption
through
usability
for
many
of
you
who
have
used
global
search
here
at
gitlab
at
the
search
that
works
through
and
searches
all
the
content
issues,
mrs
and
code
across
the
entire
product.
We
are
working
to
improve
the
group
and
project
drop-downs.
C
If
you've
used
these,
you
may
have
found
out
or
have
used
other
project
or
group
drop-downs
across
the
product.
They
don't
always
return.
What
you're?
Looking
for
I'm
trying
to
find
gitlab
dash
or
gitlab,
I'm
not
getting
the
results,
I'm
really
intending
to
see.
We
are
working
to
improve
that
this
release
with
two
features.
The
first
is
that
we
are
taking
the
current
sub-optimal
rankings
system
and
working
to
adapt
a
algorithmic
score
based
on
a
number
of
factors
which
will
hopefully
provide
a
more
relevant
result
for
your
searches.
C
Of
course,
global
search
is
good
at
this,
but
we're
also
working
to
also
provide
a
list
of
recently
used
projects
and
groups
as
well.
So
before
you
even
search,
we
will
show
you
what
you
likely
probably
want
to
try
and
use
anyways
and
then,
when
you
do,
search
we'll,
hopefully
be
showing
you
the
more
relevant
one
first,
and
so
that
way
we
can
all
help
and
improve
this
part
of
our
product
here
and
help
you
find
multiple
we're
looking
for
from
there.
We
can
move
on
to
our
geo
functionality.
C
This
is
the
function
of
git
lab
where
you
can
stand
up
multiple
nodes
across
the
world
to
provide
improved
performance
for
your
users
currently
with
the
web
ui.
When
users
are
trying
to
use
it,
they
get
a
banner
across
the
top
that
tells
them.
This
is
actually
a
read-only
site
that
they
have
to
go
to
the
primary
to.
Actually,
you
know
kind
of
comment
or
make
any
changes.
C
This
is
suboptimal
for
that
reason,
but
also
because
we
have
to
have
different
urls
for
both,
and
so
users
have
to
be
aware
of
that
other
url,
the
secondary
to
get
that
performance
boost.
We
are
working
to
solve
those
both
of
these
problems
with
this
work
here
to
have
secondary
sites
proxy
to
the
primary
site.
So
you
can
have
a
common
url
where
any
kind
of
traffic
that
hits
the
secondary.
Perhaps
you
were
directed
there
to
the
secondary
because
you're
closest
to
it.
C
If
you
were
to
look
at
it
load
pages
and
then
make
a
change,
we'll
actually
proxy
the
change
transparently
to
you
over
to
the
primary
and
so
your
users
of
your
gitlab
instance
and
of
course
your
broader
users
can
simply
access
transparently
the
fastest
site
to
them
at
the
time
and
they
can
use
it
as
if
they
were
using
the
primary.
So
the
whole
concept
of
secondaries
just
goes
away,
and
your
overall
experience
should
just
be
faster
for
our
users,
so
super
excited
about
this
and
for
the
improvement
to
our
geo-replication
functionality.
C
We're
also
working
to
simplify
the
process
for
promoting
a
secondary
to
a
primary
in
the
event
of
some
kind
of
disaster
or
challenge
right
now.
You
have
to
run
at
least
two
commands
and
then
also
edit.
The
configuration
on
each
server
we're
working
to
simplify
this
process
with
a
single
command
promotes
a
primary
that
can
be
run
on
these
nodes.
C
That
will
do
the
right
action
based
on
what
type
of
instance
they
are
whether
database
or
italy
or
rails,
and
so
simplifying
the
whole
process,
and
this
is
to
further
improve
our
work
towards
really
making
sure
the
secondary
promotion
process
should
be
as
simple
and
hopefully
as
automated
as
possible
from
there.
Let's
work
on
our
sas
first
topics,
the
first
one
I
want
to
talk
about
here
is
allowing
scitic
to
use
re-replicates.
C
But
in
reality
a
lot
of
these
jobs
don't
actually
have
to
write
content,
and
so
they
can
actually
use
secondaries,
and
so
this
work
is
going
through
and
finding
those
psychic
jobs
that
actually
don't
need
the
right
content
and
having
them
get
directed
towards
a
read-only
replica
so
that
you
can
overall
scale
us
the
primary
higher
or
just
have
a
smaller
scale
primary,
for
instance,
because
we
can
better
distribute
the
load
from
there.
We're
also
looking
to
upgrade
our
core
ruby
version
to
3.0.
C
For
those
who
may
not
be
aware,
the
goal
the
ruby
team
set
back
in
twitter
was
to
be
three
times
faster
in
3.0
and
so
we'd
like
to
upgrade
to
theater,
though,
to
take
advantage
of
those
and
performance
improvements
and
other
features
as
well.
Right
now
we're
on
2.7
and
so
there's
a
fair
bit
of
work
to
make
sure
our
gems
are
all
updated
to
make
sure
our
code
is
all
compliant
and
works
with
ruby,
theater,
doe,
and
so
we're
working
towards
that.
C
C
Work,
that's
just
getting
underway
continuing
on
the
theme
of
performance
and
scalability,
we
have
our
primary
key
re-indexing
process,
so
some
of
our
larger
tables,
like
sea,
artifacts
and
web
hooks
currently
have
a
relatively
small
primary
key
size,
and
the
larger
instances
that
are
around
for
longer
are
in
danger
of
actually
running
into
this
and
running
out
of
index
space,
so
we're
going
through
all
of
our
tables
and
converting
them
over
to
a
much
larger
index
size.
So
they
can
continue
to
grow
for
years
and
years
and
years
to
come
without
any
problems.
C
We
are
completing
this
work
in
14.1,
as
you
can
see
here,
with
a
large
number
of
tables
all
being
migrated.
This
is
a
great
effort
from
the
team
and
has
completed
faster
than
we
expected
it
to
and
well
before
any
instances
actually
had
this
problem
continuing
on
database
scalability.
We
also
have
our
sharding
group,
which
is
looking
at
taking
the
main
github
database
and
taking
parts
of
it
and
moving
them
over
to
separate
logical
databases.
This
would
be
largely
transparent
for
all
of
our
self-managed
users.
C
However,
it
will
provide
the
scalability
for
the
very
very
large
instances
should
they
need
it
to
run
these
on
separate
instances
or
separate
database
hardware,
and
so
what
we're
doing
here
is
we've
gone
through.
We've
established
our
design
and
we'll
be
taking
the
most
commonly
or
the
largest
portion
of
our
database,
which
is
our
ci
tables
and
moving
them
into
that
separate
logical
database.
C
If
I
go
back
here
to
the
overall
size,
you
can
see
that
webhook
logs
is
actually
by
itself
the
next
largest
database
portion
of
our
database
next
to
ci,
and
so
we're
going
to
be
going
through
this
and
actually
implementing
time-based
partitioning
and
ultimately
retention
policies.
So
we
can
drop
this
content
very
easily
because
for
a
lot
of
our
self-managed
customers,
this
table
can
be
the
biggest
table
in
the
overall
database
because
it's
containing
so
many
webhook
logs
from
a
long
time
ago.
C
We
can
automate
this
drop
those
content
with
pretty
safely,
and
this
will
save
db
admins
on
our
self-managed
instances
from
having
to
go
in
and
drop
this
content
manually
every
six
months
after
it
gets
too
big.
C
So
this
is
a
great
improvement
for
performance
as
well
as
overall
quality
of
life
and
finally,
let's
get
on
to
the
operator
and
new
markets,
we're
continuing
to
work
towards
our
ga
release
of
our
operator,
and
we
will
be
going
through
and
addressing
a
couple
last
items
here
to
improve
the
installation,
experience
solving
things
like
ssh
support
and
overall
propagation
for
going
ga
we're
very
close
in
the
line
here.
If
you're
interested
in
testing
our
beta
release
originally
released
in
1311.
C
D
Thanks
josh-
and
let
me
get
my
screen
shared
here:
okay,
so
to
dive
in
here.
Let's
start
off
with
dev
the
create
stage.
First
they're
focused
on
two
items:
usability
through
adoption
as
well
to
scale
building
performance.
D
So
the
first
item
is
focused
on
the
scale
loading
performance-
and
this
is
us
rolling
out
a
beta
version
of
our
gitlab
sshd
divan.
This
will
be
replacing
the
traditional
open,
ssh
daemon,
that
we've
been
using.
The
main
reason
for
this
is
to
give
us
better
scalability,
as
well
as
better
stability
for
gitlab.com,
as
josh
mentioned,
for
the
items
that
anyone's
working
on
this
will
also
become
available
for
self-managed
instances
as
well.
So
our
goal
is
to
move
this
to
beta
in
14.1.
D
Next
for
the
editor
team,
they're
focused
on
adoption
to
usability.
The
first
thing
is
introducing
a
markdown
preview
as
part
of
the
source
editor.
I'm
gonna
show
you
what
that
looks
like
great
video
attached
to
the
epic.
So
if
you
wanted
to
see
it,
you
can,
but
you
can
see
here
in
the
demo
they
right
clicked
and
it
brought
in
a
preview
view
right
alongside
the
editor.
D
It's
a
really
great
way
to
be
able
to
see
the
changes
you're
making
in
real
time
and
know
that
you're
applying
the
styles
that
you
would
like
and
then
finally,
for
the
editor
team,
they're
focused
on
supporting
inserting
images
into
the
content
editor.
This
will
bring
us
in
line
with
the
full
column
mark
spec,
more
details,
of
course,
are
here
on
the
issue.
D
If
you'd
like
to
read
more
about
it
and
then
finally,
for
the
getaly
team,
they're
focused
on
again
adoption
fusibility
as
well
as
scalability
we've
been
talking
about
the
rollout
of
repository
level
incremental
backups
over
the
last
couple.
Kickoff
calls.
This
is
coming
to
a
point
where
it'll
now
be
available
to
kind
of
highlight
it
for
you.
The
goal
here
is
to
address
the
common
issue
with
get
git
does
not
have
a
concept
of
incremental
backups.
D
This
is
leveraging
getaway
to
be
able
to
begin
to
offer
that
so
backups
can
run
faster
and
also
require
less
load.
I
would
also
like
to
highlight
this
is
our
incremental
approach
to
incremental
backups
and
that's
why
we'll
probably
continue
to
tell
you
about
it
over
the
next
couple,
kickoffs
and
then.
Finally,
this
kind
of
builds
up
something
josh
was
talking
about
regards
to
zero
to
geo
for
goodily
we're
working
on
I'll
call
it
lazily
selecting
the
primary
today.
D
If
you
fail
over
to
your
secondary,
you
can
now
begin
to
continue
to
do
your
reads.
The
effort
of
switching
back
over
to
the
primary
requires
bringing
everything
back
up
to
speed
with
rights.
D
This
could
have
a
lot
of
jarring
back
and
forth,
depending
on
the
stability
of
your
environment.
What
this
is
going
to
allow
us
to
do
is
to
switch
back
to
the
primary
for
rights
when
writes
start
to
happen
into
the
repository
again.
This
is
going
to
make
a
huge
performance
improvement
as
well
as
make
it
a
lot
easier
to
adopt
for
the
planned
stage
again
they're
working
a
lot
of
the
infradev
and
scalability
items.
The
one
item
to
highlight
that
is
new
is
supporting
multiple
iteration
cadences
within
a
milestone.
D
Today,
if
you
have
a
team
who
is
using
multiple
teams
using
the
same
project,
this
can
be
a
problem.
We
try
to
do
that
today,
separating
it
by
milestone.
However,
this
is
going
to
allow
multiple
teams
to
have
their
own
iteration
cadences
within
that
milestone.
This
is
gonna.
Allow
the
a
lot
of
the
automated
value
customers
find
with
our
planning,
including
auto
generation
of
things
like
release,
notes
based
off
the
close-up
items.
This
will
then
be
able
to
support
that
as
well
to
wrap
up
the
dev
section
with
the
manage
stage.
D
We
were
talked
a
lot
about
our
compliance
and
our
focus
on
improving
security
and
compliance.
A
part
of
this
is
the
push
for
new
event
types
as
part
of
our
effort.
This
quarter
here,
the
first
one
you're
seeing,
is
generating
an
audit
event
when
creating
or
deleting
ssh
keys
or
gpg
keys,
vrr
api.
This
will
now
show
up
in
that
traditional
audit
events
view
when
the
api
is
being
used
for
these
actions.
D
Next,
the
ability
to
also
generate
an
audit
event
when
compliance
frameworks
are
changed
on
the
project,
it's
a
great
way
to
catch,
whether
they
were
done
on
purpose
or
they've
done
accidental
and
be
able
to
have
that
traceability
understand.
Why
was
say
the
project
changed
from
pci
to
socks
or
whatever
that
change
was
on
the
compliance
framework
and
then
finally,
working
on
generated
event
when
the
new
users
added
as
an
instance
admin.
D
D
We
start
us
off
with
static
analysis,
they're
working
on
the
improving
of
the
vulnerability
tracking
we've
been
calling.
This
always
called
vulnerability
fingerprinting
as
well
as
tagger,
which
is
internal
code
name
with
it
coming
out,
we're
going
to
be
referring
as
that
vulnerability
tracking.
The
focus
will
be
attaching
it
to
additional
scanners.
The
initial
effort
was
focused
around
some
graph
and
symbol
coming
on
14.0,
but
as
we
move
forward
with
our
sem
graph
adoption,
as
well
as
keep
updating
our
existing
scanners,
we'll
be
attaching
our
new
formulae
tracking.
D
To
that,
the
dynamic
analysis
team
has
a
lot
of
really
great
updates.
David
heads
down
working
on
our
new
browser,
focused
crawler,
to
allow
us
to
support
single
page
apps,
that's
coming
out
in
beta
in
1312,
so
it's
out
today
so
now
they're
working
on
ui
configuration.
D
This
looks
a
lot
like
what
you've
been
seeing
for
on-demand
scanning
the
ability
to
create
scanner
profiles
and
site
profiles.
This
also
allows
you
now
to
attach
those
to
your
pipeline
runs
so
now.
Instead
of
having
to
have
independent
files
that
you're
trying
to
track
all
this,
you
can
actually
build
and
save
those
configurations.
As
part
of
your
ui
configuration
experience,
you
can
see
all
that
is
in
line
here,
allowing
you
to
save
it
as
well
as
select
an
existing
profile.
D
If
you
have
that
today
also
another
big
exciting
item
last
year
about
13
months
ago,
we
announced
we
had
acquired
peach
tech
as
part
of
our
posing
acquisitions.
One
of
the
products
that
pete
chad
was
api
security
scanner.
It
did
both
api
closing
as
well
as
dashed
api
functionality
with
14.1.
We
are
rolling
out
the
deprecation
of
zapper
deskt
api
and
we'll
be
using
the
peach
scanner
that
we
acquired.
This
is
a
huge
improvement,
not
only
just
on
the
usability,
but
on
the
findings
results.
D
We
are
finding
that
we'll
have
potentially
less
false
positives.
Now
that
we'll
be
using
the
das
api
engine
component
from
the
peach
acquisition
and
then
to
finish
up
with
our
threat
insights
team
we've
been
talking
about
the
ability
to
create
vulnerability
records.
A
lot
of
that's
been
around
the
api
with
14.1
we'll
begin
the
role
of
doing
this
within
the
ui,
and
so
here
you
can
see
on
the
screen.
D
If
you're
on
the
vulnerability
report,
there's
a
little
button
at
the
top
that
says
create
finding
when
you
do
that
same
fields
that
we're
populating
today
automatically
are
going
to
be
available
to
you,
including
the
name,
a
description,
the
severity,
what
they
say
that
is,
and
then
of
course,
any
evidence
you
have,
whether
that's
back
of
captures
log
files
and
so
forth.
I
know
that
vulnerability
will
look
like
any
other
vulnerability,
that's
coming
out
of
our
pipeline
scans
or
on-demand
scans.
This
would
be
big
for
you.
D
Also,
we've
talked
about
how
to
bulk
update
vulnerabilities
in
previous
kickoff
calls
we're
now
extending
that
to
include
the
ability
to
have
a
reason
for
that
change.
So
if
you
check
the
items
and
only
can
you
set
what
the
status
is,
whether
it's
confirmed
resolved
so
forth,
you
can
also
include
a
status
for
that
that'll,
be.
A
D
To
the
audit
event
for
that
vulnerability,
so
I'll
also
have
that
traceability
there
as
well,
and
then,
finally,
I
probably
should
told
you
all-
these
secure
ones
were
focused
on
adoption
through
usability
and
ast
leadership,
which
is
a
theme
that
both
manage
and
secure
support.
This
one
one's
focused
on
the
performance
and
scalability
this
you'll
not
necessarily
see
in
the
ui.
However,
hopefully
you
will
feel
the
impact
of
it.
D
Once
it's
rolled
out,
the
team
is
focused
on
moving
over
the
pipeline
security
report
over
to
use
graphql,
which
will
add
the
performance
you
now
see
when
we
moved
over
the
vulnerability
report
and
security
dashboards
over
to
wrap
this
up.
Before
I
hand
it
back
to
mcnoop
for
the
protect
stage,
they
are
focused
on
two
things
that
I
think
are
very
exciting.
In
14.0
comes
out
tomorrow,
our
new
default
container
scanner
will
be
trivi.
D
D
This
is
beginning
to
now
not
just
expose
desk
but
expose
other
scanners
via
the
ammo
configuration,
so
here's
a
screenshot
if
you're
inside
of
the
policy
editor,
you
can
select
your
scan
execution
policy
and
here's
an
example
of
das
being
in
there.
So
you
can
now
write
that
all
in
there
save
that
that
now
becomes
an
immutable
configuration.
D
So
if
someone
decides
that
they
want
to
remove
a
part
of
the
gitlab
ciemo
file
and
disable
a
certain
type
of
scam,
this
is
going
to
be
automatically
appending
that
scan
back
into
it.
It's
a
great
component
for
not
only
just
adoption
of
our
product,
but
also
giving
you
the
compliance
and
the
audibility
you
need
when
you're
releasing
software
in
different
regulated
industries.
A
Thank
you
david.
What
an
amazing
update
14
is
a
major
release,
but
14.1
is
also
packed
with
unbelievable
goodness.
I
heard
nested
variables
escalation
policies
for
incident
management,
including
manual
triggers
simplifying
jio
with
proxy
urls
and
single
command
promotions.
That's
great
that
great
for
admins
improving
sas
performance
by
reading
from
secondaries
and
upgrades
to
ruby
3.0.
That
will
be
amazing.
A
I
can't
wait
for
the
ga
release
of
the
gitlab
operator
for
openshift.
I
love
the
real-time
markdown
preview
for
the
source.
Editor.
That's
super
exciting,
faster
backups,
with
repo
level
incremental
capabilities,
better
performance
with
redirect
to
primary
on
right
for
a
repo,
better
compliance
with
new
audit
events
for
security,
keys,
immutable
security,
scan
execution
pipelines,
improved
tracking
accuracy
for
sas
unbelievable
content.
This
is
going
to
be
a
great
release.
We'll
see
you
again
next
month,
bye.