►
A
Hey
everyone,
my
name
is
darby
and
I
work
in
incubation
engineering
at
gitlab
today
is
november
8th
2021,
and
this
is
the
devops
for
mobile
apps
demo.
So
as
always,
we've
got
an
issue
here
that
I've
created
for
this
demo
and
I'll
link.
This
issue
in
the
description
of
this
video
below
the
start
of
this
issue
is
same
as
always.
We
have
a
section
here
that
links
to
our
handbook
page
talking
about
our
mission,
which
is
about
improving
the
experience
for
developers,
building
mobile
apps
on
gitlab.
A
A
So
then
we'll
go
ahead
and
jump
right
into
the
demo
for
this
week,
so
we've
been
working
on
code
signing
and
beta
releases
using
fastlane.
So
last
week
we
did
the
ios
pipeline
and
this
week
was
the
android
pipeline.
So
we've
got
both
of
them
working
now.
They
they
work
pretty
well.
I've
got
a
screenshot
here
of
the
of
the
whole
like
build
pipeline,
and
so
this
is
what's
going
to
run
on
the
master
branch.
A
As
a
reminder,
this
project
is
using
fastlane
or
excuse
me,
this
project
is
using
flutter,
so
this
is
a
cross-platform
tool.
So
in
the
case
of
what
we
would
be
doing
here,
we're
actually
only
running
one
test,
build
right
now,
because
it's
just
testing
the
flutter
code
and
not
actually
the
specific
android
and
ios
code
bases.
So
that's
why
it's
set
up
this
way,
but
in
the
future
we
might
break
that
out.
We
might
do
it
a
little
differently,
but
that
was
kind
of
the
setup
for
this
time
so
down
here.
A
A
So
in
android
world
it's
a
little
bit
different.
There
isn't
really
the
equivalent
of
fastlane
match
for
android.
I
did
some
digging
and
there's
a
lot
of
discussions
around
it.
I
think
there's
some
third-party
plug-ins
for
fastlane
that
maybe
makes
this
a
little
bit
easier,
but
out
of
the
box,
it's
sort
of
a
roll-your-own
kind
of
situation.
A
So
there's
there's
a
key
store
file
that
you
use
to
kind
of
do
the
same
thing
that
the
fastlane
match
was
doing
for
ios
and
then
use
a
service
account
instead
of
a
an
api
configuration
for
for
actually
uploading
the
app
kind
of
really
really
doing
the
same
things
in
both
places.
Just
cite
different
mechanisms
for
those
so
then
below
here
I've
got
some
details
on
how
these
these
work
and
how
I
got
them
set
up.
A
So
basically,
what
we
do
is
in
the
in
these
documents
here
there's
there's
an
example
of
building
the
or
generating
the
key
store
through
the
android
studio
ui,
and
then
this
link
on
the
flutter
site
actually
shows
you
a
way
to
do
it
through
the
command
line.
So
there's
a
couple
different
ways
to
do
that
and
what
you
get
when
you're
done
doing.
A
If
I
wanted
to
and
basically
the
way
this
breaks
down,
there's
two
passwords,
there's
one
for
the
keystore
file
itself
and
then
one
for
the
specific
password
within
that
keystore
file
or
the
specific
key
within
that
keystore
file
that
you
want
to
access
and
then
that
key
is
going
to
have
a
name.
In
this
case
we
called
it
upload
and
then
there's
actually
like
a
path
to
the
file
on
disk.
A
So
in
this
case,
this
is
where
we
decided
to
put
it
and
then
the
the
second
part
of
this
is
just
configuring
gradle
to
actually
use
these
environment
variables
when
it
does
its
build.
So
I
just
put
an
example
here
and
I've
linked
to
the
the
file
in
the
project,
so
you
can
set
all
these
environment
variables
in
gitlab
and
then
the
other
part
of
it
is
actually
uploading
that
keystore
file,
because
we're
not
using
match
in
the
same
way
that
we're
using
it
for
ios.
A
We
don't
have
a
git
project
to
to
put
that
data
in
so
we're
just
going
to
put
it
in
an
environment.
Variable
I
linked
to
an
open
issue
in
git
lab
about
this
right
now.
There's
no
support
for
binary
files
as
environment
variables
or
as
ci
cd
variables
and
so
kind
of
the
work
around
here
is
is
just
to
base64
encode
the
contents
of
that
file
and
then
put
it
into
an
environment
variable
as
plain
text.
A
So
so
that's
what
I've
done
here.
So
I
do
a
base64
encode
and
then
assign
it
here
and
then
in
the
build
script.
We're
actually
just
going
to
decode
that
and
then
write
it
to
the
file
in
the
runner
and
you'll.
See
that
where
I
do
that
in
the
example
below
so
that
gets
us
our
code
signing
part
of
this.
A
A
There's
a
handy
command
too
to
check
that
to
make
sure
that
it
works.
So
you
can
just
run
fast
lane
run,
validate
play,
store,
json
key
and
give
it
the
key
file
and
then
that'll
test.
It
it'll
test
the
connection
to
the
play,
store
and
see
if
it
works.
So
that's
that's
kind
of
nice
to
double
check
things,
and
then
I
basically
use
the
same
methodology
as
above
to
put
this
in
as
a
cicd
variable,
so
taking
base64
encoding
that
file
and
then
putting
it
as
a
variable.
A
I
could
do
this
without
that.
However,
the
the
masking
functionality
wouldn't
work
in
that
case
because
of
some
special
characters
within
that
file.
So
I
decided
to
play
it
safe
and
just
base64
encode
that
as
well.
So
what
this
all
looks
like
is
this
is
the
ci
yaml
file.
So
what
we're
doing
here?
Some
simple
steps:
bundle
install
flutter
pubget,
so
this
is
just
pulling
our
dependencies
and
then
we
go
in
and
we
echo
those
two
files
out
the
base64,
decode
them
and
echo
them
out
to
the
file
system.
A
We
did
this
last
week
too,
so
we're
using
a
flutter
plug-in
to
auto-generate
the
versions,
and
here
we're
we're
just
specifying
the
versions
within
the
within
the
upload
command.
So
there's
a
version
code
and
a
version
name
and
there
there
are
different
inputs
for
that.
And
then
this
is
just
the
app
bundle
file.
So
this
was
generated
from
the
command
up
here,
and
so
we
just
give
it
the
path
to
that
file
until
it
upload
this
to
the
play
store.
A
So
it's
pretty
straightforward
in
in
this
case
we
were
using
a
lot
more
fastlane
functionality
for
the
ios
build
in
this
one,
we're
literally
just
using
this
one
command
upload
to
play
store.
So
it's
a
little
bit
simpler
this
time.
So
that's
it!
That's!
Basically,
what
it
takes
to
sign
sign
this
app
and
upload
it
and
I've
tested
this.
It
goes
through
the
process.
It
deploys
that
to
the
beta
testers
on
their
phones
and
everything
works.
So
so
that
was
good
to
see.
A
There's
a
few
other
pieces
of
information
I
just
captured
here.
One
problem
I
ran
into
which
I
thought
was
pretty
interesting-
is
the
the
upload
keystore
file
that
I
generated
was
generated
on
my
machine,
and
it
was
a
slightly
different
version
of
java
than
was
on
the
default
docker
image
that
I
was
using
to
to
run
the
to
run
the
deploy,
and
it
gave
me
this
this
error.
So
no
such
algorithm
exception.
A
I
dug
into
this
a
little
bit
and
found
out
that
it
was
really
like
a
version
discrepancy
in
java
and
it
wasn't
a
major
version.
It
wasn't
like
java
9
to
11
or
something
it
was
minor
version
numbers
within
java
11
that
I
was
running
into
so
I
fought
with
this
a
little
bit
and
decided
to
just
go
ahead
and
create
my
own
image
and
push
it
to
our
registry
and
just
use
that,
because
that
was
the
simplest
fix.
A
A
Where
did
that
link
go
from
this
blog
post
here
so
that
that
was
just
kind
of
the
work
workaround?
I
don't
think
that's
ideal.
I
kind
of
want
to
dig
into
that
a
little
bit
more
and
see
how
big
of
a
problem
that
really
is,
but
I
kind
of
got
around
the
the
problem
that
I
ran
into,
and
I've
kind
of
seen
this
before
too.
So
I
also
spent
a
little
bit
of
time
digging
into
something
called
mix.
A
A
So
there's
some
interesting
information
there
too.
So
that's
you
know
the
bulk
of
it.
For
this
week,
there's
a
couple
things:
I've
got
on
my
plate
for
next
week,
I'm
looking
at
improving
the
ios
efficiency.
This
was
something
kind
of
carried
over
from
last
week.
I
don't
think
this
will
be
too
much
effort,
but
just
clean
that
up
a
little
bit
and
then
talking
with
some
folks
on
the
runner
team
about
the
there's,
a
dependency
I'd
like
to
upgrade
in
the
mac
os
shared
runner.
A
So
I
want
to
see
if
I
can
contribute
that
over
there
and
then
I
want
to
take
a
step
back
and
then
look
at
some
ways
that
we
can
improve
the
overall,
like
simplicity
of
the
process
of
app
signing
and
releasing
with
git
lab
on
fastlane.
So
if
there
are
some
ways
that
we
can
create
some
some
automations
or
just
some
some
kind
of
simplified,
I
guess
ci
configurations
that
we
could
just
use
that
someone
could
take
and
get
started
quickly.
I
think
that
would
be.