►
Description
Chad and Jean review the epic dealing with reducing the www-gitlab-com repo size and what our immediate next steps should be.
A
Hello,
everybody.
This
is
the
static
site,
editor
issue,
the
finance
session,
and
today
we're
going
to
look
at
this
epic
of
reducing
the
gettler
dubbed
getting
calm,
repo
specifically
the
size.
So
this
is
something
that
I've
picked
up
quite
a
while
ago.
Already
that
you
know
the
science
is
getting
quite
large
over
six
gigabytes
in
size,
and
this
is
impacting
things
like
pipeline
speed
and
various
other
challenges
with
regards
to
cloning,
the
repo
and
the
amount
of
times
that
happens
with
all
the
changes
to
it.
A
So
you
might
wonder
why
go
the
monorepo
route
if
we
plan
to
go
to
a
separate
reaper,
initially
80s
and
the
monorepo
was
always
an
interim
kind
of
like
state
and
the
primary
reason
for
that
was
to
help
drive
the
decoupling
of
the
marketing
in
the
handbook
sites
which
we
have
achieved
to
a
large
degree.
We
still
have
coupling
with
shaped
templates
and
partials
and
acids
which
we
plan
to
to
work
on
the
next
few
months,
but
so,
in
the
context
of
that,
when
will
we
move
to
a
separate
repo?
A
I
can't
say
I
I
don't
think
it'll
be
in
the
next
three
months,
maybe
towards
the
end
of
the
year.
So
that's
just
the
context
that
we
need
to
keep
in
mind
as
we
kind
of
go
through
this
epic
and
the
related
issues
and
see
kind
of
like
what
is
still
relevant.
What
are
what
is?
Are
they
some
new
things
that
we
know
about
that?
We
can
tackle
and
yeah.
So
let's
get
into
this,
so
I
think,
let's
quickly
see
what
comments
on
you.
B
So
for
for
shallow
clones.
I
think
that
helps,
but,
as
we
know,
the
the
overall
size
of
the
repo
is
still
large
so
for
for
fresh
local
clones
as
well,
as
I
think,
some
load
on
the
giddily
backend.
The
the
overall
size
of
the
historical
repo
has
some
impact.
It's
not
clear
what
and
also
there
may
be
some
other
large
images
that
weren't
under
team
or
team
pets
that
might
still
be
able
to
be
reduced,
large
images
or
files,
and
so
those
are.
A
B
A
B
Ways
those
that
one
and
the
other
last
three
in
the
epic
are,
in
my
mind,
they're
they're,
all
related
they're
sort
of
the
same
thing
like
giving
large
blobs
out
of
the
repo
right,
the
workflow
for
uploading
assets.
That's
like
preventing
new
images
getting
in
moving
stuff
to
cloud
storage
like
they're,
the
same
thing,
different
categories
of
stuff.
B
A
B
Also
just
realize
that,
with
the
with
the
change
to
the
change
log
being
merged
yesterday,
we
should
be
able
to
reduce
the
maximum
file
size
back
to
two.
So
I'm
doing
that
right
now,
oh
great
so
between
that
was
one
thing
just
to
stop
the
bleeding
so
to
speak,
and
it
will
prevent
other
big
things
from
getting
added,
there's
still
a
small
creep
of
up
to
two
meg
files,
getting
added
in
images
and
stuff,
and
so
stepping
back
from
this
whole
topic.
B
B
B
No
at
that
point
I
would
I
would
do
it
as
not
a
clean
repo,
but
the
result
of
doing
a
filter
branch
of
throwing
away
everything
we
don't
want.
So
we
still
have
the
history
of
everything
that's
left,
but
everything
that
we
don't
care
about
is
is
gone.
Okay,
so,
like
all
of
the
handbook
files
and
the
actual
source
files
and
whatever
templates
and
stuff
we
bring
along
the
history
should
be
there
mostly
and
all
of
the
stuff
that
we
don't
even
that
we
didn't
care
about
and
bring
with
us
will
be
gone.
A
A
To
I
don't
want
to,
I
don't
want
to
comment
about
the
the
separate
reaper
until
so
this
might
actually
be
worth
covering
quickly,
so
the
the
next
six,
let's
call
it
six
to
12
months.
The
the
journey
for
for
the
handbook
will
likely
looks
or
I'm
gonna
propose
that
it
looks
something
like
this.
Q3
will
see
us
have
clean,
total
decoupling
of
from
the
marketing
site,
so
no
shade
assets
or
templates
with
marketing.
A
It
will
also
see
us
migrating
to
frontman.
Q4
will
likely
see
us
starting
to
to
experiment,
maybe
with
a
you
know,
like
a
mirrored
repo
of
the
of
the
handbook
to
and
and
setting
that
up
on,
gitlab
pages
and
and
also
then,
you
know
playing
with
cdns
and
so
on
and
getting
data.
So
I
had
a
conversation
with
with
infrastructure
yesterday
about
you
know:
what
can
they
do
to
help
us?
A
You
know
long
term,
you
know
have
better
control
of
these
sort
of
new
because
they
they're
kind
of
like
resource
constrained.
In
terms
of
you
know
the
team
they
have
to
take
care
of
gitlin.com
and
and
well
they're,
more
than
happy
to
help
set
up
the
cdn
and
all
the
all
the
so
and
then
give
us
the
necessary
training
for
us
to
essentially
maintain
it
ourselves
going
forward.
A
So
that's
that's
something
that
that
will
come
back
so
q4
will
likely
be
something
along
the
lines
of
starting
to
like
do
a
proof
of
concept
of
posting.
The
handbook
on
getting
our
pages
so
that
that
will
and
then
probably
in
q1
next
year,
is
when
we
can.
If,
if
we
can
sort
out
the
you
know
the
challenges
and
and
proof
that
everything
works
in
our
state
is
stable
and
so
on,
we
can
then
likely
move
the
handbook.
B
This
issue,
what
we
can
say
without
mentioning
any
of
that
like,
let's
just
approach
it
to
say,
we
need
to
gather
metrics
of
whether
this
would
even
help
given
that
we
do
a
shallow
clone.
I
think
the
answer
is
no,
but
I'm
not
100
sure
and
then
the
other
if
it
will
help
the
ci
performance
right.
There's
three
things:
there's
like
the
ci
build
speed
tax
to
clone
the
repo
there's
fresh
clones
locally,
which
are
a
pain
but
infrequent,
and
then
there's
whatever
load,
we're
putting
on
the
giddily
back
end
right.
B
A
B
A
A
A
A
I'm
not
sure,
given
the
current
context,
whether
it
makes
sense
to
try
and
rewrite
the
replay
history
for
file
silence
reduction
purposes
in
the
ci
pipelines,
we
do
a
shout
out
kind
of
lasting
and,
as
such,
then
pull
the
whole
repo
down.
We
are
not
certain
about
what
we
are
not
certain
about
is
what
the
impact,
what
is,
what
impact
the
overall,
largely
precise
one,
have
in
other
areas
of
the
gitlab
ecosystem,
given
yeah.
B
B
A
B
A
I
also,
I
also
think
it
doesn't
really
matter
in
that
we,
this
is
something
we
should
be
doing.
There's
no
reason
to
keep
those
reviewer
environments
around
so
with
whether
it
has
a
positive
performance
impact.
It
is
written
like
this.
This
is
one
of
those
clean
up
things
that
we
should
probably
just
do.
According
to
james
ramsey,
it
does
have
an
impact,
at
least
in
terms
of
the
you
know,
the
way
the
refs
are
resolved
and
all
of
those
things,
and
it
can
have
an
impact
on
on
various
things.
A
A
Now
we
get
to
so
this,
for
me,
is
a
is
a
bigger
one,
and
this
is
where
I'm,
where
I'm
a
little
kind
of
like
conflicted,
whether
we
should
do
something
in
the
short
term
and
the
two
reasons
for
that
is
we're
likely
gonna,
be
introducing
some
sort
of
functionality
in
the
static
site.
Editor
at
at
some
point
around.
A
You
know
specifying
your
remote
or
external
cloud,
the
storage
in
point
for
for
image,
uploads
and
also,
if
the,
if
the,
if
we
are
moving
to
a
separate
repo,
we're
not
gonna,
have
you
know,
there's
not
that
many
assets
in
the
handbook.
Do
we
want
to
have
an
an
external
thing?
Yes,
definitely,
but
I'm
wondering
I'm
wondering
how
much
like
this
is
not
a
small
initiative.
That's
a
there's,
a
lot
of
effort
in
those
three
issues,
and
I'm
wondering
whether
it's
worth
trying
to
tackle
that
in
the
next
few
months.
B
B
What
are
the
options
and
figure
out
the
optimal
way
to
approach
this
problem,
and
then,
whenever
we
do
for
the
static
site
editor
we
just
back
port
to
whatever
is
currently
there,
but
that
they're
already
in
there,
and
only
through
doing
the
filter
branch,
which
we
said
we
want
to
avoid.
Are
we
going
to
help
them
yeah?
You
know
it
may
make
the
the
the
current
clone
size,
the
shallow
clone
size
smaller,
but,
like
we
said,
that's
not
that
big
of
a
deal.