►
A
As
always,
I
have
a
issue
here
that
I've
created
for
today's
demo
and
you'll
be
able
to
get
to
this
issue
from
the
the
description
in
the
description
of
the
video
below.
As
a
quick
reminder,
we've
got
our
mission
here
and
our
link
to
our
handbook
page
and
the
mission
for
this
group
is
to
make
the
experience
for
mobile
engineers
building
a
gitlab,
a
better
experience,
and
so
that's
that's
what
we're
focused
on.
You
can
read
about
it
in
the
handbook
here
and
you
can
also
check
out
previous
weekly
demos.
A
Another
weekly
demos
link
here,
so
we'll
jump
right
into
this
week's
update.
So
today,
I'm
going
to
talk
about
this
feature
that
I'm
I'm
specking
out
called
code
signing
code
signing
in
gitlab
and
I've
got
a
I've
got
two
issues
that
I'm
going
to
talk
about
here.
One
is
about
ux
and
one
is
about
architecture,
so
we'll
do
the
the
ux
one
first
and
I've
got
a
link
to
that
issue
right
here.
So
you
can
follow
along
this
with
the
discussion
there.
A
And
so
this
is
some
ideas
about
what
this
could
look
like
and
for
each
of
these
different
types
of
assets,
the
the
attributes
are
a
little
bit
different.
So
in
the
case
of
the
android
key
store,
there's
there's
two
passwords
and
an
alias
name
that
get
associated
with
that
as
as
well
as
the
the
file
itself
provisioning
profiles
a
lot.
All
of
that
data
is
just
built
into
the
file
itself
and
then
I
believe,
for
signing
certificates
for
ios.
A
A
The
idea,
though,
here,
is
to
be
able
to
visualize
the
data
for
that
type
of
asset
in
the
proper
way.
So
in
a
provisioning
profile,
you
would
want
to
see
maybe
the
the
team
identifier,
the
bundle
id
the
expiration
date,
things
like
that
versus
a
an
android
key
store,
which
would
which
would
be
a
little
bit
different.
So,
like
I
said,
there's
a
link
to
this
issue
here:
I'd
love
to
get
any
feedback
from
folks
if
they
have
opinions
on
how
this
should
work
or
how
this
should
look
so
yeah.
A
That's
that's
where
that
kind
of
ux
discussion
is,
and
then
the
second
issue
I
have
here
is
about
the
architecture
proposal.
So
this
is
how
this
actually
work
within
git
lab
in
the
underlying
data
models,
and
things
like
that.
So
within
this
issue
it's
I've
kind
of
sketched
out
some
ideas.
But
basically
the
highlights
are
I'd,
be
proposing
a
separate
database
back
model
for
each
type
of
asset,
and
I
think
that
what
this
allows
us
to
do
is
it
gives
us
the
ability
to
validate
that.
A
So
in
the
case
of
android,
we
want
to
make
sure
that
you
have
all
the
the
right
properties
associated
with
it,
so
the
passwords
and
alias
and
stuff
before
we
save
that,
because
otherwise
things
aren't
going
to
work
down
downstream.
So
we
would
do
that.
We
can
also
visualize
it
better.
You
know,
sort
of
here
being
able
to
see
the
bundle
id
or
the
team
identifier
or
things
like
that
within.
A
We
think
it
lab
would,
I
think,
be
very
helpful
and
then
it
would
prevent
confusion
around
like
which
which
file
are
we
passing
around
or
what
is
the?
What
are
the
internals
of
that
certificate
or
whatever,
and
then
I
think
this
could
also
set
us
up
to
be
able
to
generate
files
ourselves
later
so
instead
of
having
to
build
it
on
a
local
machine
and
then
upload
it
to
gitlab,
we
could
literally
just
generate
it
within
gitlab
and
put
it
right
within
the
account.
A
So
those
are
those
are
some
thoughts
around
that
and
then,
when
we
do
that,
then
we
would
add
the
ability
to
in
inject
the
relevant
environment
variables
into
the
ci
job.
So
in
the
case
of
a
provisioning
profile,
you
might
just
need
the
file,
but
in
the
case
of
an
android
key
store,
you
need
the
key
store
and
the
password
and
the
alias
and
the
a
to
this
password
to
all
kind
of
pass
through
to
the
ci
job.
A
So
we
would
want
to
be
able
to
intelligently
pass
that
information
in
to
the
to
the
runner.
So
I
think
we
could
do
that
by
by
having
this
set
up
that
way.
There's
the
the
support
that
we
don't
have
within
gitlab
right
now
is
for
binary
files
to
be
passed
into
ci
jobs,
and
so
there's
going
to
need
to
be
a
change
to
the
runner
to
support
that
right.
A
Now
we
support
text
files,
but
but
binary
files
don't
work
in
that
context,
so
we'll
need
to
figure
out
a
way
to
to
work
around
that
or
to
get
that
to
work
and
then
yeah.
Then.
The
last
thing
I
have
written
here
is
we'll
just
start
with
one
asset
type
and
then
prove
out
the
concept
and
then
roll
out
the
other.
A
So
I
think
kind
of
starting
with
the
the
android
file
type
probably
makes
a
lot
of
sense,
and
then
we
can
kind
of
incrementally
roll
out
the
other
types
as
we
go.
So
that's
kind
of
the
highlights.
There
there's
already
been
some
discussion
in
the
architecture
proposal,
but
obviously
we'd
love
to
get
more
input
there
as
well.
So
so
please
jump
in
there.
A
If
you
have
anything
to
to
add-
and
then
the
last
section
I
put
in
here,
there's
a
couple
sort
of
configuration
or
considerations
that
that
I'm
thinking
about
right
now
this
is
purely
focused
on
mobile,
but
maybe
more
generalized
code
signing
feature
would
make
sense
and
it
would
be
an
easy
adjustment.
I
think
the
main
area
that
I
see
missing
right
now
is
desktop
app
signing
for
windows.
A
I
think
the
desktop
signing
for
mac
can
already
be
done
with
the
the
similar
process
that
mobile
uses,
but
windows
is
sort
of
not
in
that
not
being
considered
right
now.
So
I
want
to
look
into
that
and
then
you
know
there's
also
the
idea
about.
Do
we
want
to
pass
all
this
information
to
all
runner
jobs
or
just
the
ones
that
need
are
needed
for
code
signing
and
so
there's
some
discussion
in
the
architecture
issue
about
that
as
well.