►
Description
Related to https://gitlab.com/gitlab-org/gitlab/-/issues/389857
B
Was
yesterday
morning,
oh
okay
yeah,
so
they
would
have
not
been
merged,
yet
all
right,
well,
I'll,
go
over
it
quickly.
Just
while
I've
got
you
to
make
sure,
we've
got
the
same
idea,
yeah
with
three
clusters
and
three
agents,
one
for
each
of
it's
just
split
it
up
for
production
review
and
staging
there's
nothing
special
about
these,
except
that
they
each
have
a
dedicated
branch
that
each
agent
looks
at.
They
look
at
and
there's.
This
is
just
like
pure
manifest.
There's
nothing
fancy
going
on
here!
B
And
yeah
and
that
doesn't
really
work
that
well
with
basic
manifests,
but
you
could
hopefully
imagine
if
you
were
using,
you
know
Helm
or
something
a
bit
more
powerful
here.
It
would
start
to
pay
off
a
little
bit.
It's
kind
of
a
pain,
especially
for
review
apps,
which
we'll
get
to,
but
everything
else
kind
of
works
quite
well,
so
this
Branch
thing
I,
actually
quite
like
and
I,
will
show
you.
B
Why
is
because
we
have
predicted
branches
for
each
of
these,
and
the
only
thing
that
can
push
to
them
is
a
dedicated
token
for
that
branch.
So
no
one
can
miss.
No
one
can
mess
with
what
is
on
this
Branch.
You
could
configure
this
yourself.
I've
used
project
tokens,
but
you
could
also
use
deploy
keys.
B
They
have
to
write
to
the
branch
yeah,
but
so
you
could
do
either
or
a
bot
user
or
you
could
do
it
manually
if
you
really
wanted,
because
then
you
could
create
merger
quiz,
but
we'll
talk
about
that
a
bit
later
yeah.
So
these
are
just
branches
setup
projected
there's
tokens.
Each
token
is
in
also
exposed
as
a.
A
B
Yeah,
so
I
will
I'll
go
back
to
that
then.
So
now
we've
got
these
three
agents
looking
at
their
three
branches.
This
will
have
a
bit
more
in
it.
Since
last
time
you
looked,
but
basically
what
happens
is
and
this
this
Project's
a
bit
odd
as
well,
because
it
runs
builds
and
tests
and
then
updates
manifest.
A
B
So
all
that
I
mean
all
it
does
is
pull
the
deployment
branch
in
this
case
is
those
particular
branches
mergers
only
fast
forward,
so
you
might
get
merge,
commits
or
anything
like
that
very
brittle,
we'll
come
back
to
that
as
well,
and
push
us
to
the
branch
head
of
the
branch
and
the
agent's
going
to
pick
that
up
and
deploy
it,
and
it's
that
it's
I
mean
it's
that
simple.
This
could
be
done
by
a
Verge
request.
B
If
you
wanted
to
have
approvals
code
owner
stuff,
you
know
all
that
sort
of
thing.
So
this
this
merge
really
doesn't
have
to
happen
in
good
website
CI
at
all.
You
could
have
it
just
in
a
traditional
measurequist
with
all
your
nice
rules
and
everything
like
that,
and
that
way
you
can
use
all
the
pile
of
other
features.
We
have
around
making
sure
merge,
requests
are
approved.
A
Okay
and
if
okay,
just
so
that
I
understand
it
correctly
so
right
now,
when
you
set
up
the
protected
branches
with
the
project,
access
tokens
or
so
obviously
token
users.
Basically,
this
is
because
you
merge
and
push
from
the
ti.
But
if
you
would
do
it
from
the
merge
request,
then
you
would
set
up
those
protected
branches
for
the
users
who
are
allowed
to
merge.
A
B
A
B
A
A
B
B
A
B
A
B
B
So
that
will
eventually
that
will
stand
up
an
environment.
It
actually
takes
a
while
because
it
will
provision
and
Ingress
and
everything
and
I
won't
change
to
that
term,
because
it's
been
recorded,
but
that
will
stand
up
if
I
go
to
environments
that
has
been
deployed
to
and
assuming
that
everything
goes
goes
well
have.
I
got
my
measure
quiz,
though.
B
A
B
A
And
and
okay
and
next
question
we're
discuing,
is
and
feel
free
to
say
you
have.
No
idea
is
that
we
create
environment,
one
review
environment,
one
the
resource
Group
is
taken,
there's
a
an
unstarted
manual
job
to
stop
that
environment.
When
we
create
a
new
environment,
is
it
that
would
they
conflict
or
not?.
B
B
A
B
This
point
they
review
it
yeah
and
that's
kind
of
tricky,
because
it's
not
in
Maine
the
cool
thing
about
everything
else
is
that
everything
is
in
Maine
and
you
just
have
to
look
at
where
branches
are
compared
to
main.
But
rubyopes
is
not
so
you
have
to
check
the
review
Branch,
but
that's
okay.
It's
still
stores
somewhere.
A
B
A
B
I
didn't
I
didn't,
but
you
can
you're
free
to
because
again
you're
changing
branch
and
pushing
to
a
different
branch.
I
haven't
set
up
version,
Quest
pipelines
and
that's
what
you
need
to
Auto
Stop,
the
environment
I
think
so.
Yes,
that
should
I,
don't
see
any
reason
why
it
wouldn't
work,
but
I
just
haven't
done
it.
Okay,
we
can
probably
add
that
should
be
fine.
This
is
going
to
build
an
image
and
tests,
and
so
now
we
can
take
the
image.
B
B
So
that
is
that's
all
happened,
yeah,
so
the
deployment.
So
all
the
stuff
is
hooked
up,
but
yeah
it's
a
bit
out
of
sync,
because
this
says
it's
deployed
when
the
push
happens
not
or
when
the
job
read
not
when
the
agent
actually
picked
it
up.
But
it's
probably
close
enough.
It's
close.
It's
close
enough
to
to
work
out
what's
happened,
but
now
you
can
look
at
what's
deployed
and
it'll
just
kind
of
yeah
that
works
like
that.
Yeah.
B
A
B
A
B
A
B
A
B
A
But
but
what
I
mean
is
that
that
that's
that
that's
that's
a
little
bit
missing
to
me
there
that
I
have
the
review
up.
It
uses
image,
X
and,
of
course,
injury
in
the
merging
Quest,
I
kind
of
have
it's
saying
that
use
image,
exports,
paging
and
production
as
well,
and
once
it
gets
merged.
That
might
be
the
way
to
do
it
actually.
A
B
B
So
I
it
did
think
about
this
and
it
kind
of
you
kind
of
end
up
in
a
bit
of
a
chicken
and
egg
scenario
when
you've
got
the
same
repo
making
the
code
changes
as
updating
the
Manifest,
because
if
you
automatically,
if
you're
automatically
pushing
then
you'd
be
like
creating
pipelines
for
yourself
yeah,
we
could
probably
think
about
a
bit
further.
But
I
didn't
I
didn't
come
up
with
a
nice
way.
Yet.
A
B
A
A
B
Yeah,
once
you
have
different
projects,
it
becomes
a
lot
easier
to
do
stuff
like
that,
where
you're
pushing
to
the
same
branch
that
you're
just
changing
and
like
it
gets
yeah
gets
a
bit
confusing.
So
it
would
be
much
easier
if
I
get
a
bit
more
a
bit.
You
know
more
straightforward.
Have
you
had
a
separate
project
and
separate
projects?
That's
where
it
will
kind
of
actually
work?
If
you
hit
multiple.
A
A
Anything
because
that
was
that
was
how
I
think
about.
Is
that
like,
like
that,
basically
tagging
should
work
in
the
application
project
yeah.
They
said,
okay,
build
a
new
tagged
image
and
then
move
it
out
to
staging
and
production
and
so
on,
and
when
it's
not
a
tagged
one,
then
it
might
still
go
to
review
environment,
but
it
shouldn't
go
up
to.
B
Yeah
the
cool
thing
about
this
as
well,
since
these
are
just
branches
I
can
just
oh,
they
both
got
pushed
there's
a
you,
can
just
compare
branches
as
branches
or
create
merge
requests
to
do
all
this.
All
these
nice
kind
of
UI
things
that
we've
been
pretty
good
at
for
a
while
I
just
work
on
branches,
which
is
nice.
A
A
But
publish
it
and
I
will
try
to
get
feedback
from
intra
from
solution.
Architects
technical
account,
managers
to
people
who
are
on
the
field
like
what
do
they
think
about
this
setup
and
whether
we
can
remove
the
beta
flag
and
I
think
you
should
just
focus
primarily
on
on
kind
of
polishing
what
you
have
and
and
writing
the
the
description
yeah
like
a
little
bit
but
followingly
or
or
besides
that,
if
you
have
capacity,
I
would
like
to
ask
you
to
think
about.
Where
could
this
fail
kind
of
like
a
pre-mortem
style,
I.
A
A
B
You
want
staging
and
production
branches
to
be
a
subset
of
what's
in
Maine,
you
don't
want
to
have
to,
but
you
need
it.
You'd
need
a
process
around
going.
Okay,
we
need
to
put.
We
need
to
fix
staging
so
we'll
merge
something
into
staging
that
needs
to
go
back
into
main
before
main
can
get
into
like
before
the
process
can
resume
so
there's
just
kind
of
like
extra
process
that.