►
Description
5mp is now Cloud Seed ⛅🌱 https://hello.cloudseed.app
Cloud Seed is an open-source program lead by GitLab Incubation Engineering in collaboration with Google Cloud.
Deploying web application (and related workloads) from GitLab to major cloud providers should be trivial.
Cloud Seed makes it ridiculously simple and intuitive to consume appropriate Google Cloud services within GitLab.
A
A
If
a
user
tries
to
access
this
page,
the
user
is
not
a
maintainer,
just
a
regular
user.
It's
again
a
404.
This
page
should
be
made
available
only
for
project
maintainers
maintainers
should
be
able
to
access
this
page
if
the
feature
flag
is
enabled.
If
not,
we
hide
the
page.
If
the
feature
flag
is
enabled-
and
the
gitlab
instance
has
been
configured
for
google
oauth
2..
A
A
Then,
once
the
instance
is
set
up,
so
the
feature
flag
is
enabled
and
it's
been
configured
for
google
award
2.
We
can
show
them
the
page
with
the
list
of
service
accounts.
If
the
project
does
not
have
any
service
accounts,
we
show
a
relevant
message
for
that
else.
We
show
the
list
and
finally,
we
show
a
link
to
the
generate
service
accounts
page
that
starts
the
whole
process.
These
were
the
scenarios
that
were
tested
for
this
route.
A
The
next
route
that
was
tested
is
the
google
cloud
generate
service
account
get
route.
All
the
checks
of
the
previous
page
are
included,
so
the
checks
of
the
user
maintainer
feature
flag
status
and
google
auth
2
conf.
All
of
these
have
to
be
tested,
of
course,
but
additionally,
there
are
some
tests
that
are
relevant
for
this
page.
A
A
A
A
If
this
has
not
been
performed,
we
show
a
relevant
warning
and
we
login
error
for
the
admin
to
review.
If
this
permission
or
this
api
has
been
enabled,
then
we
move
forward
and
we
check
whether
the
user
has
gcp
projects
or
not.
If
the
user
does
not
have
a
gcp
project,
they
are
prompted
to
create
a
gcp
project.
A
A
First
of
all,
we
have
to
include
all
the
checks
we
did
previously,
so
the
checks
on
the
user
maintainer
status,
the
feature
flag
and
the
google
award
to
configuration
once
all
of
this
is
good.
We
check
specifically
for
this
page,
we
check
if
the
google
iam
api
has
been
configured
or
not.
This
is
similar
to
the
cloud
resource
manager
api
described
in
the
last
section.
A
This
is
supposed
to
be
done
by
the
admin
of
the
gitlab
instance.
For
that
particular
instance,
once
the
google
im
api
has
been
configured,
we
can
proceed
if
it
has
not
been,
then
we
showed
a
relevant
warning
to
the
user
and
we
log
login
editor
for
the
admin,
but
assuming
the
iam
api
is
configured.
We
now
have
the
ability
to
create
service
accounts
for
the
user,
and
we
do
the
same
once
that
has
been
done.
These
service
accounts
are
saved
as
project
ci
variables,
so
the
test
plan
should
include
all
of
this.
A
A
A
Now
that
the
tests
are
complete,
the
next
part
for
me
for
next
week
would
be
to
componentize
the
front
end
using
vojs
and
the
pyjamas
framework.
A
I've
already
begun
working
on
that,
but
that
will
take
me
next
week
and
I
will
be
writing
additional
front-end
tests
for
that
that
piece
of
work
I
want
to
now
set
a
date.
I
want
to
target
29th
of
october,
that's
next
friday,
to
make
this
mr
come
out
of
draft
stage.
So
mdmr
should
be
ready
for
reviewers
and
maintainers
to
start
the
review
process.
The
review
process
will
take
a
while.
I
believe
it
will
be
a
back
and
forth.
A
It
will
be-
let's
say
two,
maybe
three
weeks
of
reviews
and
fixes
and
things
of
that
nature.
That's
my
estimate,
which
means,
if
things
go
really
smooth
we're
looking
at
shipping
this
as
part
of
14.5
in
november,
but
the
most
likely
outcome
is
that
this
might
be
pushed
back
to
14.6,
we'll
see
how
it
goes
next
week.