►
From YouTube: CI Minutes - architectural overview
Description
Fabio Pitino (Backend Engineer) gives an overview of the CI minutes feature.
A
So
they
are
only
applied
to
shared
runners
on
the
gitlab.com
and
if,
for
example,
you
are
using
private
runners
or
specific
runners
for
at
project
level,
for
example
those
consume,
this
consumption
is
not
tracked
against
the
ci
minutes.
So
the
same
means
are
initially
assigned
when
a
user
signs
up
for
an
account
on
gitlab.com
at
the
name
space
level.
A
So
as
part
of
the
subscription
plan-
and
there
is
a
monthly
allowance
that
is
given
to
a
specific
namespace
and
starts
with
400
minutes
on
the
free
plan
as
of
today
and
then
progressively
increases
for
a
higher
paid
tiers
and
and
then
on
top
of
that,
a
user
can
decide
to
buy
additional
minutes
if
the
monthly
allowance
is
not
sufficient
for
specific
for
a
specific
month.
And
so
these
two
values
of
the
monthly
allowance
and
the
any
additional
minutes
are
stored
on
on
gitlab.com
sent
from
the
customer
portal.
A
We
see
that
when
shared
runners
request
a
new
job
and
we
check
whether
for
the
potential
list
of
jobs
that
could
be
assigned
to
the
shared
runner,
whether
there
is
any
jobs
that
don't
have
ci
minutes
available.
So
we
take
the
namespace
of
the
specific
job.
But
we
see
whether
the
consumption
of
the
current
consumption
of
minutes
is
higher
than
the
limit
and
with
the
limit
given
by
the
sum
of
the
monthly
subscription
allowance,
plus
any
additional
purchase
minutes.
A
So
if
the
namespace
doesn't
have
any
emails
available,
we
don't
assign
the
job
to
the
runner
and
that
the
job
remains
pending,
eventually
shows
as
stock
and
the
pipeline.
And-
and
this
is
like
as
a
signal
to
say-
you
don't
have
any
more
minutes,
so
we
can't
process
any
more
jobs,
and
but
if
the
there
are
minutes
available,
then
the
job
is
assigned
to
the
runner
and
the
runner
proceeds
with
it
with
a
normal
execution
of
the
job.
A
When
the
job
is
completed
and
then
the
an
event
is
submitted,
and
then
we
update
the
ci
minutes,
consumption
based
on
the
job
duration,
which
is
the
the
amount
of
seconds
that
the
job
remained
in
a
running
state
which
is
being
executed
on
the
runner
machine.
So
we
don't
consider
as
part
of
the
minutes
consumption
and
when
the
job
is
in
a
pending
state
or
it's
been
or
is
in
a
created
state
waiting
for
previous
jobs
in
the
pipeline
to
be
executed.
A
So
when
the
job
is
idle,
for
example,
we
don't
account
cm
and
it's
only
when
the
shared
runner
is
actually
been
actively
executing
the
job.
So
we
we
multiply
the
consume.
The
duration
of
the
job
per
cost
factor
that
is
associated
to
the
shared
render
so
shared
runner
can
have
two
different
cost
factors
at
the
same
time
can
have
like
a
one
cost
factor
associated
to
private
projects
and
a
cost
factor
associated
to
public
projects.
A
But
before
doing
that,
we
actually
recalculate
any
additional
minutes
remaining,
and
for
that,
what
we
do
is
we
if
the
namespace
has
been
using
more
minutes
than
the
monthly
subscription,
but
it
has
also
additional
minutes.
In
that
case,
we
subtract
the
difference
from
the
additional
minutes.
So
to
make
a
quick
example,
if
we
have
an
plan
that
gives
us
1000
minutes
per
month,
and
but
on
top
of
that,
the
customer
has
purchased
400
minutes.
Additionally,
so
we
have
1400
minutes
in
total,
but
the
monthly
consumption
right
before
the
reset
is
1200
minutes.
A
So
we
are
200
minutes
higher
than
the
sub
subscription
plan.
So
we
have
to
reduce
by
200
the
additional
minutes
that
we
have
in
the
upcoming
month.
So
we
reduce
from
400
to
200
so
the
next
month
we
have
200
remaining
additional
minutes.
If
the
consumption
is
lower
than
the
subscription
plan,
then
we
just
leave
and
touch
the
additional
minutes
because
we
haven't
used
those
and
and
just
we
carry
over
as
is
in
the
upcoming
month,
but
then
after
doing
that,
we
reset
the
consumption
to
zero.