►
From YouTube: 2022 05 26 Git Cache Maintenance
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
Welcome
this
is
the
get
cash
maintenance
project.
It's
may
the
27th
2022
topics
for
today.
So
hushakesh
are
there
questions
that
you
have
that
we
want
to
be
sure
we
address
what
topics
are
of
concern
for
you.
B
B
A
Yes,
async
inside
the
jenkin
in
the
jenkins
controller
running
a
separate
process.
B
I
was
thinking
of
you
know
a
queue
you
know
so
that
I
put
the
tasks
into
the
queue
and
then
you
use
another
thread
to
you
know:
dequeue
everything
from
that
queue
to
run
run
the
maintenance
tasks.
A
And
I
think
I
think
that
makes
sense,
and
I
believe
that
there
is
a
concept
of
cueing
inside
jenkins
that
you
can
use
so
use
a
queue
to
and
the
concept
there
would
be
to
keep
basically
a
relatively
few
maintenance
tasks
running
concurrently.
So
we
don't
want
to
overwhelm
the
thing
with
too
many
maintenance
tasks.
B
Basically,
I
think
a
maximum
of
five
million
five
you
know
get
maintenance
starts,
will
be
put
if
all
of
them
are
set
at
the
same
time,
you
know.
A
C
So
I
have
a
question
here:
we
want
to
use
a
queue
as
far
as
I
understand,
cues
are
used
when
you
want
to
decouple
two
concepts.
C
So
since
we
know
that
these
tasks
that
we're
running
are
going
to
be
scheduled
at
some
frequency
that
we've
configured
ourselves
is
there
a
way?
Is
there
a
reason
or
is
there
a
possibility
that
our
initial,
let's
say
the
first
job
or
process
hasn't
finished,
and
there
would
be
other
processes
that
have
started
happening,
and
that
is
why
we
need
something
like
a
queue
to
make
sure
that
that
doesn't
happen
and.
C
B
Oh,
I
I
thought
of
a
queue
because
you
know
we
have
discussed
in
the
meet.
You
know
that
we
want
to
run
the
maintenance
task,
sequentially,
okay,
so
assume
assume
a
cube
which
has
like
five
or
two
two
or
three
maintenance
stuff.
You
know
like
a
prefetch,
you
know
and
a
comet
graph
and
a
gc
for
example,
okay.
B
So
whenever
the
I
I
check
whether
the
queue
is
empty
or
not,
if
the
queue
isn't
empty,
I'd
remove
the
for
I
dequeue
the
first
element,
and
then
I
run
all
the
maintenance
tasks
you
know,
although
you
know,
I
run
that
maintenance
task
on
all
the
get
caches
and
then
after
that
finishes,
then
I
continue
for
the
you
know
next
maintenance
task,
but
this
thing
happens
only
when
all
the
maintenance
starts
were
scheduled
at
the
same
time,
like
you
know,
same
ground
schedule
like
every
minute
or
every
hour
that
time
only
this
this
case
happens.
B
Otherwise,
if
it's
for
different
chron
syntax.
That
time,
I
think
only
one
maintenance
task
would
be
pushed
into
the
queue.
C
Still,
my
question
is
that,
like
mark
has
written,
we
want
to
do
control
resource
consumption
right.
So
if
we
were
not
sure
what
would
be
the
amount
of
time
a
process
takes,
or
we
are
not
sure
about
the
incoming
processes
that
are
going
to
come.
While
my
existing
process
is
running
on
the
controller,
then
we
would
want
to
use
a
user
queue
which
would
make
sure
that
we
don't
overload
the
controller.
C
Let's
say
I,
I
push
a
million
messages
within
a
second,
so
you
you
need
a
queue
or
something
like
that
to
not
overload
your
system,
but
when
you
know
that
the
processes
that
are
going
to
run
are
going
to
run
in
as
finite
time-
and
you
yourself
are
the
originator
of
the
next
set
of
tasks
that
are
going
to
come
there.
Then,
why
would
you
need
something
like
that?.
A
Well,
but
but
you
made
an
assertion
there,
richard
that,
I
think
I
think
is-
is
not
precise
right
in
that
the
maintenance
tasks
we
actually
don't
know
their
duration,
get
gc
of
the
linux
kernel
could
be
minutes
and
in
fact
it
could
be
much
longer
than
that
if
the
computer
is
under
memory,
pressure
or
relatively
lower
performance
and
and
whereas
fetch
of
most
repositories
is
seconds
or
take
the
other.
The
other
end
fetch
of
the
linux
kernel
over
a
slow
link
could
be
an
hour
or
more.
C
A
B
B
You
know
get
me
get
cashes
when
I
do
that,
okay
and
assume
there's
another
maintenance
task
which
is
scheduled
hourly
okay,
so
you
know-
and
if
this
gc
task
and
another
maintenance
task
like
a
preset
both
have
been
set
at
the
same
time,
so
two
maintenance
tasks
would
enter
the
queue
and
assume
the
g.
Garbage
collection
is
takes
another
one
hour:
okay,
if
it.
B
If
there
are
too
many
repositories
on
the
kit,
jenkins
controller,
then
more
tasks
would
be
added
to
the
maintenance
to
the
queue
and
the
previous
maintenance
tasks
also
wouldn't
have
been
executed.
I
think
that
would
be
a
duplication
of
maintenance
tasks
on
the
queue.
A
B
Yeah
yeah
we
wouldn't,
but
assuming
60
minutes,
has
finished
and
you
know
again
the
crown
syntax
executes
for
you
know
after
60
minutes,
because
we
said
you
we
set
prefetch,
so
there
would
be
two
prefetches
in
the
queue
or
you
know
another
comment
graph
in
the
queue
which
would
you
know
there
would
be
a
duplication
of
two
tasks
in
the
queue.
What
I
was
telling
you.
A
I
see
what
you're
saying
okay
right,
so
so
you're
you're
concerned
okay.
So
how
do
we?
So?
I
guess
the
question
there
is:
do
we
need
to
handle
duplication,
duplicates
that
arrive
in
the
cube
that
are
are
in
the
queue,
so
should
the
queue
as
now
I
now
I
have
to
make
a
match
to
my
jenkins
job
experience
so
at
jenkins,
job,
a
jenkins,
freestyle
job,
let's
be
very
precise,
jenkins
freestyle
job
with
its
parameters,
a
cued
jenkins,
freestyle
job
with
its
parameters
will
be
replaced.
A
If
a
new
job,
a
new,
a
q
jenkins
bill,
build
this
correct
word
if
a
new
build
is
scheduled
with
the
same
parameters,
so
this
is
the
way
that
the
jenkins
freestyle
job
handles
the
duplication
problem
you
were
just
describing
and-
and
so
I
think
mentally
are
you?
Are
you
suggesting
we
may
want
to
allow
that
in
the
queue?
B
C
C
I
I
was
thinking
that
we
would
have
a
way
to
identify
a
particular
job
or
a
process
using
a
unique
identifier,
and
we
that
would
be
calculated
based
on
the
parameters
that
we've
defined
for
a
particular
process.
A
A
B
B
It's
fine,
but
I
have
a
doubt.
Is
there
any
way
of
getting?
You
know
the
the
path
of
all
the
caches
on
the
jenkins
controller.
A
Yes,
there
is
yeah,
so
so
is
there
a
way,
so
is
there
a
at
least
I'm
pretty
sure
there
is
because
to
list
all
the
caches
on
the
controller?
A
A
Because
or
what
maybe
yeah
it
was
last
year's
project,
wasn't
it
that
we
had
an
scm
cache
on
the
controller
that
we
were
relying
on
as
a
way
to
answer
size
questions?
Oh
yes,
yes,
hang
on
now.
I
think
we
can
find
it
just
a
minute.
You've
prompted
me.
A
And
the
size,
where
is
okay,
size
of
repo,
so
here
we
go
so
there's
a
repository
size,
cache
and
that
size
cache.
If
I
remember
right
knows
how
to
look
inside
yes,
here
it
is
abstract,
get
scm
source
dot
get
cache
entry,
so
there
is
inside
the
get
plugin.
This
get
cache
entry
method
that
for
a
given
repository,
url
or
here
getcashdur,
I
think,
is
the
one
we
want
right,
the
the
directory.
We
want
the
folder
on
the
file
system
that
contains
the
cache,
and
here
it
is
so
abstractgitscmsource.getcashter
will
for
a
given
repo.
A
A
A
A
A
B
A
Okay,
so
abstract
get
sem
source,
find
the
caches,
find
a
cache
or
a
repository
abstract,
yet
scm
source.
A
A
C
A
Now
you
may
say:
oh,
but
I'm
not
sure
I've
got
that
a
caches
directory,
and
if,
if
you
find
that
you
don't
have
a
caches
directory,
that
may
mean
that
you
haven't
run
a
pipeline
yet
or
haven't
run
a
multi-branch
pipeline.
If
it
would
help
you,
you
are
welcome
to
use
a
toy
environment
that
I
maintain
as
a
docker
image.
A
It's
so
it
requires
docker
container,
but
it
what
it
does
is
gives
you
a
it's
a
jenkins
controller
with
mem
with
several
interesting
jobs.
A
A
C
A
A
C
A
A
C
Okay,
I
have
this
and
the
question
that
I
have
related
to
this,
which
I
think,
if
you've
answered
already
or
not,
is
that
the
way
I
see
it
the
this
work
or
this
handling
these
processes
is
that
this
is
above
the
layer
of
a
particular
job
or
a
pipeline.
C
So
when
I
was
working
in
the
git
plugin,
I
remember
that
I
always
had
this
concept
that
I'm
going
to
get
a
job
which
could
be
a
freestyle
could
be
a
pipeline,
and
then
I
have
to
do
some
work
on
it
and
give
my
results
whatever.
That
is
the
function
that
I
had
to
write
and
that
was
the
environment
or
context
which
I
was
working
under
with
rishikesh
works.
What
I
understand
is
we
need
to
go
above
that
layer
right.
C
We
need
to
go
above
that,
because
we
are
actually
sitting
at
the
sitting
at
the
place
where
we
decide
when
and
where
the
control
the
jobs
are
going
to
run
or
whoever
is
publishing
these
jobs.
So
does
that
come
so
now?
My
question
is:
I'm
sorry
that
I
it's
a
long-winded
question
is
that
is
this
within
the
purview
of
the
git
plugin?
C
A
Good
question,
and
since
since
the
git
plug-in
has
things
that
it
configures
at
a
global
level,
I
think
it's
safe
for
this
to
be
inside
the
git
plug-in,
but
but
for
me
it's
there.
There
are
things
that
the
git
plug-in
configures
globally,
and
this
will
be
effectively
another
significant,
large
and
interesting
global
configuration
where
yes,
maintenance
tasks
should
never
be
more
than
this.
Many
in
the
this
many
running
concurrently,
yes,
maintenance
tasks
should
prefer
to
start
sunday
morning
or
things
like
that.
A
B
But
you
know
all
the
there
were.
There
was
some
other
problems
which
I
was
thinking
about.
Like
you
know,
when
we
are
scheduling
the
task,
there
are
trons
and
taxes
where
you
can
run
the
maintenance
task
every
minute.
Okay,
like
there's
a
taxes
left,
I
was
thinking.
Can
we
prevent
users
from
running
maintenance
tasks
like
that?
No,
there
should
be
like
a
base.
B
Syntax,
like
you,
can
start
a
running
task
only
hourly,
and
then
you
know
start
from
hourly
only
you
can't
run
any
maintenance
tasks
below
one
number,
like
you
know,
every
30
minutes
or
every
15
minutes
or
every
5
minutes
the
minimum
base
you
know
focusing
tax
for
cron
should
be
starting
hourly.
You
know
so
that's
established.
A
A
A
Because
if
they're
all
the
linux
kernel
or
they're
all
variants
of
some
large
repository,
it
could
just
be
a
long
time.
So
so
isn't
this
safeguard
that
you're
suggesting?
Should
we
have
that
we've
got
to
have
that
form
of
safeguard
somehow
without
making
it
time-based,
but
rather
making
it
don't
overload
the
jenkins
controller.
B
But
here
scheduled,
ten
thousand,
are
you
know,
maintenance
which
are
written
here?
All
of
them
will
be
happening,
sequentially
right.
A
They
will
that's.
At
least
that
was
my
assumption.
My
assumption
is
because
we're
we
cue
them,
they
will
be
sequential,
so
it
shouldn't
overload
the
controller,
but
the
user
may
say:
hey.
I've
got
10,
000
maintenance
tests
in
the
queue
and
I'm
only
processing
a
hundred
maintenance
tasks
an
hour.
I
will
never
empty
the
queue
that
that
that
was
the
the
thought
I
was
seeing,
and
so
I
think
we
may
have
to
have
a
way
to
maybe
it's
maybe
not
safeguard
them,
but
alert
them
should
we
we
have.
A
A
A
B
I
don't
know
I
was
thinking
of
this.
You
know
situation
because,
as
we
are
running
meeting
and
start
sequentially,
okay
so
assume
now
I'm
running
the
common
graph
maintenance
task.
So
when
I'm
running
comment,
craft
maintenance
tasks,
all
the
repositories
of
the
commit
all
the
repositories
on
the
jenkins
controller,
you
know
would
run
the
comments
draft
maintenance
class,
so
I
don't
think
it
is
required
to
put
it
in
a
queue.
B
Once
I
finish
this,
then
I
take
out
the
other
maintenance
task
from
the
queue
and
then
again
around
all
of
the
you
know:
maintenance
tasks
on
the
get
caches
present
on
the
controller.
I
don't
see,
you
know
why
we
need
to
add
to
get
caches
in
the.
B
Like
information
like
you
know,
such
as
you
know
the
pre-fetch
the
commit
graph,
the
gc,
and
once
you
remove
the
information
from
the
queue,
then
we
can
iterate
through
all
the
repositories
present
on
the
jenkins
controller
and
run
around
all
of
them.
A
B
A
Gc
prefetch
was
what
was
the
graph
calculation
one
I'll
come
again
commit
graph.
Thank
you,
commit
graph
dot
dot,
or
do
we
iterate
over
repositories.
A
I
mean
that
has
the
nicety
that
has
the
very
nice
thing
that
the
user
interface
is
much
more
straightforward,
then
isn't
it
by
iterating
over
tasks?
You
say:
how
often
do
you
want
to
garbage,
collect
and-
and
it's
one
single
setting-
we're
not
worrying
about
how
many
repositories
are
there
that
are
cached?
That's
that's
a
very
elegant
idea.
I
don't
know
why
I
didn't
think
of
that.
That's
very
good.
Okay,
iterate
over
repositories,
and
but
the
problem
with
iterating
over
repositories
is
that
then
needs
much
more
complicated
maintenance,
much
more
complicated,
interfa
user
interface.
A
C
C
If
we're
not
letting
the
user
decide
the
the
repository,
where
they're
going
to
run
this
maintenance
task,
how
do
if
you're
going
to
so
then
the
assumption
is
that
our
system
is
not
going
to
care
about
the
size
of
the
repository
or
the
parameters
of
the
repository,
we're
going
to
care
about
running
a
maintenance,
pushing
a
maintain
tasks
and
then
executing
it
over
all
the
repositories.
C
But
then
I
I
believe
we
discussed.
There
were
issues
with
that
for
an
example
if
we're
running
gc
and
if
we
start
gc
as
the
first
maintain
tasks
and
then
we're
going
to
run
that
all
over
the
system,
this
sense
that
being
a
combinational
heavy
tasks.
So
do
we
want
to
then
have
the
awareness
to
understand.
C
How
do
we
make
sure
that
whatever
tasks
we're
running,
because
I
understood
initially
that
since
the
user
has
the
ability
to
decide
the
the
task
and
the
the
resource
on
which
that
task
is
going
to
run
on
that
is
the
pipeline
or
the
sorry
the
repository?
Then
it
would
be
easier
for
it.
It's
it's
a
work
that
we
don't
have
to
do
and
that
is
to
make
sure
that
we're
not
over
utilizing
the
over
utilize.
C
The
over
utilization
of
the
controller
is
not
happening,
but
now,
since
the
user
does
not
have
an
option
to
decide
the
repositories,
we
need
to
make
sure
that
either
we
have
the
intelligence
within
our
system
to
figure
out
the
kind
of
tasks
we're
running
and
the
kind
of
utilization
that
they're
going
to
take
once
they
started
to
run
because
we're
going
to
run
them
across
the
the
whole
controller
right
with
all
the
repositories.
A
So
I'm
not
sure
I
understood
that.
Could
you
repeat
the
last
part
of
your
sentence
again,
it
was,
if
that
we
need
to
run
the
the
thing
we
will
need
to
check
is
that
we
are
running
the
maintenance
task
over
all
of
the
repositories,
but
that
that
is
not
overloading
the
system.
Ask
your
question
again
richard
I'm
sorry
for
my
not
being
able
to
keep
up.
C
No,
I
actually,
I
think,
I'm
thinking
I'm
just
thinking
out
loud,
probably
so
I'm
just
thinking
if
that
is
something
that
we
need
to
worry
about
or
not.
So
my
question
was
that
if
we
are
not
giving
the
user
an
option
to
decide
on
upon
which
repositories
they
want
to
run
these
tasks,
then
what
we're
doing
is
we're
just
making
sure
that
okay,
this
is
the
schedule
I'm
going
to
run
a
gc
on
all
of
the
repositories.
C
B
You
know
a
regular
expression,
or
you
know
the
minimum
size
and
while
processing
each
maintenance
you
each
get
cash.
We
can
check
all
these
conditions,
which
the
user
has
put
and
then
check
if
he
wants
to
run
that
you
know
or
get
a
repository,
you
know,
run
maintenance
tasks
on
that
repository
or
if
we
skip
it.
That
was
what
I
was
thinking.
One
like.
A
A
B
A
A
Now
I
apologize
we're
almost
at
the
hour
and
I'm
it's
late,
my
night,
I'm
I'm
a
little
bit
weary!
I'm
unavailable
next
week
because
I'll
be
out
of
town
reshab
you'll,
provide
the
zoom
link,
it'll
be
a
different
length
than
the
one
that's
in
our
meeting
and
the
two
of
you
can
meet
separately
now.
Do
you
have
permission
to
to
edit
this
this?
Oh,
yes,
you
do
good,
okay,
okay,
so
you've
got
a
way
to
edit.