►
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
Cool
so
welcome
everyone
to
the
distribution
demo
for
the
big
september,
2nd
2021.
A
A
A
During
the
tagging
phase,
we
update
all
the
method
as
a
related
file,
so
in
omnibus
gitlab
this
this
will
mean
the
various
version
files
which
is
used
to
point
to
different
components
of
gitlab,
which
we
need
to
pull
to
build.
Gitlab,
like
this
version
of
gitlab,
will
use
the
specific
shy
of
italy.
This
specific
share
of
gitlab
our
course
is
of
like
pages
and
etc.
A
Four
charts
this
means
updating
the
ca
variables.tml
file
where
we
set
all
this
version
related
information.
A
This
comes
from
an
order,
tradition
like
what
have
what,
if
we
want
to
fix
gitlab.com
when
gitlab.com
is
down
like
we
want
releases
to
be
done
from
a
different
instance,
so
that
we
can
fix
gitlab.com
if
it
ever
go
down
by
creating
a
new
version.
So
we
we
continue
that
till
date,
all
the
releases
are
done
from
dev.gitlab.org.
A
A
If
there
are
some
artifacts
to
be
built
and
pushed
they
build
and
push
to
the
dev
registries,
or
if
these
are
packages,
we
push
to
a
specific
private
package
cloud
repository,
so
essentially
everything
gets
pushed
to
a
gitlab
internal
space,
whether
it
be
a
package
registry,
whether
it
be
a
docker
registry.
A
All
of
this
because
gets
pushed
to
gitlab
internal
spaces
and
when
the
package
of
when
gitlab
version
is
ready
to
be
released,
release
managers
run
the
published
task
on
the
published
checkups
comment
where
the
remaining
manual
tasks
of
this
fireplace
gets
automatically
run.
A
So
now
we
want
to
add
operator
to
the
mix
and
operator
brings
a
new
new
dependency
between
components
in
the
sense
that
operator
actually
actually
requires
health
charts
to
be
available,
because
one
of
the
jokes
in
the
operator
release
pipeline
is
fetching
the
helm
charge
so
for
releasing
an
operator
corresponding
to
a
gitlab
version
or
a
github
charge
version.
A
A
Okay,
I
believe
folks
can
see
my
screen
yeah
yeah,
so
this
is
one
of
the
tag
pipelines
for
operator
serosa,
one
beta-
and
this
is
the
job
I
mentioned,
which
actually
pulls
the
supported
chart
versions.
A
So
if
we
are
to
bring
operators
to
the
official
release
process,
this
means
the
automatic
part
of
the
release,
the
job
that
gets
run
when
a
tag
is
pushed.
A
If
we
don't
want
to
do
that
right
now,
do
we
just
have
a
manual
published
task
like
the
tagging
phase?
Won't
do
anything
but
just
have
a
manual
job
that
will
be
run
when
publishing
happens,
or
do
we
do
something
else.
So
all
these
questions
needs
to
be
answered,
but
before
that
before
any
of
those
we
want
to,
we,
we
will
have
to
find
a
way
so
that
the
charts
which
is
not
has
been
published
but
has
been
tagged.
So
the
tagging
phase
is
complete.
A
How
can
we
make
an
operator
pipeline
in
dev.gitlab.com
use
these
charts
for
us
to
do
any
validations
before
actually
publishing
something
to
the
users?
So
for
every
component
we
do
some
sort
of
validations
that
what
we
are
releasing
actually
works
before
we
push
it
to
the
public
user.
So
it
is
essentially
why
we
have
a
two
phase
release
process.
A
A
We
should
be
able
to
push
operator
manifest
to
a
nuclear
internal
space.
We
should
be
able
to
verify
it
works
as
expected
and
run
unit
tests
or
integrations
or
whatever
we
want.
So
that
we
can
confirm
when
we
publish
it
to
the
a
public
registry
and
when
user
pulls
it,
they
actually
get
a
working
piece
of
artifact.
A
So,
like
from
what
I
see,
I
don't
think
we
have
a
dev
counterpart
for
operator.
Yes,
everything
happens
in
dot
com
project.
So
please
please
correct
me.
If
I'm
wrong,
I'm
I'm
not
100
sure
I
I
did.
I
saw
a
double
counterpart
and
the
pipelines
are
essentially
firearm
for
that
kind
of
game
like
there
is
no
control
once
the
pipeline
has
been
started
once
a
tag
has
been
pushed,
it
essentially
goes
through
all
of
these
stages.
A
In
one
go,
so
we
don't
have
a
two-phase
release
process
for
operator,
yes,
and
we
will
want
to
bring
that
so
this
is
kind
of
the
context
of
what
we
might
want
to
do
to
bring
operator
release
also
to
release
stores
if
we
have
to
do
a
manual
one
for
the
time
being,
many
of
these
steps
can
be
removed
like
we
don't
want
to
bring
the
business
registration,
we
can
just
start.
If
an
operator,
we
can
create
an
operator
tag
from
the
last
stage
of
a
charts
release.
So
everything
gets
automatically
done.
A
We
can
do
all
those
workarounds
for
now
if
you
want
to.
But
if
you
want
to
hook
this
to
the
official
release
tooling,
we
will
have
to
transform
operator
ca
pipeline
to
use
a
two-phase
release
process
with
a
gitlab
internal
validation
system
and
they
publish
manual,
publish
to
so
jason.
Do
you
have
any
comments
on
this
general
idea
or
what
is
what
you
had
in
mind.
C
Sure
so,
let's
break
this
down
into
a
few
bits
that
we
have
to
worry
about.
Yeah
first
off
the
operator
is,
is
similar
to
the
cng
that
it's
waiting
on
something
else's
asset
right,
so
in
the
cng
we
actually
have
it
trying
to
consume
the
assets
from
the
omnibus
runs,
so
that
we're
not
doing
it
over
and
over
and
over
again.
C
This
one
in
particular
is
different
because
we're
not
stashing
it
somewhere
in
another
repository
yet
right.
So
the
way
to
deal
with
the
pull
charts
situation,
where
do
I
get
the
assets
that
I
stash
are,
is
what
we'll
have
to
figure
out
in
regards
to
that
one
right.
The
fact
is,
we
have
to
have
a
tag
in
helm
with
the
content.
The
way
it
is
for
us
to
have
the
ability
to
generate
a
turbo
or
pull
it
from
somewhere
that
we
published
publicly,
because
that
still
builds
off
the
same
process.
C
Second,
yes
right
now,
this
does
not
have
a
dev
counterpart.
There
is
no
non-visible
version.
We
will
at
some
point
need
to
have
that,
for
the
purposes
of
security,
we're
going
to
have
to
have
a
security
branch,
we're
going
to
have
to
the
dev
branch
to
include
into
the
release
processes
that
that
much
is
still
the
same,
because
in
the
end,
because
this
relies
on
assets
from
other
things
before
it,
those
things
don't
exist
in
gitlab.com.
C
C
A
Yeah,
so
one
one
thing
I
I
kind
of
thought
of,
but
gitlab
recently
got
support
for
handcuffs
registry,
so
technically
as
part
of
health
charts
values.
When
it
gets
tagged,
we
can
push
it
to
a
dev
registry
so
whether
that
works
for
us
or
not,
I
haven't
checked,
but
I
remember
seeing
a
release
post
where
it
says
we
have
now
support
for
hand
registry.
A
So
if
we
push
helm
charts
to
a
dev,
they
will
have
hand
charts
registry.
It
means
full
charts,
can
fetch
it
from
like
fitted
by
your
heading
sets.
But,
as
you
said,
we
we
at
least
have
a
workaround
for
it
like.
Instead
of
fetching,
we
can
just
build
the
packages
when
needed,
but
one
other
interesting
situation
that
health
charts
and
operator
brings
is
the
fact
that
they
are
not
version
locked
with
gitlab,
so
health
chart.
A
Success
is
not
locked
to
gitlab
versions,
which
means
we
can
release
new
versions
of
helm
charts
without,
depending
on
a
new
new
gitlab
version,
but
they
vice
versa,
always
triggers
a
new
release
like
when
there
is
a
new
gitlab
version.
It
will
create
a
charged
version
like
whether
or
not
there
have
been
any
changes
in
charge.
A
new
gitlab
version
means
a
new
gitlab.
Charts
version
will
be
created.
A
Interesting
thing
is
finding
out
what
the
next
release
for
charts
right
now
is
not
an
ideal
way
of
doing
it.
Like
b
parts
get
tagged
messages
we
parse
the
gitlab
version
from
which
we
compare
like
gitlab
version.
Like
is
this
a
new
gitlab
major
version?
Then
we
bump
the
major
version
component
of
charts
version.
A
This
should
be
the
charts
version,
so
we
are
doing
such
a
focus
for
finding
out
health
charts
right
now,
when
operator
follows
suit
and
does
the
same
with
charts
version,
we
will
have
to
do
something
similar
to
find
out
what
should
be
the
next
operator
version
like
because
we
don't
know
if
operator
has
released
a
new
version
on
its
own
without,
depending
on
charts,
charts
releases,
I
I
did
check
and
a
delivery
team
is
actually
maintaining
a
json
metadata
of
all
the
releases
like
forever
release.
A
C
C
C
C
When
we
get
an
update
to
the
available
charts,
we
may
not
want
to
be
specifically
going
okay,
well,
14
3
came
out
so
we're
going
to
make
1.3
of
the
operator,
because
the
operator
currently
has
the
ability
to
actually
have
three
patch
releases
so
we're
intentionally
making
it.
So
people
have
upgrade
and
downgrade
paths
that
are
same
right.
A
Okay,
but
the
the
problem
there
is,
if
you
are
using
release
tools
to
release
the
only
input
it
gets,
is
gitlab
version
like
we
compute
everything
else.
From
that
version
we
compute
what
should
be
the
next
start
version
from
an
input
gitlab
version
yeah
like
if
we
have
to
use
this
only
for
minor
and
pass
releases.
A
C
C
C
A
Enough,
so
let
me
ask
this
from
a
different
angle:
how
do
you
see
a
new
operator
version
gets
released
like
who,
let's
say
we
use
chat?
Ups.
A
C
So
for
4ga
for
effectively
1.0
or
even
0.9,
whatever
we
call
it
right
both.
I
don't
know
that
full
automation
is
actually
required
for
the
initial
ga
release
and
I
I've
tried
to
call
that
out.
So
I
apologize
if
that
message
is
not
clear
for
the
time
being.
If
we
need
to
let
them
do
everything
and
then
we
whack
it
and
it
spits
out
a
version.
A
C
C
A
A
Like
yes,
we
it's
just
what
changes
is
who
starts
the
process
when
we
think
the
ca
is
ready,
we
can
just
hook
everything
to
release
tools
so
that
that
trigger
comes
from
a
release
tools,
action
note
of
manually
pushing
a
git
tag.
I
I
think
it's.
It
makes
sense
for
a
first
iteration,
okay,
so
that
that
kind
of
serves
for
what
what
should
happen
for
this
release.
C
C
Do
we
know
how
it
functions
and
do
we
want
to
rely
upon
it
until
we
do
so?
No
not
to
anyone,
but
personally
I
don't
know
yet.
If
somebody
does
have
that
immediate
familiarity,
please
jump
in
if
we're
not
comfortable,
saying
that
this
is
capable
of
replacing
our
lab
pages
based
distribution
mechanism.
I
don't
know
that
we
can
rely
on
it
as
part
of
the
release
process.
C
Yeah,
that's
my
only
concern.
I
do
feel
it
could
be
extremely
useful,
especially
in
the
case
of
dev,
at
which
point
that
particular
fetch
script
would
just
be
like.
Instead
of
going
to
get
the
get
live
repository
from
charts.gitlab.io,
it
ends
up
getting
it
from
dev
dash,
charts
dot,
get
like
dial
right.
We
just
literally
change
the
url
that
we
add
when
we
do
helm.
Rebo,
add.
E
Yeah
yeah
I've
played
with
a
bit
and
I've
like
pushed
our
chart
to
it
and
installed
from
it
and
stuff
like
that,
I
would
say
in
terms
of
like
being
able
to
stash
and
install
the
chart
from
it,
it
seems
to
work
fine.
I
would
say
that,
like
it's,
it's
big
issue
right
now
is
like
the
pathing
is
pretty
long
to
get.
E
E
A
Cool,
so
that
that
will
essentially
mean
an
update
to
the
charts
ca
to
add
a
job
which
pushes
the
build
charts
to
endeavor
registry
like
before
publishing,
so
that
that
is
something
we
can
do
in
parallel,
not
tied
to
this
work,
but
can
be
used
in
when
full
automation
is
in
place.
So
that
actually
makes
sense
to
me.
C
C
A
Okay,
so
essentially
it
requires
an
infrastructure
setup
in
dev
so
that
we
can
run
this
as
part
of
tagging
before
publishing,
okay,
exactly
right,
yeah.
That
also
makes
sense
so
and
when,
when
everything
is
ready
and
when
the
ca
is
in
a
good
position
to
do
the
two-phase
release
thing,
we
can
start
looking
at
adding
code
to
release
tools
which
will
do
all
the
necessary
steps
of
creating
a
stable
branch.
Updating
the
charts
versions,
file
pushing
a
tag,
and
we
will.
A
We
will
need
some
sort
of
waiting
mechanism
in
the
operator
pipeline
to
wait
for
charge
to
be
ready.
Similar
to
how
starts
has
to
wait
for
images
to
be
ready.
We
can,
we
can
do
a
waiting
mechanism
to
ensure
charts,
is
fetchable
and,
and
then
operators
publish
can
continue
so
that
that
seems
to
be
the
road
we
want
to
travel
down
the
road
so
for
four
ga.
A
What
I
am
going
to
do
is
one
write
all
of
this
down
like
document
how
the
official
release
will
look
like
when
we
are
at
the
full
automation
stage
to
start
looking
at
getting
a
dev
infrastructure
for
to
access
a
counterpart
to
run
tests
to
spin
up
a
cluster
and
all
those
things
three
enhance
the
ca
so
that
the
two
phase
release
can
work,
but
with
us
manually
pushing
attacks
not
not
released
towards
doing
anything
yet,
but
we
will
be
creating
a
git
tag
and
pushing
it,
and
the
pipeline
should
look
exactly
like
how
it
would
when
release
tools
does
the
same
thing
and
as
a
next
iteration.
A
When
this
much
of
automation
is
in
place,
we
can
look
at
bringing
release
tools
into
the
mix
like
figuring
out.
What
is
the
next
operator
version
automatically
updating
the
charge
versions,
files
creating
stable
branch,
pushing
comments,
pushing
tags
all
of
those.
So
this
seems
to
be
what
I
think
the
different
iterations
we
can
take.
D
I
have
a
question
kind
of
related.
You
just
mentioned
it,
so
the
charts
version
file.
It's
a
in
my
mind,
it's
a
sticky
subject
because
it's
basically
a
matrix
of
like
which
combination
of
versions
should
be
in
that
file,
and
how
do
we
want
to
maintain
it
so
right
now
we
have
three
versions
in
there.
Do
we
just
trail
the
tip
of
three
major
releases
or
like
what?
D
A
Okay,
I
think
the
current
current
situation
is.
We
have
last
patch
releases
of
last
three
minor
versions,
whether
that
means
any
version
in
between
is
supported
or
not,
I'm
not
sure
like.
What
do
we
expect
that
that
three
lines
to
convey
as
a
message,
but
you
actually
bring
up
an
interesting
point?
What,
if
I
have
a
specific
charts
version-
and
I
want
to
know
which
operator
version
I
should
use-
is
how
how
do
we?
How
can
a
user
know
that.
C
Right,
so
the
metadata
in
the
operator
itself
will
have
the
ability
to
declare
which
versions
it
has.
Second,
we
may
have
to
replicate
the
version
mapping
document
very
short
period
like
I
don't
love
it,
but
we
have
release
notes.
We
have
version
mapping
capability,
so
there's
that
and
effectively
we
want
to
be
following
our
release
processes
and
our
support
timelines.
C
Therefore,
it
is
expected
that
the
last
three
minor
releases
worth
of
patches
are
supported.
So
if
a
patch
release
is
issued,
that
should
result
in
a
patch
release
of
rails,
which
does
containers
which
does
charts,
which
then
turns
around
and
does
the
same
thing
for
the
operator.
Does
that
mean
it's
going
to
be
annoying
yeah?
It
does
kind
of
mean
it's
going
to
be
slightly
annoying.
C
C
That's
not
impossible.
There's
a
couple
of
ways
to
do
it.
Does
it
mean
that,
because
we
have
three
versions
and
not
one
that
it's
more
complicated
to
know
the
version
you
have
installed?
Yeah,
that's
that's
true.
There's!
No
denying
that.
A
One
one
doubt
I
have
like
14
3
2
got
released.
Does
that
mean,
like
operator,
got
a
new
version
new
patch
version?
Also?
C
We
support
the
last
patch
revision.
That's
currently
released
right
if
we're
intentionally,
especially
if
it's
a
security
release,
if
we're
intentionally
adding
to
the
number
of
things
that
are
available
within
the
operator's
bundles,
because
for
us
to
say
the
operator
supports
this,
we
actually
have
to
bundle
the
chart
tarball
inside
the
image.
D
So,
essentially,
on
every
tagging
of
the
get
louder
rails
we
practically
we
have
to
trigger
the
operator
rebuild
at
some
point.
Whatever
the
chain
of
events
is
happening
between
and
take
that
tip
and
leave
the
rest
of
the
tips
alone,
as
they
are
so
it's
kind
of
like
bringing
the
modification
into
the
tree
every
single
time.
So
the
pipeline
is
not
just
reading
the
repo.
It
may
actually
need
to
modify
the
recall.
A
D
A
A
I
mean
this
delivery
team
has
a
metadata
repository
which
is
supposed
to
do
this,
like
we
maintain
json
files
for
each
releases,
which
maps
to
which
gitlab
version
it
has
which
omnibus
get
laboratory
with
cng
tag
it
has
so
that
is
supposed
to
access.
That's
that
single
source
of
truth,
but
I'm
not
sure
if
release
tools
currently
use
that
information
yet
like
we
are
maintaining
that
those
files,
but
whether
we
are
using
that
anywhere
in
release
process.
I
am
not
entirely
sure.
C
Is
right
now,
that's
the
trick
right
is
the
charts
version
file
is
basically
a
register
of
these
are
the
versions
that
we
know
are
currently
the
latest
tip
right.
How
is
that
consumed
in
the
operator?
Yeah?
Here's!
The
thing
is:
if
we
don't
need
to
commit
it,
then
we
don't
need
to
commit
it,
but
we
need
to
know
what
those
are.
C
A
D
Oh
this,
actually,
this
can
be
solved
like
if
we
want
to
have
that
information
we
can
just
publish
as
part
of
the
pipeline.
You
know,
publish
it
back
into
the
pipeline
artifacts
and
you
have
it
along
with
a
release.
So
I
don't
think
that
that's
the
big
problem,
it's
like
it's
whether
we
do
want
to
split
that
process
of
decision
making,
which
versions
go
into
that
into
its
specific
place
and
okay.
C
I
need
to
update
the
chart
versions,
and
these
are
the
ones
that
should
have
I'm
going
to
write
the
chart
version
files
commit
with
ci,
skip
and
then
tag
the
version
and
make
any
modifications
it
needs
to
make
to
metadata
bits,
and
then
it
pushes
that
commit
with
the
tag
to
the
repository
then
triggers
the
actual
release
process
ci,
which,
in
the
release
process,
is
not
altering
anything
that
pipeline
itself
doesn't
alter.
It.
C
E
D
D
A
Issue,
okay,
so
this
is
a
case
of
which
pipeline
wins
and
updates
the
master
branch.
The
chart
starts
version
files
in
the
master
branch
right
like.
A
A
A
Whether
this
is
the
latest
version
of
note
and
do
the
master
branch
updation
only
if
it
is
right,
like
after
tagging,
a
an
operator
version,
we
need
to
like
similar
to
how
we
update
the
version
mapping
file
in
charts
that
gets
updated
in
the
stable
branch
right
or
that
gets
updated
in
the
master
branch.
We
need
something
similar
to
happen
for
charts
versions,
file
in
operator,
so
for
version
mapping.
E
D
C
C
D
It
off,
but
they
will
know
in
advance
that
they
will
be
producing
three
of
them
so
until
they
have
they
don't
publish
that
file
and
once
that
has
been
done,
that
will
be
part
of
that
release
process.
Okay.
Now
we
commit
that,
like
again,
it
puts
the
manual
gate
on
a
different
side
like
I
just
mentioned
the
manual
gate
at
the
end,
and
this
will
be
the
manual
gate
at
the
front.
E
C
So,
basically,
though,
whether
it's
run
the
pipeline
once
after
everything
is
done
right,
like
do
all
the
security
releases
for
everything
else
and
then
trigger
a
pipeline
via
release
tools
or
whatever
for
the
actual
operator
or
run
three
separate
pipelines.
That
then
result
in
this
file
being
updated
and
then,
after
that
file
is
fully
up
to
date,
then
run
the
release
pipeline
for
the
operator
we're
putting
an
extra
synchronous
step
in
place
that
writes
the
file
when,
in
reality
run
the
three
wait.
A
time
run.
D
C
C
That
is
still
a
lockstep
on
them.
Whether
we
write
the
versions
to
a
file
literally,
doesn't
matter
yeah
yeah,
because
if,
if
they
wait
for
all
of
the
pipelines
to
complete
they're
tagged
and
now
we
can
actually
pull
that
information
from
the
tag.
So
writing
it
to
a
file
and
then
pulling
that
file
into
that
pipeline
is
actually
extra
steps.
D
A
Personally,
if,
if
it
is
between
two
wasted
operator
tags
versus
release
managers
remembering
to
do
something
manually
after
everything
has
completed,
I
will
pick
the
wasted
operation
tags
and
note
overload
release
managers
to
do
something
like
they
have
to
keep
it
in
mind.
Complete
everything
then
run
the
operator
publish
defi.
I
don't
want
us
to
put
that
load
on
release
managers.
A
A
E
That
might
be
the
easiest
thing
for
a
first
step
and
then
also
like
you
have
add
that
check
to
the
operator,
but
then
also
you
have
it
only
initially
that
we're
only
doing
operator
releases
on
publish
as
like
a
first
step
so
that
we
know
at
that
point
in
time
that
there
are
going
to
be
all
those
tags
because
we're
at
the
we're
at
the
publish
phase
at
that
point
yeah
which
and
then
you
know
the
next
steps
would
be
we'd
have
to
we'd
want
to
figure
out
something
better
in
the
future.
A
A
A
C
Okay,
yeah,
so
the
the
trick
the
trick
still
comes
down
to,
even
if
our
pipeline
has
the
is
there
something
in
am
I
the
latest
version
right?
You
still
have
the
problem
of
race
condition.
It
might
be
a
liz
version
at
that
time
right.
This
is
the
nature
of
the.
This
is
the
nature
of
the
beast
that
we
currently
ship
three
versions
of
the
chart.
C
C
Yeah
the
downside
to
that
is,
if
you
downgrade
the
operator,
it
doesn't
necessarily
know
how
to
downgrade
right.
A
C
D
One
thing
to
throw
into
this
conversation
and
that,
like
again,
I
could
be
coming
from
lack
of
context
here,
but
okay,
we're
shipping
three
bundled
versions
of
chart
with
the
operator
right
now
and
I'm
assuming
that
was
done
for
the
air
gap
systems
and
things
like
that.
So
they
don't
have
to
pull
externally.
D
But
if
we
built
the
capability
of
fetching
dynamically
for
the
non-air
gap-
environments,
whatever
version
they
specify,
it
could
be
a
way
out
for
situations
where
you
know.
Customer
has
a
very
specific
version
already
in
and
they
are
trying
to
upgrade
to
the
next
release
and
things
like
that.
Okay,
so.
C
D
It
solves
customer
issue,
it
doesn't
solve
our
issues
because
for
the
customer
to
come
from
a
specific
version
and
go
to
a
very
specific
version,
they
need
to
figure
out
which
operator
provides
that,
and
that
is
from,
like
just
a
customer
perspective
to
me.
That's
what
it
sounds
like
a
complication.
C
Oh
yeah,
really
even
doing
that
is
dangerous
in
its
own
right,
because,
as
we've
seen,
people
set
the
gitlab
version,
even
though
they
shouldn't
within
the
chart.
I'm
running
chart
version
5,
but
the
image
is
from
12
point
x,
I'm
like
yeah.
No,
that's
not
going
to
work
at
all.
So
what
so?
That's
that's
the
problem.
What
we
face,
so
I
I
get
it
yeah.
A
Of
summarize,
before
we
wind
up,
I
think,
for
at
least
for
the
first
release
for
ga
or
the
first
iteration
of
release,
we'll
be
looking
at
manually.
Doing
this
and
pushing
a
git
dash.
A
I
will
look
at
making
this
current
ca
pipeline.
A
two
phase
release
where
pulling
charts
and
building
manifest
is
automated,
but
uploading
manifest
and
creating
a
release
is
a
manual
job.
So
we
have
some
time
to
verify
whether
the
manifest
actually
work
or
not.
I
will
look
at
setting
it
up
that
way.
A
I
will
write
all
of
this
down,
as
the
current
issue
is
sent
to
me,
is
to
define
a
release
process.
So
all
of
this
needs
to
be
documented,
so
first,
first
code
related
task
will
be
implementing
two
phase
releases
in
the
current
pipeline,
with
without
any
new
jobs
or
anything
making
the
release
part
of
the
current
pipeline
a
manual
one.
A
E
A
A
C
C
You
could
even
like
technically,
we
can
separate,
have
a
separate
pipeline.
That's
just
the
one
job,
that's
just
when
it's
a
triggered
pipeline
and
it's
got
the
incoming
version.
Just
go
update
version.
So
the
end
of
this
tag,
literally
just
fires
off
there
and
goes.
Oh,
I
have
a
new
tag
for
you
and
it
goes.
Does
it
matter
right
now,
aka,
if
it's
four
versions
back,
we
don't
care
yeah.
If
it's
one
of
the
latest
three
that
we
know
about.
C
C
A
A
E
E
We
could
just
keep
it
in
our
back
of
our
heads
for
later,
but
I
had
an
idea
just
around
like
later
down
for
when
we
off
automate
that,
if
we're
trying
to
like
figure
out
what
version
we're
gonna
bump
the
operator
for
it,
that
we
could
just
have
in
the
main
branch,
a
version
file
that
you
know
gives
shows
our
intent
of
what
the
next
major
minor
is
and
that
the
release
tools
when
we're
at
the
point
of
release
tools.
E
Doing
this
only
ever
cares
like
it
checks
that
file,
basically
only
ever
cares
about
doing
patch
releases
based
on
that
version.