►
From YouTube: Argo Contributor Experience Office Hour 29th Apr 2021
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
Okay,
so
good
morning,
everyone
one
more
time,
oh
good
evening,
so
today
we
had
a
whole
new
team
in
that
meeting,
so
guys
from
cod
fresh.
If
you
don't
mind,
maybe
can
you
introduce
yourself
and
I'm
going
to
you
know
just
use
a
list
of
users
from
my
screen.
I
see
first,
roy,
oh
yeah.
Can
we
go
hit
this.
B
Yeah
hi
guys
so
I'm
a
vacant
developer
from
code
fresh
from
orange
team
working
on
the
the
new
autopilot
which
we
are
about
to
present
today.
Awesome.
E
F
Hi
guys,
I'm
I'm
a
team
leader
at
the
codefest
and
also
working
on
the
rbcd
autopilot
project.
Awesome
welcome
guys.
So
thank
you
great
to
have
you
folks.
A
All
right,
and
so
today
a
list
of
items
issued.
I
think
you
forgot
italia
right
did
I
he
was
next
to
my
okay.
Sorry
about
that.
A
A
G
H
A
G
G
So
the
just
to
recap
the
main
problems
that
we
identified,
that
there
is
no
opinionated
way
to
install
algo,
cd
and
and
the
best
part
is
supposed
to
do
it
in
a
github
way.
So
we
wanted
to
tackle
this
point
and,
of
course,
github's
based
installation
of
august
cd
requires
manually,
editing,
manifest
indicate
repository,
and
there
is
no
opinion
that
way
how
to
create
and
add
other
cd
applications.
G
Argo
cd
projects
in
a
github's
approach
way
and
to
solve
the
the
problem
of
how
to
correctly
model
a
need
to
deploy
a
single
application
multiple
times
in
different
logical
environments
that
can
be
on
different
clusters
and
how
to
do
it
in
a
github's
approach,
way,
of
course,
facilitated
by
algo
cd.
So
these
are
the
main
things
that
we
wanted
to
tackle
in
the
autopilot,
and
we
already,
of
course,
created
a
full
release,
lifecycle
that
we
can
show
you
a
little
bit
later.
We
did
it
using
code.
First.
G
E
B
Thing
just
command
plus
a
couple
of
times.
It's
tiny.
E
Okay,
is
that
better
or
okay?
So
first
thing
all
the
obviously
autopilot
commands
require
a
git
token,
because
basically
we're
cloning,
a
repo
making
some
changes
and
then
commit
and
pushing
it.
So
the
easy
the
simplest
way
would
be,
of
course,
to
put
it
in
the
end
variable.
I
already
did
that.
So
I
have
a
token
already
in
my
environment,
but
that's
a
good
way
to
start.
You
can
also
just
pass
it
on
to
every
command,
but
it's
massive
this
way
and
the
first
command
I'll
just
create
an
empty
repository.
F
E
Variable
so
it'll
be
easier
for
for
the
following
commands,
and
now
I
can
bootstrap
the
solution.
So
basically
bootstrap
like
this
with
all
the
default
variables,
it
will
apply
argo,
cd
and
application
set
on
my
coordinate
cluster.
Currently
I'm
on
my
gke
cluster,
so
it's
applying
it
there
and
then
it
will
also
commit
to
my
github
repo,
all
the
the
the
bootstrap
manifests,
which
include
that
iocd
and
application
set
and
another
application-
and
it
also
applies
one
application
directly
to
the
cluster.
E
E
E
E
Empty,
so
there's
nothing
here
yet,
but
so
you
will
add
projects
and
applications,
and
everything
will
appear
here
and
now,
if
I
look
in
the
repo,
so
the
bootstrap
app
is
looking
at
this
folder.
So
this
is
do
applications
and
then
argos
of
the
app
is
looking
at
this
folder,
which
is
basically
a
customization.
That
brings
argo
cd.
E
Everything
here
is
customizable,
so
in
the
bootstrap
command
that
I
executed,
I
can
send
in
a
different
url,
so
you
can
put
in
adversity
from
a
different
source,
your
own
flavor,
with
your
own
stuff.
They
we
only
require
a
lcd
and
application
set,
but
everything
else
you
can
do
whatever
you
want
with
it
and
then
the
the
sorry,
the
second
application,
the
root
application
is
looking
at
projects
which
is
currently
empty.
It
only
has
a
readme
file
which
explains
how
to
create
a
project.
E
E
So
now
I'm
creating
a
project
with
again
all
the
default
parameters,
I'm
just
calling
it
prod.
Just
a
name,
a
project
is
both
an
argo
cd
project
and
an
application
set
so
we'll
see
it
over
here.
If
I
go
into
root
and
just
refresh
to
make
things
a
bit
quicker,
so
here
is
the
project
and
application
set
together,
and
if
I
look
in
in
my
repo.
E
This
is
just
what
I'm
going
to
call
it
it's.
It's
gonna
have
a
the
prefix
of
the
of
the
prod
of
the
project,
but
it
will
be
prod,
underscore
f1,
and
this
is
the
the
source
so
according
to
support
the
sources,
only
customize
but,
of
course,
we'll
add
other
different
options.
E
So
now
we
have
this
application
that
we
created
and
it
has
the
base
folder
which
directs
to
where
I
was
installing
the
app
from,
and
then
we
have
the
overlays
prod
which
directs
the
base.
So
over
here
I
can
add
patches
or
whatever
I
want
to
add
for
a
specific
project
overlay
for
a
specific
project,
and
this
is
the
file
that
the
the
app
set
is
watching
for
and
we'll
create
an
application
from
it.
So
now,
if
I
refresh
again,
I
should
see
it.
E
E
Project
and
now
I
want
to
create
it
on
a
different
cluster
in
order
for
agua
city
to
have
access
to
a
different
cluster,
it
has
to
get
the
the
context
for
the
cluster.
So
first
I
need
to
log
in
in
august
b,
and
this
is
something
that
we
should
improve
upon.
We
want
to
make
it
more
seamless,
but
for
now
I
I
need
my
argo
cd
config
file
to
contain
the
correct
token,
so
I'm
basically
logging
into
auto
cd.
E
Okay
and
now
I
can
create
a
new
project
and
this
time
I'm
creating
a
different
name
and
I
have
a
destination
cube
content.
So
this
is
a
different
quantities,
cluster
that
I
have
access
to,
and
these
are
just
flags
that,
basically,
we
forwarded
them
forward,
then
to
drago
cd,
so
the
taco
city
will
be
able
to
connect
to
its
server,
so
the
obviously
cli
will
connect
to
the
ocd
server.
So
when
I'm
running
this,
so
this
is
a
bit
different
than
the
previous
command,
because
it
doesn't
do
only
github's
operation.
E
E
So
here
I'm
basically
I'm
using
the
same
the
same
name
as
before
and
the
same
source.
This
will
make
sure
it
will
have
the
same
base
folder,
and
this
will
well.
This
will
be
validated
for
the
same
name
we
put
in
the
same
url,
otherwise
it
will
fail
and
I'm
giving
it
a
different
project.
So
now
this
is
what
what's
going
to
cause
it
to
be
on
a
remote
cluster.
E
E
E
E
Okay,
so
I'm
just
using
a
different
image
for
staging-
and
I
can
just
have
some
pipeline
automatically
update
some
tags
after
build
and
this
way
I
deploy
to
staging
and
over
here
we
should
see
that
automatically.
E
You
should
create
a
new
deployment
there.
It
is,
let's
say,
deployment
new
okay.
So
now
in
the
staging
I'm
running
a
different
version
and
once
I'm
satisfied
again
some
pipelines
some
set
of
rules,
I
decide
I
want
to
promote
it
to
production,
then
I'm
just
committing
over
there.
So
it's
all
being
done
through
here.
G
E
And
we
also
have
some
a
few
other
commands.
We
can
just
manage
their
applications
in
a
specific
project
and
we
can.
We
will
be
adding
delete
and
some
more
commands
that
will
help
to
handle
the
githubs.
Here.
We
can
see
that
in
production
we're
on
the
default
cluster,
but
then
in
staging
we're
under
a
different
server.
E
E
E
E
Different
ways
to
customize
with
a
c
just
to
customize
the
installation
in
different
ways,
so
you
can
use
a
and
already,
if
you
have
a
repo
that
you're
already
using
you
can
just
add
the
entire
thing
into
it
into
some
photo
that
you
like
and
that's
about
it.
G
A
Before
you
show
like
yeah,
I
want
to
say
it
was
super
impressive
to
me.
I
was
impressed
that
you
know.
I
can't
know
the
use
case
because
we
talked
about
it,
but
it's
super
cool
that
it
was
even
easier
than
getting
started,
guide
or
fargo
city.
E
E
J
Thank
you
very
much
for
the
demo.
This
was
really
good.
I
had
a
few
questions,
or
rather
a
few
things,
to
confirm.
If
I
understood
correctly
so,
could
you
show
me
the
directory
structure
once
I
just
want
to
check
so
so
you
so
you
had
a
base
on
which
you
had
to
manifest,
and
then
you
had
overlays
on
that
base
for
every
environment
right.
J
Nice
and
in
projects
you
had
the
argo
projects
being
defined
there.
I
think
I
kind
of
missed
that.
So
sorry.
E
E
So
then,
in
the
project
we
can
have
some
permissions
and
make
sure
it's
from
specific
data,
repo
or
specific
cluster,
and
this
is
what's
generating
the
applications
themselves
by
looking
at
the
overlay
in
a
specific
in
its
own
subfolder.
So
this
is
the
staging
project.
So
it's
looking
at
overlay
staging.
J
Got
it
okay,
yeah?
Thank
you
very
much
and
you
had
a
bootstrap
directory
as
well
right.
E
E
F
E
J
Got
it
it,
it
ensures
everything
that
you
put
in
your
projects.
Directory
gets
pulled
in
and
synced
onto
the
cluster
awesome,
yeah
and,
and
could
you
could
you
show
me
the
bootstrap
argo
cd
directory
once
please.
E
J
Interested
okay,
so
there
is,
there
is
a
high
level
directory
that
you
maintain
and
from
that
github
repo,
you
install
a
do
a
namespace
install
of
argo
cd,
okay,.
E
Yeah-
and
it's
also
you
can
have
this-
is
the
cluster
installed
and
you
can
we
have
an
option
for
namespace
installation?
That's
what
you
need.
G
B
J
Thank
you.
I
think
that
sounds
good,
another
question,
so
so
I
think
under
demo
you
have
bootstrap
and
projects
and
they
are
very
argo
cds,
setup
specific,
but
I
think
I
mean
something
that
I
haven't
noticed
and
that's
probably
something
I
want
to
confirm.
If
today
I
was
to
let's
say
I
started
with
this
and
you
know
I'm
happy
and
everything,
and
then
somebody
wants
to
take
that
customized
directory
in
there
and
use
it
for
flux
in
principle.
J
J
E
Customization
overlay
directing
at
the
base
well
yeah
it
has
the
config
json.
So
that's
an
app
send
specific.
I
guess.
J
Got
it?
Thank
you
very
much.
This
looks
good
and
one
last
thing.
So
do
you
have
something
based
on
what
I
saw
in
your
yaml?
The
secrets
are,
of
course,
not
being
committed
to
git
they're
being
created
onto
the
cluster,
but
you're
referencing
them
from
your
manifests.
Is
that
correct.
E
Yeah,
if
yeah,
so
the
argo
cd
application
from
here
is
everything
except
the
secret.
The
cli
applies
that
and
the
secret
so
that
you'll
have
access
to
the
github
repo
and
it's
also
something
that
we
want
to
improve
by.
But
then
we
probably
need
to
use
some
secret
management,
some
skilled
secret,
or
something
like
that,
so
we'll
be
able
to
commit
it
as
well.
J
Got
it
I
mean
I,
I
kind
of
like
that
as
well,
which
means,
if
I
mean
there
are
two
ways
like
two
thought
process,
and
we
can
go
into
details
on
that,
but
in
general
this
this
ensures
that
if
somebody
wants
to
use
a
different
secret
management
tool,
they
can
use
it
separately,
but
you're
just
not
committing
that.
Okay,
okay
yeah,
I
think,
sounds
good
to
me.
Thank
you
for
the
demo
now
my
pleasure.
A
Do
you
want
to
give
me
I'm
trying
to
imagine
I'm
almost
going
to
kind
of
you
know,
suggest
additional
features
and
just
want
to
hear
if
you
think
this
would
be
useful,
I
feel
like
you
can
think
about
whole
set
of
fairy
commands
that
help
manage
argo
cd
settings.
For
example,
you
know
you
can
because
the
tool
can
be
as
opinionated
as
needed.
You,
for
example,
might
have
argo
cd,
autopilot
configure
sso
octa
and
the
benefit
is
that
you
know
what
octa
is
and
then
you
can
figure
out.
A
You
know
you
can
like
use
cli
to
user,
for
configuring
it
and
basically
hope
pretty
much.
You
can
think
about
cli
driven
workflow
for
almost
any
rvcd
setting,
for
example,
resource
customization.
Do
you
think
it
would
be
useful
or
is
it
out
of
scope.
E
No,
we
haven't
thought
about
a
configuring
deeply
rcd,
but
it
might
be
a.
G
Such
capabilities
I
mean,
I
don't
see
anything.
Why
not
in
terms
of
scope,
I
think
it's
totally
fine.
We
did
have
other
things
that
we
wanted
to
do
before,
especially
around
the
secrets
that
just
no
I'm
sure
right
now,
because
we
do
want
everything
to
be
fully
github
as
well
addition
of
new
clusters.
F
G
To
take
care
of
uninstall
and
deletion,
and
we
want
to
show
the
actual
state
not
only
listing
gibbs
for
the
kit
and
do
some
optimization.
So
for
my
perspective,
actually
we
have
the
proposal
doc
and
we
have
like
future
work
items
that
we
have
demonstrating
so
feel
free
to
add.
I
mean
really
just
put
put
your
thoughts.
We
really
want
to
get
the
feedback
from
you
guys
and
what
you
said.
I
don't
think
it's
for
sure
part
of
the
scope
just
matter
of
what
we,
what
we
do.
First,
what
we
do
afterwards.
D
B
Yeah,
and
also
just
something,
I'm
not
fully
aware
of
the
of
the
process
of
supporting
octa,
but
about
which
part
of
it
is
supported
using
the
declarative
setup,
because
everything
that's
declarative,
I
think
we
can
possibly
support
after
out
of
the
box
or
really
easily.
B
So,
if
that's
something
declarative,
we
can
think
of
supporting
it
pretty
much
soon.
I
think,
but.
B
A
Okay
and
another
question:
is
it
possible
to
maybe
it's
not
yet
possible,
but
do
you
think
it
will
be
possible
in
future
to
customize
structure
of
that
repository?
Basically,
I'm
thinking
about
users
who
already
use
rbcd
and
they
have
different
structure,
and
you
know
if,
but
they
used
some
kind
of
convention.
If,
if
you
could
let
users
kind
of
configure
that
conversion
somehow
they,
then
they
could
take
advantage
of
the
autopilot
as
well.
E
I
would
imagine
that
if
they
have
like
similar
structure
but
just
different
names,
it
might
be
possible
by
some
simple
mapping
to
do
it.
But
if
the
entire
structure
is
like
upside
down
with
overlays
and
pieces,
it
might
be
a
bit
more
of
a
challenge
and
I'm
not
sure
if
it's.
B
C
Yeah,
that
was
that
was
my.
That
was
actually.
My
question
is
how
how
tied
in
is
the
autopilot
with
the
directory
structure
like?
Is
it?
Is
it
like
really?
Is
it
like
opinionated
in
terms
of
the
bootstrap
process,
or
is
it
opinionated
the
whole
way
through
meaning
like
okay,
you
give
me
this
directory
structure?
C
Can
I
then
go
in
and
customize
this
based
on,
like
my
like
my
environment
or
like
how
the
the
way,
I
you
know
me,
and
my
team
would
do
our
own
directory
structure
or
is
this
like
opinionated
from
the
the
top
bottom.
B
So
so
right
now
it's
pretty
much
locked
locked
in
place
in
terms
of
the
structure,
but
I
guess
if,
if
we,
if
we
found
out
that,
there's
like
three
different
structures
which
the
community
loves,
then
maybe
we
might
support
it
doing
the
bootstrap
command.
Maybe
you
just
create
give
the
user
a
choice
between
three
different
structures
or
something
like
that.
B
But
right
now
it's
it's
locked
in
in
this
structure.
J
Yeah,
I
think
the
way
I
see
it
is
it's
really
hard
to
have
an
opinionated
structure
which
everyone
will
like.
So
I
think
that's
an
effort
worth
doing
but
worth
getting
into.
J
We
just
don't
know
I
mean
I
I
just
don't
know
how
rewarding
that
would
be,
because
to
be
fair,
no
structure
is
something
everyone
likes
and
not
sure.
If
the
get
outs
working
group
is
something
where
we
could
all
have
a
larger
agreement
on
what
a
structure
could
look
like,
but
then
yeah
I
mean
we
should
assume
that
as
long
as
the
structure
fulfills
the
needs
of
folks
who
want
to
say
hey,
I
have
no
clue
what
the
structure
needs
to
be.
J
G
Also,
we
also-
I
mean
there
is
no
basically
if
we
will
see
that
after
the
feedback
that
we
get
also
from
community,
that
we
have
gaps
that
suggest
that
we
maybe
need
to
support
already
some
different
structure.
So,
of
course,
we
can
always
do
the
required
changes.
We
really
invested
a
lot
in
in
thinking
about
the
structure
to
be
able
to
support
the
use
case
of
multiple
environments
and
which
is
one
of
them.
C
Yeah
yeah,
it's
it's
not
it's
not,
and
also
I
personally
actually
structure
my
repos
very
similar
to
how
you
guys
do
it.
So
it's
not
like
it's
not
like
it's
it's
it's
it's
bad!
It's
just!
I'm.
Just
thinking
of
situations
where,
like
me,
as
in
on
the
operation
side,
have
a
specific
directory
structure
and
then,
like
I
hire
a
group
of
developers
who
have
been
using
autopilot
and
then
all
of
a
sudden.
We
have
this
contention
of
like
how
to
art.
You
know
all
of
a
sudden.
C
A
A
Try
to
see
what
users
say
and
then,
if
you
get,
you
know
like
100
requests
to
slightly
customize.
You
know
if
everyone
pretty
much
uses
similar
structure
but
slightly
different.
Maybe
you
can
introduce
some
configuration
loops
and
just
let
them
you
know
adopt
to
what
they
have
already
and
you
know,
but
I
would
not
do
it
right
away
because
we
don't
know
yet.
G
Totally,
I
totally
agree
with
the
comments.
Eventually
we
from
our
side,
one
of
the
biggest
issues
that
we
see
both
with
cod,
fresh
customers
and
also
internally,
it's
super
hard
to
get
to
a
good
methodology
of
how
you
actually
structure
your
stuff-
and
this
was
like,
I
think,
maybe
50
of
the
time
we
invested
was
deciding
how
to
correctly
structure
all
these
all
this
stuff
in
a
way
that
makes
sense
and
also
also
provides
resolution
for
for
what
the
use
cases,
including
secrets,
eventually
and
all
the
multiple
environments.
G
So
hopefully,
we
will
only
need
to
support
like
variations
and
not
completely
different
methodology,
but
I
I
really
think
that
alex
is
right.
We
need
to
see
what
is
the
feedback
from
the
community
and
decide
afterwards.
What
are
the
correct
and
next
stages
in
terms
of
structuring
in
that
area?.
A
You
know
cli
commands
that
how
to
phrase
it
basically
promote
command
that,
let's
say
if
we,
if
you
introduce
knowledge
of
qa,
provide
preproad
into
the
cli
and
then
you
can
you
know,
then
you
can
maybe
run
command
like
promote
and
it
would
make
you
know
propagate
changes
from
yeah
yeah.
G
A
F
G
A
G
G
A
Like
you
know,
for
for
future
users
to
to
make
to,
you
know,
help
them
understand
where
project
is
going.
I
would
list
you
know,
possib
possible
future
features
in
the
readme.
So
people
understand
you
know
what
eventually
project
is
going
to
be
like,
and
I
I
personally
you
know
the
first
suggestion
about
argo
cd
management.
A
I
I
see
it
as
a
value.
I've
seen
its
value
as
a
argo
cd
operator,
it's
a
pain
for
me.
You
know
to
basically
go
and
manually
change,
rcd
con
settings
sometimes,
and
that's
why
we
introduced
we
start
working
on
argo.
Cd,
util
and
util
is
like
non
opinionated
tool
that
help
you
generate
settings
and
we
see
the
autopilot
is
even
kind
of
higher
level
it.
It
can
provide
good
user
experience
and
experience
might
be
even
better
because
you
have
much
narrow
context.
You
kind
of
you
know
how
user
is
managing.
A
You
know
how
exactly
user
manages
server
cd,
so
argo
cd
util
can
simply
produce
a
yaml
and
then
you're
supposed
to
copy
paste
and
put
it
into
file.
Autopilot
can
just
go
ahead
and
commit
it
and
sink
it
right
away,
yeah.
So
what
I
was
trying
to
say
that
if
you,
I
don't
know
describe
all
the
possible
directions
where
project
can
go
so
users
understand,
and
then
you
let
them
choose
what
you
know,
which
parts
are
the
most
important
that
will
help
to
the
project
to
go.
J
Yeah-
and
I
think
in
in
in
general,
like
while
we
are
at
it
on
you,
know
using
this
as
also
to
commit
configuration
changes
around
argo
cd
itself
in
in
general.
We
may
want
to
consider
how
I
mean
if,
if
it's
needed
at
all,
if
you
wanted
to,
you
know,
lay
out
the
direct
structure
a
little
more
differently,
so
that
you
know
you
could
call
it
out
very
clearly.
J
This
is
where
your
cd
manifests
look
like
to
should
land,
considering
the
fact
that
the
persona
who
would
you
know
change,
argo
cd
configuration
might
be
very
different
than
the
persona
who
might
just
change
application
manifests,
given
the
fact
that
the
the
folks
who
manage
argo
cd
may
not
even
have
any
idea
what
applications
go
into
and
vice
versa,
but
then
to
me,
what
I
feel
is
that
that
customized
directory
is
where
you
could
actually
I
like
and
like
the
persona
which
alex
has
in
into
it.
J
J
And
I
think
no
man
folks,
I
think
dan
and
everyone
while
you're
at
it.
I
would
also
like
to
just
pass
on
something
similar
that
folks
at
red
hat,
has
been
working
on
with
respect
to
you
know,
both
trapping
initial
manifests,
laying
them
out
under
different
directory
structures,
etc.
I
just
put
it
on
chat
if
you'd
like
to
collaborate
on
not
a
single
implementation,
rather
on
you
know,
directory
structures
etc.
Let
us
know
we
run
it
into
the
same
conversations
as
well.
D
Yeah,
we
are
actually
working
up
to
improve
our
repository
layout
too.
So.
G
G
B
Contributing
yeah,
okay,
so
basically
we
just
created
the
two
pipelines.
One
is
for
the
the
sli.
Obviously,
and
one
is
for
the
release.
We
tried
to
keep
it
simple
to
do
it
all
with
just
two
pipelines,
and
the
life
cycle
itself
is
pretty
much
similar
to
what
you
do
in
other
argo
projects.
So
you
just
create
a
pr
to
the
main
repo
and
it
automatic
automatically
just
runs
the
the
ci
pipeline,
which
I'll
show
in
just
a.
B
B
B
Go
out
to
a
version
branch
once
you
want
to
release
a
new
version,
you
just
go
to
a
version
branch
and
it
runs
the
ci
as
usual
and
when
once
you're
ready
to
release
new
version-
and
you
can
only
do
it
from
the
the
version
branch
and
only
by
the
repo
admins,
you
can
just
send
a
release
message
and
it
will
run
the
release
pipeline.
F
B
So
it's
pretty
simple
at
the
moment.
A
Thank
you
for
sharing
and
before
we
before
I
forgot,
I
noticed
on
the
picture.
There
was
rollouts
and
events
do.
Do
you
still
have
plans
to
eventually
support
rollout,
specific
commands
and
events.
G
G
G
A
A
A
G
You
know
it's
kind
of
much.
We
we
totally
have
it
on
our
map
for
for
before
the
community
meeting.
So
then
dan
will
help
us
create
a
blog
post
that
will
focus
on
how
exactly
what
norm
did,
but
a
little
bit
more
thoroughly
and
how
to
create
and
deploy
your
application
multiple
times
and
promote
it
between
the
environments
using
the
autopilot
using
our
cd
totally
fully
github
support.
A
A
H
Hey
alex
jan,
if
we
have
time
could
I
throw
talk
about
changed?
What
I
want
to
do
for
the
release
manifests
that
we're
doing
with
rollouts
and
and
maybe
argo
cd.
Eventually,
I
think
it
should
be
quick,
yeah.
H
Okay,
so
this
is
so
I've
basically
been
working
on
automating
the
rollout
release,
process
and
john.
I
think
you're
really
familiar
with
the
argo
cd
side
of
things,
because
you
you
did
it
on
the
cd
one
of
the
changes
that
I'm
I'm
doing
for
rollouts.
Is
that
so
today,
when
you,
when
we
publish
manifest
this
is
true
for
rollouts
in
cd,
we
commit
a
version
of
the
manifest
to
a
tag.
H
This
is
stable
right
now,
but
there'll
be
like
a
you
know,
v1.0
install.yaml,
so
the
the
difficulty
with
this
is
that
it
actually
requires
those
manifests
to
be
committed
and
get
with,
and
then
the
manifest
themselves
have
to
have
the
the
correct
image
in
those.
So
there's
almost
like
a
little
bit
of
a
chicken
and
egg
problem
where
you
have
to
have
a
tag
to
commit
and
that.
H
Commit
actually
has
to
have
the
correct
image
tags
there
so,
instead
of
committing
those
manifesting
to
get,
what
I'm
doing
for
rollouts
is
actually
attaching
them
as
release
artifacts,
so
the
installed
donamos
names
installed
and
will
actually
get
uploaded
to
as
a
release
artifact
alongside
like
any
binaries
that
and
go
there
and
so
for
the
release
process
for
rollouts.
It's
it's
actually
now
gonna
be
a
github
action.
H
So
this
there's
a
github
action
supports
something
called
a
workflow
dispatch
action
which
basically
means
you
can
go
to
an
action
and
run
it
ad
hoc.
So
I
can
go
to
this
release
action
in
this
case.
I'm
just
giving
it
a
tag
to
commit,
and
then
this
this
github
action
will
perform
the
actual
make
manifest
and
then
upload
it
to
a
a
github
release.
So
it
would
this.
This
release
was
automatically
produced
by
the
action
and
then
these
artifacts
were
uploaded.
H
So
so
that's
pretty
much
the
change
I'm
doing
for
rollouts.
I
thought
it'd
benefit
other
projects
as
well,
because
of
that
that
whole
chicken
and
egg
problem
of
a
tagged
commit
having
to
have
also
the.
J
J
I
I
F
I
And
I
agree
that
that
the
way
you
shown
it
like,
with
the
with
the
dispatch
and
and
also
to
provide
the
the
manifests,
as
in
release
asset,
probably
would
be
the
way
to
go
for
rsd
as
well.
So.
H
Cool
and
I
I've
tested
that
you
can
still
keep
ctl
apply
the
new
url,
which
is
it
like.
This
url
would
still
work
as
a
cubesat
apply,
so
it's
just
releases
download
and
then
this
tag-
and
you
can-
and
this
also
works
as
a
customized
remote
resource,
so
it
still
works
with
customize.
So
I
think
I
don't
see
a
downside
in
switching
to
this
url.
The.
H
F
I
I
think
it
would
it
would
like
alex.
What
do
you
think
I
mean
today?
We
have
this
script,
which
creates
a
you
know.
You
need
to
to
create
a
release,
tag
like
a
volatile
tag
and
stuff
like
that,
and
I
think,
triggering
the
action
via
or
the
workflow
via
github.
A
You
know
what
basically,
in
the
in
the
release
section,
it
would
be
even
easier
if
you
could
specify
you
know,
branch
and
desired,
commit
tag
and
then
release
section
create
that
commit
deck
as
well
as,
basically,
if
you,
if
you
make
that
release
action,
to
do
even
more
work
for
me.
So
I
don't
have
to
I
just
pick
release
branch
and
just
tell
to
you
know,
release
it
from
yeah,
but.
H
There's
definitely
yeah
some
flexibility
here
this
one.
This
process
as
it
stands
right
now
requires
the
tag
to
exist,
and
then
you
run
it
but
you're
right
that
the
workflow
itself
could
commit
or
push
a
tag
and
then
do
the
exact
same
thing.
It's
kind
of.
A
I
understand
why
you
didn't
do
it,
because
you
would
have
to
provide
credentials
to
push
to
get
right.
That's
right!.
H
H
But
that's
yeah,
it's!
I
think
you
already
have
credentials
native
credentials
in
the.
I
H
I
Yeah,
I
will,
I
will
also
steal
it
for
for
the
image
updater
and
then
and
then,
and
then
we
see
so
to
to
revise
the
ago
cd
release
selection
as
well.
So
I
think
because
this
is
this-
is.
J
I
think
I
think
it's
worth
probably
adding
it
to
some
documentation
to
say
if
you're
joining
the
argo
project
or
our
go
labs
project.
These
are
some
of
the
things
that
you
need
to
do
to
keep
things
similar
and
consistent
and
we
should
provide
the
plumbing
for
it.
So
if
you
need
to
create
a
plumbing
repository
where
it
all
should
live
so
that
everyone
can
use
this,
let's
do
that,
but
it
feels
like
everyone
would
benefit
from
this
and
we
might
as
well
put
it
in
one
place.
H
Yeah,
so
currently
it's
just
it
drafts
a
release
without
publishing
it.
F
H
And
that's
only
because
I
haven't
automated
the
the
change
log,
but
there
are
tools
to
generate
auto-generate
the
description
inside
here
from
a
change
log,
as
so
long
as
your
change
log
follows
like
a
a
specific
format
and
I
think
those
are
kind
of
improved
future
improvements
that
we
can
do
to
make
this
fully
automated.
A
That
concludes
the
meeting.
No
more
topics
in
end
of
meeting
exactly
right
now,
all
right
time
for
dinner,
so.
C
One
more
thing:
github
moderator.
A
A
A
To
you
know
kind
of
ask
for
feedback,
and
we'll
do
it
next
time
just
to
see
if
you
know
if
we
still
have
enough
topics
or
maybe
not
enough
topics
in
the
give
up
discussions
right
thanks
everyone,
one
more
time.