►
From YouTube: Monthly CI/CD Product & Engineering Q&A
Description
A
So
thanks
everybody
for
coming
to
the
cicd
strategy
review,
which
we
do
monthly
and
is
a
good
chance
for
engineers
or
anybody
to
come
and
ask
questions
about.
What's
on
the
roadmap
page,
there
haven't
been
a
ton
of
roadmap
updates
that
are
major.
Obviously,
the
categories
are
updated
all
the
time,
but
for
the
big
vision
for
ci
cd,
no
real
changes
now
next
week,
we'll
do
a
review
of
the
content.
That's
there
with
the
e-group.
So
there
may
be
some
interesting
changes
that
come
out
of
that.
A
Otherwise,
it's
it's
pretty
much
the
same
as
last
month
and
we're
still
just
executing
on
on
that
same
plan,
yeah,
the
the
the
the
big
things
that
have
been
going
on.
I
suppose
that
I've
observed
is
it's
been
interesting
to
follow
along
the
teams
that
are
using
kanban
and
how
that's
working-
and
it
seems
like
there's
some
really
interesting
progress
there.
A
C
Thanks
jason
and
thanks
for
doing
these,
I
really
do
appreciate
you
doing
this
sort
of
walkthrough.
It
helps
me
take
a
moment
and
thank
him
in
a
bigger
picture,
so
yeah.
The
first
question
I
have
forgive
for
the
container
registry
maturity
plan
on
the
site.
It's
currently
linked
to
the
old,
get
lab
fuss
issue
for
camille
that
he
created
and
that's
been
moved
over
to
the
new
project.
So
I
was
thinking
either
change
it
to
the
the
newer
link,
which
is
the
one
I
linked
under
camille's
issue
or
the
epic.
E
C
A
No,
that's
fine.
Yeah
costs
in
general
seem
to
be
coming
up
more
with
infrastructure
and
not
just
on
the
package
registry,
but
on
like
free,
ci,
cd
minutes
and
other
kinds
of
discussions
that
we're
having
and
how
are
we
effectively
managing
the
costs
of
our
infrastructure
as
we
acquire
customers
and
introduce
people
to
get
everything?
It's
a
very
big
topic
that
there's
a
bunch
of
threads
going
on
to
speak
to
your
specific
item.
Yeah.
A
A
If
there
is
a
specific
item
that
sort
of
needs
people
to
swarm
on
it,
we
can
potentially
do
a.
What
do
we
call
it?
It's
like
something
like
a
global,
optimization
process
or
something
there's
something
to
find
where
we
can
potentially
bring
in
people
to
help,
if
there's
a
specific
kind
of
short-term
deliverable
that
we
need
to
to
do
so,
that's
an
option
but
yeah,
I
don't
know
tim.
Where
is
this
fitting
in
the
priority,
and
can
you
maybe
expand
on
that
a
bit.
D
Yeah,
I
feel
good
about
how
we're
prioritizing
things
I
think
we're
making
good
progress.
I
don't
feel
good
about
how
much
it's
currently
costing
a
gitlab,
but
I
feel
like
we.
What
we've
done
so
far
is
we've
prioritized
the
optimization
work
for
how
garbage
collection
is
run
for
the
different
object
storage
systems
in
order
to
unblock
a
lot
of
our
enterprise
customers.
But
this
work
was
required
anyway,
because
it
really
gave
the
product
developers
the
chance
to
see
understand.
D
What's
going
on
in
the
code
base,
build
out
performance
and
benchmarking
tests
we're
implementing
optimizations
now
for
google
cloud
storage,
so
that
is
informing
how
we
will
architect
and
design
a
solution
for
online
garbage
collection,
which
will
enable
us
to
actually
lower
the
cost
for
gitlab.com.
So
it's
a
long
path
there,
but
when
you're
dealing
with
problems
of
scale
where
there's
several
petabytes
and
there's
also
this
problem
of
how
do
we
migrate
from
the
existing
registry
into
the
new
one?
D
C
C
C
A
Yeah,
I
mean,
I
think
you
know
I've
shared
the
the
priorities
for
within
the
cicd
section,
and
I
think
that
those
are
still
being
kind
of
mapped
to
and
everything
the
discussions
are
largely
happening
at
a
different
level
than
me
now
and
it's
like
with
the
board.
It's
with
the
e-group
and
trade-offs
are
being
made
for
the
whole
company.
I
don't
know
how
much
more
it's
going
to
change
or
or
when
we'll
get
the
final
word,
but
I
do
feel
like
the
priorities
for
ci
cd
have
been
well
represented
in
that
process.
A
C
D
D
On
the
the
container
registry
front
and
lowering
the
cost
of
storage,
we
launched
the
nbc
of
docker
expiration
policies
which
will
allow
our
users
to
programmatically
delete
images
using
set-by-setting
policies,
so
I'm
really
excited
for
that.
It's
currently
limited
to
only
new
projects,
but
we
have
a
plan
for
rolling
it
out
to
existing
projects.
Over
time,
we've
also
been
just
improving
the
package
registry.
We
added
npm
tags.
We
added
additional
meta,
the
build
metadata
to
the
user
interface.
D
So
now
you
can
see
which
pipeline
which
job
which
commit
and
branch
are
responsible
for
generating
a
specific
package.
So
this
site
is
really
a
first
step
in
tying
together.
Cicd
and
package
features
a
little
bit
tighter
and
then
just
some
things
that
we're
starting
to
think
about
now,
as
we
head
into
1210
and
beyond.
I
really
want
to
start
thinking
about
right
now.
We
have
basically
the
concept
of
local
repositories,
so
you
can
set
up
a
private
nuget
repository,
for
instance.
D
If
it's
the
package
is
not
available
in
on
git
lab
and
then
having
a
virtual
repository,
which
is
basically
a
combination
of
those
two
things
where
the
dependencies
are
all
cached,
so
you
could
think
of
it
as
your
locals,
your
private
repository,
the
remote
is
the
public
version
and
then
the
virtuals,
the
dependency
proxy
caching.
Those
packages
we're
also
really
making
some
changes.
This
milestone
and
next
milestone
on
updating
deploy.
Tokens
is
a
very
common
issue
here
from
customers.
D
The
first
thing
that
we're
doing
is
that
is
allowing
updates
to
happen
using
the
api,
so
we
can
make
changes
across
multiple
projects
and
groups
and
then
in
the
next
milestone,
we'll
work
on
expanding
the
scopes
to
include
write
registry
right
container
registry
and
write
package
registry,
which
are
big
things
that
we
hear
from
customers
consistently
and
then
also
really
exciting.
To
see
some
of
the
work
that
the
front
end
team
and
the
design
team
is
doing
to
overhaul
the
container
registry
package
registry
and
dependency
proxy
front
end.
E
Thank
you,
tim
sounds
really
cool.
I'm
really
interested
to
see
how
that
how
that
works
with
the
virtual
option
sounds
really
interesting.
So
we're
going
to
start
with
my
favorite
topic,
merge
trains.
So
at
the
moment
it
is
currently
disabled
on
about
about
lab.
It
has
been
so
for
the
entire
milestone,
because
we
found
two
critical
bugs
that
we
wanted
to
solve.
E
Those
were
solved
in
addition
to
another
request
that
we
had
for
dog
fooding,
which
will
notify
and
slack
what's
going
on
with
your
train.
So
those
are
all
done.
The
last,
mr,
is
in
review,
and
once
it's
done
we're
going
to
re-enable
it
on
about
gitlab.
So
really
good
news
resource
groups
was
delivered
in
the
previous
milestone,
which
allows
you
to
limit
the
concurrency
of
jobs
and
pipelines
to
make
sure
that
you're
not
destroying
your
whatever
you're,
deploying
to
let's
say
a
physical
device.
E
If
you
deploy
more
than
one
more
than
once
simultaneously,
that
was
like
it
had
like
400
of
those
that
issue,
so
we're
really
happy
that
it
made
it
and
it
got
out
continuing
tim's
point
with
group
deploy
token.
So
that's
almost
done
it
will.
It
didn't
make
12.8,
but
it
will
probably
be
finished
early
on
next
week
and
this
actually
introduces
a
new
setting
to
allow
group
deploy
tokens
that
can
be
shared
between
projects
in
the
same
group.
E
So
any
project,
that's
in
that
group
will
inherit
tokens.
So
it's
also
like
one
of
the
top
most
popular
issues
and
I'm
happy
to
see
that
we're
making
progress
with
that
next
up
in
12.9.
We
have
two
main
focuses.
One
is
the
truly
dynamic
urls
another
high
priority
issue
for
review
apps.
So
it's
actually
a
really
cool
feature.
E
It
allows
you
to
pass
the
environment
name
to
the
job
itself,
so
it's
a
slick
solution
that
can
probably
be
used
not
only
for
review
us,
but
also
for
other
use
cases
where
we
need
to
pass
things
between
jobs,
so
really
really
cool
feature
and
lots
of
work
on
refactoring
feature
flags.
We
found
out
that
we
had
limitations
to
our
current
implementation,
so
we're
working
on
fixing
them
so
it'll
be
a
flexible
and
scalable
solution.
G
The
team
is
forming,
but
given
the
engineers
are
to
be
hired
for
the
templates
group,
I
will
be
coordinating
with
pms
and
existing
teams
to
deliver
a
few
key
issues
on
the
upcoming
milestone,
probably
getting
some
help
from
the
ci
team
and
then
also
coming
is
the
theme
strategy
page
for
city
onboarding.
We
want
to
make
that
easier
and
to
address
barriers
for
adopting
gitlab
ci.
G
There
is
a
placeholder
page
up
there
now,
where
I'll
be
adding
the
content,
the
strategy
of
what
we
want
to
achieve
and
what's
next
going
back
to
the
direction
page
for
templates.
If
you
go
and
take
a
look
at
it,
you'll
see
that
for
what's
next
and
why
I'm
going
to
try
to
target
introducing
two
new
templates
for
the
issues
are
separate
for
kubeflow
and
for
pi
torch
to
address
the
machine.
G
Learning
ai
pipeline
needs
to
make
them
easier
and
and
then
going
back
and
fixing
our
existing
templates
that
either
has
some
bugs
with
them
or
some
issues
or
making
enhancements.
That
would
make
them
easier
for
our
users
to
adopt
and
then
finally,
a
couple
of
issues
listed
under
top
customer
issues.
I
actually
want
to
circle
back
with
our
sales
team
and
our
solution,
architect,
team,
to
figure
out
if
I
actually
have
the
right
ones
identified
there.
G
Those
were
based
on
the
ones
that
did
have
some
upvotes
and
conversations,
and
it
has
come
up
in
one
of
the
customer
meetings.
I
was
in
recently
that
being
able
to
parameterize
parameterize
project
templates
would
be
very
useful
right
now,
when
you
use
a
project
template
the
ci
variables
are
not
copied
over,
so
it
is
kind
of
tedious
for
them
to
go
back
and
replace
or
add
in
all
the
places
in
the
template
that
should
have
some
custom
ci
variables.
F
All
right,
so
I
just
wanted
to
share
that
with
12
8
we'll
be
releasing
the
first
step
into
accessibility
testing.
So
it's
the
very
first
feature
in
that
category:
we're
leveraging
review
apps
to
scan
the
review
app
and
provide
an
accessibility
report.
So
I'm
really
excited
about
that.
In
kicking
off
that
category,
it
should
be
really
helpful
for
folks,
as
they
start
to
do
more
accessibility
testing
earlier
in
the
software
development
life
cycle
and
then
the
direction
items
that
the
team
is
working
on.
F
One
graphing
code
coverage
that
I
think
jason
mentioned
in
the
kickoff,
probably
two
or
three
kickoffs
ago
now-
is
really
being
worked
on
in
earnest.
The
other
one,
the
full
code
quality
report,
taking
that
open
source
report
that
we're
generating
and
using
to
create
the
merge
request,
diff
view
or
the
merge
request,
widget
we're
going
to
be
displaying
that
in
the
full
gui.
F
That's
a
pattern
that
we're
starting
to
replicate
with
some
of
the
other
reports
that
are
generated
from
testing
data
or
testing
jobs
and
then
we're
looking
to
then
leverage
that
in
future
releases
or
add
value
to
that.
So
we're
not
just
giving
you
another
view
of
something
you
can
download,
but
actually
making
that
a
lot
more
usable
within
gitlab,
it's
kind
of
the
vision
for
the
broader
testing
categories.
F
So
while
these
issues
have
been
taking
a
while
to
get
through,
it's
been
a
real
great
learning
experience
for
the
team
and
figuring
out.
How
do
we
break
down
these
really
massive
issues
into
a
couple
of
different
merge
requests?
How
do
we
assign
the
right
docs
merge,
requests
to
the
right
issue
to
know
that
everything
is
releasing
at
the
right
time
so
that
daniel
and
elliot-
and
I
are
not
in
a
constant
group-
chat
throughout
the
day
for
the
release
post
day,
making
sure
we
know
what
is
releasing
when
so.
B
Hey
everyone,
I'm
darren
here,
hey
so
yeah,
just
kind
of
like
chatting
with
you
guys
and
sharing
some
of
the
inside
baseball
that
I
was
trying
to
reflect
back
a
bit
and
realizing
that
the
runner
team.
You
know
unless
you're
saying
you
know,
engineering
meetings,
you're,
probably
not
very
privy
to
our
like
our
signs
and
what's
actually
happening.
So
let
me
just
kind
of
step
back
for
a
bit
as
we
as
a
runner
team
plans,
each
release.
We
are
consciously
trying
to
make
sure
we
include
in
each
release.
B
You
know
like
priority
p2,
bugs
that
have
been
sitting
around
for
a
while
right,
so
you
want
to
get
through
a
backup
of
those
bugs
so
you'll
see
each
release
that
we're
investing
and
trying
to
reducing
those
bugs.
Then,
in
addition
to
that,
you
also
see
us
invested
in
what
I
would
call
very
very
well
how
high
features
are
in
high
demand
on
the
user
community
right.
B
So
they
may
not
be
necessarily
big
features
that
move
the
neither
in
terms
of
a
big
strategy
but
they're
important
to
the
user
community,
so
we're
investing
in
those
as
well.
So
we
have
to
balance
those
investment
needs
with
this
broader
strategy.
That's
been
described
here
in
above,
so
let
me
talk
a
little
bit
about
the
broader
strategy
and
stuff
was
happening
in
the
dark
for
a
moment.
B
B
Ga
we're
also
working
on
new
pricing
structure
model
updates
for
the
runners
right
so
because
we
need
now
to
be
able
to
offer
customers
hey
you're
using
mac,
os
shared
runners
on
github.com
or
you
may
be
using
windows
or
sharedruns
and
get.com
your
different
cost
models
and
pricing
structures,
and
so
we're
working
on
that
once
that
pricing
structure
stuff
is
sorted
out
and
we
hope
to
to
land
that
here
in
the
next
few
weeks,
then
we'll
be
pivoting
to
say.
Okay,
we've
got
the
pricing
worked
out.
B
Oh,
we
can
now
offer
premium
machine
types
for
those
folks
that
need
bigger
machine
types
for
the
linux
or
windows
shared
runners
on
gitlab.com.
Maybe
you
need
a
gpu
enabled
machine,
so
we
need
to
add
those
details
to
the
issue,
so
we're
looking
to
roll
that
out.
So,
let's
recap
we're
going
to
make
sure
the
limits
are.
B
Then
we're
going
to
say:
okay,
let's
start
extending
the
use
of
this
auto
scaling
capabilities
to
aws,
gcp
and
azure
for
those
self-managed
customers
that
are
today
managing
their
own
fleet
of
gitlab
runners
and
the
reason
is:
we've
got
to
eventually
replace
the
current
ducting
machine,
auto
scaler.
That's
the
technology
we're
using
today
to
manage
those
streaks
of
of
runners
and
because
that
machine,
auto
scaler
is
dedicated.
So
that's
kind
of
the
high
level
kind
of
how
we're
trying
to
how
shall
I
say,
manage
the
various
moving
parts.