►
From YouTube: Technical Discussion for New CI Template Architecture
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone
and
thank
you
for
joining
this
call
this
boys
for
discussing
new
ci
template
architecture.
A
Actually,
let
me
share
my
screen,
so
I
already
sent
you
a
link
of
the
google
doc,
so
please
feel
free
to
write
down.
If
you
have
any
comments
so
yeah
at
first,
I'm
gonna
walk
you
through.
Why
we're
talking
this
topic
right
now,
like
they're,
a
bunch
of
problems
and
also
like
a
future
request.
Something
like
close
to
git
have
actions
so
at
first
we're
gonna
work
through
the
current
architecture.
A
That
was
a
problem
and
then
next
moving
it
to
the
prop
also
phase.
So
let's
get
started.
A
Oh
by
the
way,
if
you
have
any
questions,
please
feel
free
to
interrupt
me.
So
I
think
most
of
you
guys
know
what
cicd
template
is.
So
I'm
just
skipping
this
thing
and
then
it
says
architecture,
but
it's
talking
about
what
we
have
now
today.
A
So
in
the
previous
architecture,
templates
are
managed
in
the
gila
rails,
canonical
repository.
You
know
that
these
are
folder
yeah,
the
scalable
label
killer,
ci
templates.
All
templates
are
managed
under
this
folder
and
then
these
files
can
be
included
here
include
a
template,
keyword
or
directly
copy
paste
from
the
ui
picker.
A
So
here's
a
couple
of
examples
like
if
user
uses
verify
browser
performance
template
into
their
gloves
yaml
file
as
an
extension
or
like
include
template
as
a
workflow
like
old,
actually
old
devops
also
works
in
this
in
the
style.
Well,
all
the
labels.
A
You
know
drop
down
that
they
can
actually
choose
one
of
the
files,
the
templates
we
are
managing
in
this
directory.
I'm.
B
A
It's
just
this
is
the
intro,
so
I'm
gonna
go
quickly
so
yeah
like
blah
blah
blah
blah,
so
you
know
so,
but
actually
I'm
a
ci
template
maintenance
material
is
also
currently
tablet
maintenance
and
we
see
a
lot
of
problems
in
this
current
architecture.
Probably
you
you
guys
might
not
know
yet.
So
let
me
walk
through
the
the
problems.
What
do
we
have
today?
A
So
the
first
one
is
account:
control
templates
with
bargaining,
so
the
templates
in
the
local
file
stretch
doesn't
have
bargaining
information,
of
course,
so
usually
kind
of
specify,
specific
python
template,
which
include
a
keyword,
for
example
like
a
like
in
the
above
case
like
a
now
I'm,
including
the
old
devil's
template,
though
we're
going
to
specify
version
of
this.
A
Oh
yeah,
always
the
latest
template
in
the
current
repository
is
included
and
actually
the
the
current
killer
package.
You
know
if
it's
on
someone
starting
point
or
gitlab,
then
the
the
template
at
that
moment
and
the
40
pointer,
if
the
at
that
moment,
other
also
users
cannot
specify
a
floating
version
of
templates
with
including
keyword.
A
A
So,
for
example
like
now
I'm
including
autodevops
template
and
also
can
I
include
this-
like
verify
browser
performance
template,
we
don't
know
yet
it
might
closer
conflicting
problem
that
you
know
the
each
template
over
like
the
keywords
each
other
and
then
you
know,
codes
on
expected,
behavior,
so
yeah
like
so
zero
safe
mechanism
that
template
a
and
a
template
b
can
be
combined
and
used
a
user's
project.
A
Yeah,
so
we
are
lacking
kind
of
you
know,
system
level,
validation
and
the
third
problem
is
that
it
can
publish
templates
on
their
own.
So
actually
this
became
a
problem
recently
that
we
actually
received
a
community
contribution
from
the
partner,
our
partner,
that
you
know
they
want
to
publish
their
templates
with
the
technology.
But
you
know,
since
we
are
managing
these
templates
in
our
repositories,
they
have
to
go
through
our.
You
know:
community
con
community
competition
contribution
process
like
asking
maintainer
reviews,
and
it's
so
you
know.
A
Actually
it
was
causing
a
lot
of
frustration,
and
so
actually
they
were
really
frustrated,
complaining
that
the
process
so
and
then,
of
course,
community
computers,
partners,
third
parties,
individual
contributors,
open
source
project,
whatever
it
is,
they
cannot
publish
you
know
on
their
own.
They
have
to
go
through
our
ribbing
process
to
commit
the
files
into
into
this
directory.
A
So
this
is
quite
different
from
github
actions.
Right
so
github
actions,
user
can
publish
templates
at
their
pace
so
and
then,
like
it's
a
it's
super,
easy
yeah
and
then
next
problem
is
you
can't
find
a
desired
template?
A
Yes,
users
have
no
idea
what
templates
are
available
for
included
keyword,
so
we
can
point
the
template
folder
in
the
repository.
However,
this
is
not
user
friendly,
so
like.
If
you
are
asked
what
template
can
I
use
today?
You
just
point
this
directly
or
like
a
specific
future
documentation.
So,
like
it's
it's
hard
to
understand,
can
I
like
deploy
to
aws,
which
template
should
I
use
what
this
template
means?
What
this
template
does
there?
No,
you
know
summarize
the
information
general
metadata.
A
Everything
is
just
you
know
like
a
road
template
file
like
maintained
in
this
way,
and
maybe
there
are
a
few
comments,
but
it's
still
hard
to
understand
what
these
things
so
it's
hard
to
find
a
desired
template.
So
like
it's
more
like
charging
discoverability
issue,
and
then
next
point
is
the
next
problem
is
that
it
can't
keep
maintain
templates
ourselves.
So,
for
example,
we
have
these
over,
maybe
80
templates
here
and
then
you
know,
for
example,
cpr
template.
A
We
cannot
allocate
engineering
resource
to
maintaining
these
things.
We
just
like
you,
know
the
update
when
it's
necessary.
We
definitely
need
you
know
dedicated.
We.
We
should
ask
someone
who
are
dedicated,
for
you
know
each
technology
like
who
are
adopted
to
these
things.
We
should
ask
them
to
maintain
this
instead,
as
we
cannot
keep
maintaining
these
things.
Probably
we
add
more
but
yeah.
That's
a
problem.
A
The
next
problem
is
that
it
can't
maintain
dependencies
in
the
same
project.
So
maybe
you
know
some
of
you
know
that
templates
is
not
just
a
template.
Sometimes,
for
example,.
A
Here
is
a
autodevops,
auto,
deploy
template
and
it
has
a
bunch
of
review
or
like
staging
deployment,
country
deployment,
blah
blah
blah
right,
and
then
you
can
see
in
a
script
that
it
actually
doesn't
have.
You
know
the
bear
script
itself,
like
the
communicating
kubernetes
everything
the
scripts
is.
Scripts
are
included
in
this
custom
doc
image,
which
is
maintained
in
the
separate
project,
for
example
like
this,
so
this
project
is
100
percent
dedicated
for
this
template.
Just
you
know,
including
script
files.
You
can
find
it
like
him.
A
You
know
super
lengthy
scripts
file
so
that
we
we
don't
need
to
write.
You
know
scripts
directly
into
the
template,
which
is
super.
You
know
hard
to
maintain,
so
actually
some
of
our
teams
already
started
moving
to
this
technique
that
you
know
if
you
wanna,
if
your
templates
get
complicated,
just
create
a
new
project
to
build
a
docker
image
that
you
know
the
bundles,
the
bunch
of
scripts
or
yeah.
A
A
A
So
you
know
it's:
it's
not
streamlined
this
release
process
when
we
introduce
our
new
like
when
we
create
a
bump,
a
new
image
like
adding
a
future.
We
want
to.
A
You
know,
update
a
template
in
this
release
process
as
well,
but
at
this
moment
the
developers
have
to
visit
that
first
still,
the
image
project
and
the
next
visit
to
the
commander
bursary
to
update
the
old
deploy
image,
etc.
So
these
templates
aren't
imager
tightly
associated,
but
these
are
differently
version
separately
version,
then.
So
that's
a
problem
and
the
last
problem
is
that
cannot
avoid
rollback
on
production,
instant
that
this
actually
happened
recently.
A
That,
like
I
said
templates
always
you
know
latest
like
a
one
file,
is
existing
in
the
gitlab
instance
so,
and
this
template,
of
course,
is
included
in
a
bunch
of
users
projects,
though,
if
this
template
is
broken,
then
by
some
reason
we
ship
their
wrong
much
the
wrong
modular
guest
that
break
that
the
yama
syntax
or
something.
A
Then
it
breaks
all
of
the
user's
projects,
it
breaks
all
of
the
pipelines
and
then
sres
have
to
roll
back,
because
overall,
the
previous
version,
because
you
know
the
template
in
the
github
gitlab
instance-
is
what's
available
for
users.
We
can
swap
it
quickly.
A
What
are
we
having
today,
and
so
we
are
at
at
the
next.
We
were
talking
about
the
new
architecture,
the
new
proposal,
what
we
should
do,
but
basically
please
keep
in
mind
that
there's
a
problem
as
will
be
having
today
and
then
so
sorry,
let
me
add
one
thing:
the
product
side
from
pipeline
authorization
probably
might
be
again.
A
The
assist
me,
though,
like
basically,
they
wanna
something
comfortable
or
something
similar
to
github
actions.
You
know
like,
like
any
users,
can
publish
the
templates
easily
and
then
it's
available
immediately
in
any
projects,
so
yeah,
that's
also
one
of
the
motivations.
What
are
talking
this
topic
right
now,
any
questions
or
follow-up.
B
Comments,
so
there
is
a
lot
of
questions
in
the
agenda
already,
so
I
think
my
questions
are
first,
so
I
managed
to
read
the
blueprint
that
I'm
there
are
parts
of
it
that
I
love
explicit
interface,
describing
how
to
use
templates
marking
variables
as
required
or
optional
like
this.
Is
this
really
awesome,
so
I
just
wanted
to
say
that
it
feels
great.
I
have
a
few
questions,
though,
like
the
first
one
is
with
the
new
architecture
of
publishing
templates
as
packages.
B
A
Yes,
so
this
is
kind
of
similar
to
the
rubygem
and
the
library
the
package
server
like,
for
example,
rubygem
in
that
case,
there's
a
rubygem
org,
there's
a
like
central
repository
to
you
know
that's
popular
the
pulldown
pushed
by
anyone
and
then
typically,
when
users
create
a
ruby
project,
they
point
to
the
repository,
but
technically
they
can
also
build
their
ruby
gem
server.
B
Yeah,
I
understand
just
wanted
to
know
what
coming
is.
Writing
the
agenda
already,
that
we
know
that
there
are
organizations
that
are
not
willing
to
actually
connect
to
the
internet
from
the
github
instance.
It's
hidden
behind
that
not
and
basically
you
know
they
are
not
willing
to
retrieve
anything
from
the
internet
and
yeah.
A
Yeah,
so
so
I
was
thinking
about
the
thing
like
currently,
we
are
including
the
templates
in
the
repository
so
that
that
we
don't
have
that
issue,
but
like
thinking
about
that,
any
templates
communicating
to
doc
have
basically
doped
the
hub
because,
like
it
uses
docket
made,
you
know
image
keyword
so
like.
Why
not
it
can?
A
You
know,
pull
the
token
image
from
the
docker
have,
but
they
cannot
connect
to
the
gillab
dot
com,
for
you
know
pulling
packages,
maybe
they
have
the
other
dependencies
in
their
in
their
pipeline
script,
that
you
know
playing
package
from
npm
or,
like
I
said,
rubygems,
so
like
gillab.com
as
a
template,
a
template
library
server
should
be
also
allowed
in
their
organization.
B
Yeah,
so
we
might
want
to
validate
this
assumption
and
cross-check
with.
A
B
B
What
what
I
like
about
github
actions
is
that
it
feels
more
like
a
composition
that
you
can
actually
extend
a
single
job.
You
can
inject
something
you
know
your
pipeline
without
actually
the
risk
of
changing
something
that
you
have
never
intended
to
change.
So
that's
the
only
suggestion
I
have
about
the
next
iteration
thinking
about
whether
it
might
be
possible
to
extrapolate
this
new
architecture
onto
the
job
level,
somehow
so
that
you
can
actually
extend
the
single
job
without
the
need
of
inheriting
the
configuration
and
augmenting
your
entire
pipeline.
B
A
Yes,
I
totally
agree
with
that,
like
you
could
have
actions
will
encapsulate
the
job
definition.
So
one
thing
one
thing
we
cannot
do
like
they
do
is
that
in
github
actions
they
can
actually
use
all
files
in
the
repository
in
the
action
repository,
but
we
cannot
do
that.
We,
because
when
we
include
the
templates,
we
don't
include
you
know
whole
projects
into
the
jobs
into
the
job
execution.
A
So
what's
available
in
the
template
is
the
what's
written
in
the
template.
It's
our
cia
architecture
issue
and
then,
like
maybe
like.
A
We
want
to
follow
like
something
similar
to
what
they're
doing
right
now,
but
I'm
not
sure
currently.
B
The
next
one
I
have
is
about
how
we
actually
publish
the
packages,
because
I
think
that
right
now,
basically,
a
template
is
a
simple
yaml
configuration
right,
but
eventually
this
might
evolve
into
having
a
package
and
inside
the
package
you
could
have
batteries
included.
You
could
have
scripts
assets
whatever
you
you
want,
you
can
even
have
a
script
that
is
actually
going
to
generate
the
template.
A
At
this
moment,
I
haven't
thought
about
that.
Yet
the
package,
what's
included
in
package,
is
just
templates,
maybe
like,
for
example,
if
multiple
templates
exists
then,
like
a
combined
template
the
merged
one
in
the
package,
also
like
that
releases,
the
stress
of
their
performance.
A
But
what
I'm
thinking
about
it
currently
is
that
something
is
similar
to
doka
action,
what
they
have
so,
basically,
all
templates
publishers
should
created
the
basically
create
a
document
and
that
for
including
that
scripts
or
assets
helmet
charts,
whatever
things
like
something
dependency
over
the
template,
and
then
they
build
the
docker
image
and
then
push
it
to
their
published
project,
and
then
next
publish
the
templates
that
tightly
connected
to
the
the
docker
image,
so
that
that
that's
what
I'm
thinking
as
a
you
know
like
what
the
package
and
the
that
okay,
the
image
the
other
dependencies
there's.
B
I'm
not
I'm
not
sure
if
I
follow
entirely
but
like
we
can
talk
about
this
in
our
chips,
asynchronously
as
well.
So
the
last
question
I
have
is
actually
about
the
issue,
because
I
saw
that
we
do
have
an
architecture
task
tracking
issue,
and
I
I
just
wonder
if
this
issue
is
related
to
what
you're
working
on.
If
you
know
we
are
actually
collaborating
with
james
johnson
yeah.
So
basically
it
feels
like
this.
You.
A
I
haven't
noticed
it
yet
well
yeah.
It's
interesting
issue.
B
A
Yeah
yeah
yeah.
Definitely
I'm
gonna
pull
him
into
the
blue
script
that
if
there
any
like
parallel
work
happening,
I'm
I
don't
think
so.
Maybe
matia
knows
that,
like
some
isn't
something
happening
in
around
the
pipeline,
authorization.
D
So
no
we're
just
these
are
the
only
discussions
we
had.
We
had
with
the
partner
team
and
that's
to
just
get
our
get
their
thoughts
on
the
needs
of
our
good
lab
like
certified
gitlab
partners
that
want
to
contribute
their
templates
because
the
biggest
problem
with
them
contributing
templates
is
template
ownership.
D
So
they
want
to
contribute,
but
if
they
contribute
that
means
we
spend
resources
on
maintaining
them,
and
that
is
not
scalable
indefinitely,
so
they're.
So
the
only
insight
I
have
from
pipeline
pipeline
offering
is
that
we
talk
with
the
partner
team
and
they
want
something.
So
their
idea
is
similar
to
what
shinya
had.
So
their
idea
was
to
create,
like
a
to
evolve,
the
templates
into
each
template
being
a
package
of
sorts
and
then
having
a
registry
of
templates
similar
to
how
we
have
similar
to
how
gitlab
instances
can
have
private
docker
registries.
B
Yeah
anyway,
so
sheena
you
might
want
to
reach
out
to
james
yeah,
I
don't
know
double
check.
I
was
working
on.
A
Yes,
tiffany
fabio:
do
you
want
to
talk
about
that?
Your
point.
E
And
yeah,
so
this
is
a
it's
more
like
a
question
related
to
kind
of
going
back
to
the
basics
like
what
is
a
template
and-
and
you
know
we
can
like
a
template
for
now.
It's
just
like
some
configurations
that
you
can
include
and
this
configuration
is
going
to
be
merged
with
your
eclampsia
and
and
so,
while
certain
principle
makes
sense
when
including
a
template,
including
some
configuration
that
sits
on
the
same
local
repository,
it
might
not
make
sense
when
developing
templates.
B
E
Kind
of
style
of
template
we
want
to,
we
want
to
use.
E
E
Jobs
down
the
line,
this
is
probably
the
problem
we
have
like.
Can
I
use
safely
this
template
with
another
template
if
every
if
a
template
is
implemented
in
a
way
where
all
configuration
is
self-contained
like
into
each
job
and
a
job
called
as
everything
it
needs,
there
is
no
top
level
configuration
that
might
liquidate,
yeah,
yeah,
confuse
or
other
configuration,
then.
E
A
A
So
for
the
gitlab
managed
to
templates,
we
have
this
guideline,
so
this
actually
describes
what
some
sort
of
what
you
said
like
future,
like.
Basically,
we
differentiate
templates
into
two
types,
pipeline
templates
and
job
templates,
so
this
pipeline
template
is
more
like
the
pipeline
table
for
us
and
entertainment
cicd
workflow
that
matches
the
project.
Structural
language,
amazon
iteration
should
be
used
by
itself
project
that
don't
have
any.
I
think
it
also
files.
This
is
something
like
you
know,
language
like.
D
A
grails.
A
Or
gradle
language
specific
template,
it
has
ended
to
it
workflow
from
build
to
deploy,
build
test,
deploy
and
then
the
other
the
job
template.
One
is
like.
I
said
it's
more
encapsulated
that
it
doesn't
have
top
level
keyword.
A
It
does
only
certain
tasks,
maybe
only
typically
one
job
or
maybe
a
few
jobs
that
is
like
designed
to
be
included
into
an
existing
cic
workflow
users.
Maybe
user
have
already
altered
a
long
give
up
so
young
file,
but
they
need
to
extend
their
workflow,
so
they
just
include
the
you
know:
job
templates
in
the
in
this.
A
Like
manchester
case
I
described
these
types
differently.
I
described
it
as
a
workflow
template
and
then
and
and
then
a
task
template,
yeah,
better,
basically
the
same
and
then
there's
a
guideline
that
you
in
the
job
templates.
You
cannot
define
it
global
keywords,
blah
blah
blah,
so
yeah
there's
a
guide
right
here
and
then
what
I'm
thinking
about
that,
like
I'm
in
a
daily
template
maintenance,
we
wanna,
of
course,
do
this
thing
like
automate.
We
wanna
write
a
test
at
first,
you
wanna,
write
the
test
to
you
know
automatically.
A
Investigate
these
things
you
know
daily
pipeline,
but
also
I
was
thinking
that
we
should
enforce
this
end
users,
organization
organization
as
well,
so
that
when
user
combines
their
templates
and
our
templates,
then
there
are
no
conflict
issues
etc.
So
this
is
a
like
like
to
be
honest.
The
first
point:
originally
we
are
thinking
about
we
just
adding.
I
don't
know
the
testing
jobs
for
our,
what
our
templates,
what
we
have
today,
but
I
was
thinking
about.
A
C
I
I
like
it's
more
like
a
note
to
like
to
this
point,
like
the
guidelines
is
one
thing
but
like
discoverability
of
like
what
is
overwritten
overlaid
where
by
what,
if
you
have
like
many
levels
of
the
includes,
including
templates,
it's
pretty
hard
right
now.
So
this
is
like
the
clear
week's
problem
that
it's
like.
If
use
accidents
includes,
it's
really
pretty
complex,
to
figure
out
what
is
overwritten
where
and
by
which.
B
Yeah,
that's
also
the
reason
why
I
think
that
sometimes
composition
might
be
better
than
inheritance,
but
it's
a
broader
discussion
that
might
be
required
here.
C
Yes-
and
this
is
probably
like
related
to
my
point-
and
the
second
point
which
is
like
currently
templates
include
into
projecting
to
syria-
and
maybe
this
is
the
problem-
maybe
like
templates,
should
be
defining
different
type
of
tasks
like
asustinia
proposed,
which
is
like
a
workflow.
So
you
never
include
a
template.
C
You
just
use
the
template,
you
just
specify
parameters,
but
this
template
is
self-sufficient
in
your
it's
guaranteed
to
be
like
to
be
working
as
long
as
you
specify
parameters
to
use,
then
you
have
a
second
level
which
is
like
you
implement
a
specific
task,
which
is,
let's
say
our
spec
job
or
whatever
else,
and
you
include
that
into
your
project,
but
you
included
into
a
specific
task.
A
specific
test
could
be
like
some
kind
of
security
scanning.
C
A
specific
workflow
would
be
like
auto
devops,
which
is
like
iran,
I
don't
know
using
independent
pipelines,
but
for
tasks
like
a
security
scanning.
You
don't
really
maybe
need
to
run
dependent
pipelines
in
like
a
lot
of
cases,
and
the
third
step,
like
the
third
case,
is
like
what
user
was
mentioned,
like
it's
actually
like
a
step
of
execution
within
a
given
job.
So,
like
you,
have
your
own
processing,
but,
for
example,
you
add
a
step
that
executes
a
notification
plugin
or
anything
else.
C
That
is
part
of
your
of
your
job,
and
this
is
actually
like.
Each
of
these
are
actually
like
a
templated
definition
that
you
can
include
is
self-sufficient.
C
You
cannot
extend
because
I
think,
like
from
what
I'm
hearing
like
a
lot
of
problems,
comes
from
the
ability
to
extend
today,
and
this
is
exactly
what
you
just
mentioned
about
the
composition,
so
if
we
would
not
allow
to
accent,
but
rather
configure
and
compose,
maybe
like
this
whole
problem
of
like,
like
managing
templates
and
like
all
of
these
problems
of
how
they
are
written,
would
simply
go
away
because
they
could
be
written
in
any
way
that
you
want
as
long
as
as
it
works
well,.
B
I
think
it's
interesting
because
there
is
a
parallel
discussion
about
auto
devops
and
the
problems
we
have
with
auto
devops.
That
makes
it
very
difficult
to
extend
it's
very
inflexible
and
if
we
decided
to
make
templates
a
workflow
that
is
self
sufficient,
like
auto
devops
right
now,
it
makes
it
very
rigid,
sometimes
and
difficult
to
configure.
So
how
can
we
combine
the
composition
with
forkslow
in
a
way
that
you
can
actually
have
a
workflow,
but
it's
very
configurable
through
an
interface,
not
inheritance
like
this?
Is
you
know
just
just
difficult.
E
It
could
could
it
be
that
sometimes
it
depends
on
how
the
template,
somehow
the
template-
nothing
not
in
terms
of
like
a
single
yama
file,
but
in
terms
of
the
the
action
all
the
problems
trying
to
solve
is
design,
for
example,
for
other
devops
we
could
have
a
workflow
template
that
says
it
just
includes
and
everything
works,
but
you
know
there's
not
much
customization.
You
can
do
with
it.
B
What
about
having
a
autodevops
workflow
template
that
consists
of
other
templates
that
are
smaller
granularity.
E
Yeah,
yes,
exactly
that's
what
I'm
trying
to
say,
so
you
can
have
like
a
workflow,
but
you
can
also
have
as
part
of
other
devops,
that
you
can
include
only
specific
steps
that
you
you
want.
You
know
you
might
not
be.
You
only
want
the
deploy
part,
for
example,
and
you
can
include
that
template
on
that
part
portion
of
the
template.
A
Yeah,
auto
device
template
it's
kind
of
similar
to
you
know
what
you
said
like:
it's
already
has
a
bunch
of
job
templates
in
there
and
then
it's
basically
hazard
like
minimal
things
at
the
top
level
template
as
a
top
level
template
the
variable
stages
workflow.
A
So
actually,
I
also
realized
that
one
of
the
problems
with
the
task
template
is
that
you
know
stage
is
fixed.
How
do
we
treat
stages?
For
example,
this
template
includes
the
review
of
that
in
review
stage,
but
the
user
might
want
to
insert
it
into.
You
know
specific
points
like
before
this
job
or
after
this
job.
A
B
So
so
I
feel
like
there
are
a
lot
of.
There
is
a
lot
of
uncertainty
around
how
template
should
look
like
how
granule
configuration
should
be
and
how
flexible
it
should
be,
and
I
feel
like
what
we
have
right
now
served
us
very
well,
because
it
allowed
us
to
actually
understand
what
the
problems
are
and
now
we
can
iterate,
and
I
wonder
if
we
could
actually
find
the
most
significant,
significant
problem.
We
have
right
now
and
figs
fix
it
as
the
first
one
to
iterate
on.
B
A
Does
what
type
of
valuables
can
be
specified
for
arguments
etc?.
A
That's
interesting,
and
actually
I
saw
the
five
years
proposal
that
you
know
the
in
his
purpose,
though
it's
kind
of
similar
to
github
options
that
we
should
put
the
manifest
manifest
file
in
the
top
level,
the
top
level
of
the
repository.
A
On
the
other
hand,
I
my
purpose
is
that
include
the
template.
Spec,
the
template
metadata
into
the
template
itself,.
B
Okay,
can
it
be
like
a
middle
ground
like
neither
one
or
another
but
encapsulate
the
template
inside
the
directory,
and
this
way
it
will
be
something
in
between
it's,
not
one,
repository
per
template,
but
multiple
templates
per
repository
and
a
manifest
in
each
of
the
directories.
In
the
repository.
B
All
gitlab
templates
into
a
separate
repository.
We
would
have
one
repository
with
gitlab
managed
templates
and
we
could
extract
one
or
multiple
of
them
when
we
see
fit
and
when
they
are
actually
going
to
outline
the
single
opposition.
C
B
C
But
isn't
it
actually
like
that?
I
mean
so
far
like
versioning.
Wasn't
really
like
a
case
that,
like
you,
could
like
the
versioning
of
the
templates
would
be
associated
with
the
version
of
the
key
club
that
you
are
using
because,
like
the
template
would
naturally
evolve
with
the
gitlab
evolving
and
the
version
of
the
gitlab.
C
E
Yeah
but
you
won't
be
able
to
lock
your
config
to
a
specific
template.
So
let's
say
you
just
want
to
use
an
auto
devops
template
to
specific
version
1.0
and
you
don't
care
whether
it's
going
to
be
improved
later
on,
or
at
least
you
care.
But
you
want
to
upgrade
like
safely
and
you
don't
want
automatically
changes
to
leak
into
your
ci,
so
you
won't
just
lock
to
a
specific
version,
so
the
problem
will
have
having
with
the
way.
A
E
Version
so
if
we
have
version
1.0
and
then
we
introduce
a
new
template,
we
have
1.1
and
then
then,
if
we
change
an
existing
template,
we
bump
the
version
to
1.2,
but
then
for
that
template,
but
nothing
changed
between
1.1
and
1.2.
So
why
should
we
in
a
way,
you
know,
use
the
same
tag
or
same
versioning
mechanisms
for
multiple
templates.
C
I
I
mean
there
is
also
like
the
problem
that,
like
verse
running,
is
like
a
moving
target.
So
let's
say
you
stick
to
the
version
of
12.0.
Gitlab
of
a
template
is
very
unlikely.
It's
very
likely
that,
like
in
the
six
months
from
now
this
template,
we
simply
not
work
anymore,
because
some
conflicts
change,
some
images
got
updated
and
all
of
like
dependencies
are
really
like
out
of
date.
So.
B
The
same
problem
isn't
that
the
same
problem
as
with
gems,
for
example.
Yet
we
look
to
a
specific
version
because
we
don't
want
we
we
do
want
to
have
reproductible
builds,
for
example
right.
So
how
is
that
different
from
and
other
dependencies?
B
C
C
C
So
yes,
the
problem
is
the
same.
Just
like
the
severity
and
like
how
easy
it
is
to
maintain
that
it's
like
different.
C
B
So
I
I
guess
that
we
could
that
detect.
How
far
behind
is
a
template
version
you
are
using
and
we
could
warn
users
in
a
in
ui
showing
them
like.
You
are
using
an
outdated
template,
but
I
feel
like
versioning
is
also
required
to
break
compatibility.
We
might
want
to
bump
a
major
version
of
a
template
if
you
want
to
actually
do
something
differently
right
now,
it's
not
possible
and
we
are
stuck
with
this
infinite
backwards.
Compatibility
problem.
We
have
in
the
ci
since,
like
years.
E
E
Is
it
one
template
changes
radically
and
then
we
just
pump
the
version
for
the
entire
repository.
So
the
kind
of
proposal
I
was
suggesting
is
not
to
have
like
one
template
per
project
one
well.
We
have
one
project
and
put
templates
in
it,
which
doesn't
mean
that
each
project
must
contain
one
file.
It
means
a
project
contains
a
readme
that
has
the
documentation.
E
It
gives
us
like
our
ability
to
independently
version
and
would
reuse
what
we
already
have
without
you
know,
implementing
another
versioning
mechanism
on
our
own.
C
E
Works
within
a
project
each
you
know
it
can
also
allow
other
users
that
they
are
not.
They
don't
implement
or
make
changes
to
our
gitlab
managed
templates,
but
everybody
can
create
their
own
project
and
treat
it
like
a
template,
and
anybody
else
can
include
that
project
like
well.
E
Yeah
so
so
one
thing
I
was
like
hinting
earlier
like
I
then
played
like
a
project.
Template
might
not
just
contain
one
single
file
that
you
include.
It
could
be,
let's
say,
let's
take
the
auto
devops
if
we
put
it
into
different
in
a
different
project,
so
the
other
devops
you
can
decide
to
include
the
workflow
template
of
other
devops
or
you
can
decide
to
include
the
just
a
deploy
job
of
autodevops.
E
So
you
could
also
have
like
a
several
files
within
that
template.
In
a
way,
a
template
means
a
very
specific
template.
Project
means
like
a
very
specific
problem
that
solves
you
know,
and
then
you
can
either
include
a
specific
version
of
it.
Each
template
is
template.
Project
can
have
its
own
ci
to
check
its.
You
know,
or
can
have
like
an
example
project
in
it.
The
the
other
example
you
showed
earlier,
the
auto
diplo
image.
E
We
have
like
a
auto
deploy
image
project
that
sits
somewhere
else
and
the
image
then
is
compiled
and
then
is
reused
by
somewhere
else.
Well,
we
could
actually
have
the
auto
deploy
template
project
that
contains
the
code
for
the
docker
image.
That
is
automatically
compiled
and
and
uploaded
to
the
docker
registry
and
also
provides
a
yaml
file
that
you
can
include.
C
E
So
we
do,
we
need
to
have
this
kind
of
conversation
like
do
we
like
for
gitlab,
managed
projects
internet
marketing
places?
Do
we
create,
like
a
pre-created,
like
a
group
with
the
project
templates
that
concept
managed,
so
anybody
in
cell
phones
can
have
and
have
access
to
the
same
template?
I'm
not
sure
about
that.
E
Some
kind
of
a
a
mix
between
include
project
include
remote.
You
know
what
I
mean
where
you
can
actually
have
a
ability
to
pull
template
from
a
different
instance.
If
you
want.
C
It's
actually
interesting
because
we
had
initially
a
separate
people
for
our
templates.
That
would
then
be
like
imported
into
main
repo,
and
we
moved
that
from
away
from
that
design,
because
it
was
actually
additional
maintenance
pardon
into
like
a
single
repo,
and
now
we
are
discussing
moving
away
from
that
so
because
of
the
versioning.
C
So
so
then
the
question
is
like:
is
it
like
the
mind
problem
that
we
have
like
how
we
want
to
solve?
The
version
because,
like
from
the
point
that
I
hear
like
is
like
versioning,
our
ability
of
our
customers
to
contribute
to
the
templates,
presumably
separate
project
would
make
it
easier
what
other
problems
we
we
are
trying
to
solve.
There.
E
Is
also
the
pipeline
editor
that
wanted
to
integrate
the
template
better
like
a
better
ux
like
I'm,
I'm
writing
a
rails
app
and
I
want
to
search
for
all
the
rails.
The
tagged
template
so
show
me
on
the
sidebar
all
the
templates
I
could
actually
use
so.
D
E
D
D
E
So
I
think
it's
also
with
the
next
architecture
can
we
support?
Can
we
have
like
this
pipeline
editor
feature
that
also
supports
not
only
gitlab
managed
templates,
which
could
be
you
know,
displayed
as
featured
templates,
but
also
community
contribution,
and
so
anybody
can
have
their
own
template.
That
is
published,
and
I
can
reuse.
C
I
think
we
today
have
a
feature
that
you
can
configure
a
decimated
project
that
that
can
serve
to
like
with
additional
templates,
and
this
is
administrator
or
configuration.
C
If
I
remember
correctly,
there
is
a
feature
on
deploy
in
the
admin
area
that
you
can
configure
a
project
that
can
be,
at
the
summer
source
of
the
templates
to
be
used
in
the
system
like
exploring
the
like,
bundled
ones
like
sorry,
including
the
bundle
ones
and
including
also
these
external
start
in
their
repo
templates.
E
C
E
Yeah,
I
I
this
is
one
of
the
disadvantages
that
I
I
listed
there
in
the
in
the
architecture.
E
E
Maybe
we
need
to
have
like
some
way
where
to
import
template
as
as
as
a
mirror,
you
know
import
template
as
a
mirror
from
from
gitlab,
and
then
you
might
be
able
to
get
all
the
updates
and
still
and
point
to
your
local
version
of
it.
I
know
it
sounds
kind
of
not
as
that's
nice
but.
E
Mode
include
mode
that
can
allow
connecting
through
instances,
I'm
not
sure
with
which
one
makes
sense.
From
the
point
of
view
of
iteration.
C
I
I'm
kind
of
thinking
that
like,
in
any
words
what
krieger
said
ability
to
describe
the
template
with
some
kind
of
manifest
seems
like
at
the
best
first
step,
because,
like
then
like,
we
are
tasked
because,
like
this
model
should
basically
work
with
the
vendor
templates
and
external,
like
search
from
repo
templates
about
the
behavior,
I
think
like
right
now.
If
you
configure
a
repo
template
to
have
the
same
name,
it's
very
likely
that
it's
gonna
overwrite
a
bundled
template
and
it's
gonna
be
used
as
the
first
one.
C
C
C
We
don't
have
any
version
so
maybe
like
what
the
question
is
like
what
we
can
provide
compatibility
of,
maybe
like
we
always
have
the
version
which
is
like
locked
to
the
major
version
of
the
github,
that's
like
v14,
v40,
v13,
p14,
b15
or
whatever,
and
also
latest
something
like
the
version
like
this.
I
recorded
like
we
discovered
somewhere
in
some
issue.
I
think
presently
also
with
shinya
and
like
at.
D
C
Point
I
think
senia
mentioned
something,
so
maybe
we
just
introduced
to
russian,
which
is
like
a
stable
and
development,
the
kind
of
yeah
that's
absolutely
backward
compatibility
changes
because,
like
I
think
that
there
are
two
major
aspects
we
want
to
solve
with
the
version
like
ability
to
provide
new
features
and
ability
to,
and
also
like
with
changes
ability
to
remove
features
from
the
the
most
recent
template,
an
ability
to
provide
a
fixes
to
the
other
templates
that
we
are
still
supporting
today.
All
of
that
is
a
single
package
effectively.
B
I
agree
that
we
would
still
have
one
version,
like
all
the
all
the
templates
in
there
would
have
one
version,
because
we
could
only
we
cannot
tag
separate
directories.
We
can
only
attack
a
whole
repository,
but
it
still
seems
like
an
significant
improvement
to
the
current
state.
B
I
also
agree
that
this
is
not
something
without
challenges
and
problems,
so
we
might
need
to
figure
it
out,
but
basically
it
feels
like
it's
a
significant
improvement,
provided
that
we
also
work
on
the
metadata.
At
the
same
time,.
E
E
B
We
bundled
could
we
bundle
this
repository
every
time
we
release
gitlab
like
we
could
make
it
a
gem,
for
example,
or
something
else,
but
basically
it
there
should
be
a
way
to
solve
the
the
problem
of
sharing
that
with
customers
and
users
in
a
way
that
they
do
not
need
to
actually
reach
out
to
external
repository
or
package
manager.
Every
time
they
want
to
retrieve
a
template.
A
Actually,
I'm
thinking
that
this
problem
is
really
relatively
minor
that,
like
I'm
basically
against,
including
these
things
into
your
own
premises.
You
know
packages.
Rather,
we
should
you
know
on-premise
instances
to
pull
the
template,
catalog
and
roll
data
from
the
gitlab.com
or
whatever
central
server,
and
then
on-premise
server
should
cache
it
maybe
like
a
workforce,
will
be
a
workhorse
or
somewhere
that
you
know
to
prevent
the
unnecessary
network.
The
connection
happening,
so
this
is
this
mode,
is
definitely
like.
A
We
need
a
product
input
like
if
it's
a
level
or
not,
but
and
basically
like
you-
know,
introducing
more
github
action
like
architecture
that
users
can
search
the
you
know,
see
the
package,
template,
catalog
and
search
by
any
keywords
or
any
tags
specific
here
if
they
put
aws
and
they
see
the
whole
available
aws
integrated
templates,
some
sort
of
that
this
has
much
more
benefit
than
like.
You
know,
protecting
their
own
on-premises.
B
Possible
to
install
gitlab
with
some
packages
already
being
in
the
package
management
feature
of
gitlab,
because
we
you
can
manage
multiple
different
packages
with
git
lab.
There's
call
now
for
c,
plus
plus
there
is
a
dependency
proxy
for
golang.
There
is
a
lot
of
different
packaging
solutions.
Is
that
possible
to
install
gitlab
with
some
packages
being
already
in
your
local
package
store
or,
however,
we
call
that
package
catalog.
A
Maybe
there's
a
like
sync
sync
script:
maybe
we
can
provide
our
right
task
or
something,
but
I
I
would
assume
that
the
package
you
know
template
catalog
on
github.com
should
be
you
know
much
bigger
than
we
expect
that
I'm
really
looking
forward
to
seeing
that
you
know
external
contributions
would
happen
more
to
like
encourage
them
to
publish
their.
You
know
templates
that
maybe
like
that,
empowers
our
futures
more
so
yeah.
I'm
basically
focusing
on
that
point,
rather
than
yeah
paying
attention
to
you
on
premise.
A
This
specific
problem,
to
be
honest,.
E
Also,
regarding
you
know,
making
templates
available
on
self-hosted
we
might
do.
We
want
to
really
make
available
all
templates
that
are
accessible
on
gitlab.com,
because
we
might
have
a
community
contribution
templates
that
are
being
re
published
on
gitlab.com,
but
a
self-hosted
catalog
would
not
need
to
have
access
to
all
these
templates.
E
Template
so
so,
I
feel
like
that.
The
templates
we
want
to
make
available
on
cell
phones
they're
still
relatively
limited,
the
number
right-
or
at
least
as
as
iterations
the
problem
to
solve,
is
let's
make
available
the
same
templates
that
are
currently
available
on
self-hosted,
at
instance,
level
to
make
them
available
somehow
on
self-managed.
A
So
also
in
the
future,
we
would
like
to
involve
with
some
of
the
publishers
that
to
verify
their
templates
like
your
project,
your
partners
or
your
templates
are
verified
by
us,
so
like
it's
more
reliable
than
the
random
templates
that
published
by
random
contributors
so
like
on
gitlab.com,
we
wanna.
We
would
like
to
maintain
these
things
as
well.
Maybe
that
we
implement
the
future
to
you
know
give
up.
Also
administrators
can
do
that.
A
I
don't
know
how
it's
gonna
be
like,
but
basically
this
is
pretty
much
same
with
github
actions.
A
That's
well
slowly,
it's
time,
so
I
think
we
should
go.
A
I'm
gonna
summarize
what
we
discussed
today
and
then
definitely
I
appreciate
your
feedback
and
this
globally
template
atmospheric
blueprint.
Module
request
to
you
know
push
this
forward
more.
So
if
you
don't
wanna
have
any
other
comments,
I
would
close
this
session.
C
Okay,
so
maybe
last
final
comment,
I'm
just
not
convinced
about
like
the
packages
style.
Also
like
fabio
mentioned
about
the
security
aspect
like
these
templates
actually
require
more
scrutiny
from
us.
If
they
are
under
our
name,
they
actually
need
to
be,
to
some
extent
managed
by
us
and
provided
like
docker
hub
actually
has
like
this
library
type
of
the
repo
and
they
actually
kind
of
goes
like
through
most
more
stricter
validation
of
the
templates.
C
Anything
like
it
would
be
like
you
you
just
like
like.
If
someone
sees
a
template,
it
already
assumes
that
this
is
something
that
is
like
tested,
which
is
maybe
not
always
true
right
now,
and
it's
also
secure.
So,
if
our
on
premise
and
like
we
distinguish
the
template
for
our
own
premise
and
like
one
of
our
on-premise
customers
uses
that
which
could
be
stealing
some
anything
from
their
server,
it
could
be
actually
like
the
problem.
We
didn't
really
have
the
security
issues
yet
with
that,
but
this
is
additional
attack
vector
manifest.
C
Actually,
this
is
pretty
tricky
because,
like
we
can
also
improve
significantly
discoverability
of
templates,
if
you
simply
use
manifest
and
dogskitrap.com
as
a
way
to
search
available
templates
and
their
configuration
from
like
from
the
like
prescribed
manifest.
So
there's
also
some
ways
how
we
could
improve
the
current
workflow
today
and.
C
A
Sorry
I
couldn't
catch
what
you
said
last
year.
Would
you
have
a
like
a
specific
link
or
something
it's
in
a
docker?
Yes,.
A
All
right
cool,
so
thank
you
for
everyone
joining
cole.
We
still
haven't
decided
the
first
step
we
could
take,
but
it's
a
interesting
conversation
so
yeah,
let's
have
a
single
thanks.
Thank
you
very
much.
Bye.