►
From YouTube: Meshery CI Meeting (27th Jan. 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
A
A
B
You
hear
me
yeah
sorry,
roll
four,
I
I
was
trying
to
twas
something,
but
my
my
microphone
was
was
failing.
A
And
I
think
istanbul
is
now
installed
in
in
the
or
included
in
the
measure
project,
but
yeah
you
can
use
cypress
or
istanbul
to
to
create
unit
testing
or
if
you
are
creating
unit
testing
for
go
and
we
can
use
gold
as
the
game
as
the
language
to
create
those
tests
to
the
following
from
go
right.
Right.
B
Okay
and
this
this,
this
login
that
you
are
showing
and
this
code
code
report,
is
making
the
coverage
for
for
gold
and
for
and
for
javascript
right
right
now,
no.
A
This
is
only
for
javascript,
okay,
we
when
we
can
create
golang
test.
We
can
add
that
feature
to
this
code
report
in
order
to
to
measure
that
unit
testing
in
goal.
Also.
Okay,
okay,
thank
you
awesome
now,
thank
you
to
you.
So
I
will
add
that
that
we
can,
we
should
add
coverage
from
fort
unit
test
for
go
unit
test
in
order
to
be
included
in
the
in
the
report.
A
Thanks
jesus,
and
so
I
was
explaining
that
we
can
run
all
the
jobs
again
in
github
actions,
so
you
can
only
click
in
this
button
rerun
all
jobs
in
order
to
to
rerun.
If
something
fails
off,
if
there
is
a
flaky
test,
a
flucky
test
is
that
one
test
that
sometimes
fail
and
sometimes
pass.
So
if
there
is
a
flocking
test,
you
can
run
all
the
jobs
again
any
questions
about
this
new
action
or
trigger
that
you
that
any
of
you.
A
A
So
I
think
isuku
is
not
here,
but
he
is
commenting
that
we
can
use
this
github
action
in
order
to
to
publish
the
the
handle
the
hand
chart
of
measuring
in
the
ci.
A
So
in
order
that
we,
this
can
be
triggered,
we
need
to
push
to
master
when,
when
we
push
to
master,
the
new
chart
will
be
published
in
in
the
in
the
article
in
the
artifact
hub.
So
this
is
a
good
change,
because
it
will
be
all
automated
and
yeah
when
we
can
have
an
appear
from
icicle.
I
will
put
it
in
the
in
the
document.
A
A
They
are
failing
some
end-to-end
tests
related
to
ping
and
submit
console,
and
it
says
something
like
cross-origin
policy,
but
when
I
do
download
master
and
run
the
test
locally,
it
worked
well.
So
I
think
this
is
a
flucky
test
that
we
need
to
to
fix,
like
sometimes
it
fails
or
and
sometimes
pass
so
the
first
step
to
the
book.
The
error
is
to
see
the
logs
in
the
github
action
and
if
you
see
something
like
this,
maybe
it's
a
test
and
you
have
to
to
test
that
locally.
A
A
A
C
So
rudolph
to
repeat
that,
if,
if
you
want
to
run
before
you
submit
a
pr
potentially
like,
if
you
want
to
run
end-to-end
tests,
to
confirm
that
the
you
know,
checks
would
pass,
is
this
in
part?
What
you're.
A
B
Can
you
please
put
the
comments
duke
running
in
in
the
top
side
I
put
in
the
document,
make
room.
A
A
A
A
A
C
Well
now,
rudolph,
I
feel
kind
of
like
an
ignoramus.
I
I
probably
shouldn't
be
chatting
while
you're
presenting
and
that's
in
order
to
get
this
test
interface,
this
cyprus
or
the
in
order
to
get
the
underscore
pound,
slash
tests
or
the
cyprus
interface
that
that
that
that
becomes
available.
As
you
run
in
pm,
cy
open
right,
okay,.
A
C
A
And
yeah
this
is,
I
I
I
think
I
need
more
time
to
to
the
book
this
error,
but
this
is
a
way
to
to
see
what's
happening
in
your
locker
and
to
try
to
to
fix
that.
B
B
A
A
A
A
This
one,
so
we
can
debug
this
error
locally
in
order
to
identify
the
the
true
error
before
sending
a
pull
request.
B
A
We
can
yeah,
sometimes
it
blocks
the
pull
request,
but
we
should
fix
the
problem
always
before
merging
a
pull
request,
because
if
we
allow
an
error
in
the
pull
request
and
something
or
someone
has
to
fix
that
in
another
request,
so
yeah.
A
A
C
Refresh
my
memory
word
off:
we've
you've
you
produced
a
a
little
bit
of
a
documentation
on
this
around
you
produce
a
blog
post
on
sort
of
introducing
this
and
some
best
practices
and
then
you're
having
this
session
to
help
people
understand
like
hey.
When
did
you
submit
a
pr
and
a
check?
Fails?
Here's
you
know
you're
empowered
to
basically
rerun
those
same
checks
locally,
here's
some
here's
how
you
you
know:
spin
up
cyprus,
ui
locally
and
work
through
the.
C
So,
oh
sorry,
what
I
was
some
of
this
is
written
down,
and
but
I
don't,
but
I
wonder
if
we
yeah
yeah.
I
wonder
I
wonder
where
I
wonder
if
we
have
all
of
this
written
or
not
that
all
of
it
needs
to
be
written
down.
Rather
what
I
mean
is
hey:
where
would
we
most
commonly
point
people
to
for
troubleshooting
on
this?
C
I
wonder
if
we
wouldn't
he's
thinking
about
this
now
I
wonder
if
one
of
the
bots
that
we
have
shouldn't
like
point
to
a
dot
point
to
the
the
dock
that
or
that
has
this
recording
and
whatever
or
whatever
it
is.
You
know
like.
A
A
And
the
next
topic
is
that
a
we
have
fixed
the
netlife
builds
in
order
to
only
be
executed
when
queen
modified
docs,
for
example.
Here
in
this
port
request,
I
only
added
a
configuration
file
for
netlify
and
because
it
know
it
is
not
related
to
the
dogs,
it
will
not
be
triggered.
The
negligence,
for
example,.
A
A
I
have
one
question
for
you:
I
requested
to
activate
the
page
build
docs,
but
I
think
we
can
remove
that.
Okay
got
it
please
and
if
the
dco
bot
is
there
we
can
we
can
mark,
as
required.
Oh
nice,
okay,
I
put
that
in
here
in
the
document.
Also
we
shall
keep
dco
and
remove
page
build.
Please
got
it
very
good.
C
Well,
I
don't
know
if
I
don't
know
that
this
is
the
next
title,
but
what
you
just
said
about
intelligently,
you
know
kicking
off
certain
steps,
certain
certain
jobs
in
the
overall
workflow
versus
others.
C
I
think
that
was
like
one
of
the
last
comment.
Maybe
you
talked
about
this
earlier,
but
it
was
one
of
the
last
comments
that
asuko
had
mentioned
on:
building
the
helm,
charts
and-
and
I
don't
think
that
he
realizes
that
that
you
have
such
capability,
that
you
have
a
conditional
logic
in
workflows
to
be
able
to
only
execute
the
helm,
chart
action
if
there's
a
change
to
the
slash,
install
folder
or
some
logic
like
that.
A
Yeah,
the
the
change
or
in
netlife
builds
don't
affect
this
thing
because.
C
If
you
go
to
the
very
bottom
of
this,
I
thought
recently
like
that.
Okay,
it
must
be
in
a
different
I'll
point
out
his
other
comment.
Anyway,
you
might
be
able
to
provide
him
like
one.
I
think
that
it's
going
to
take
you
to
go,
do
the
chart
releaser
and,
as
you
do,
you
can
educate
him
that
the
that
action,
the
chart,
release
or
action
or
the
chart
itself
will
only
be
built
as
and
when
there's
a
a
change
to
a
file
under
the
slash
install
directory.
C
A
C
C
A
Yeah
when
isico
create
the
pull
requests
related
to
the
shutter
releaser,
and
maybe
in
that
purpose
we
can
continue
the
conversation
today
yeah
how.
C
A
C
A
A
C
Yeah,
the
the
thought
here
was
that
we've
been
taking
steps
forward
on
the
end-to-end
tests
and
on
code
coverage,
and
it's
pretty
neat
you
know
you're
able
to
see
either
at
a
pr
level
or
at
a
across
the
repo
sort
of.
So.
Where
are
we
at
how
how
how
little
coverage
do
we
have
or
how
much?
C
How
much
coverage
do
we
have
and
which
is
great,
and
I
thought
well
like
hey:
have
we
written
down
the
approach
and
the
fact
that
we're
you
know
we
have
a
central
place
where
we're
saying
hey,
we,
you
know
for
there's
about
40
something
repos
here,
there's
an
adapter,
there's
things
that
written
and
go
things
are
written
in
other
things.
How
do
we
do?
How
are
we
are
we
doing
unit
tests
and
go
like
to
jesus's
question?
Actually,
it's
been
a
recent
topic
of
conversation
on
some
pr's.
C
I've
been
asking
people
to
create
some
unit
tests
in
part
because
in
part,
because
it
takes
so
long
to
to
test
out
to
manually
test
out
the
pr
that
they
have
and
find
that
just
it
really
doesn't
work
like
it
should
that
anyway,
we
don't.
This.
Can
serve
as
a
spot
to
say
we
should
have
some
unit
tests.
We
should
probably
have
some
some
integration
tests
here,
we're
using
this
we're
using
that
some
cypress
there's
some
kind
there.
Some.
C
What
have
the
this
one
is
a
bit
higher
level,
and
you
know
it
might
articulate
things
like
our
desire
is
to
you
know,
is
to
have
an
80
coverage
or
something
something
or
like
hey
if
you're
going
to
achieve
the
silver
level
in
the
the
cii.
What
is
it
the
core
infrastructure
initiative?
If
we
achieve
that
next
level,
here's
here's,
you
know
a
percentage
that
they
look
for.
C
C
A
spreadsheet
maybe
depends
on
how
much
time
folks
have
and
how
far
along
we
get
that
where
we're
articulating,
where
we're
sort
of
highlighting
that
coverage
like
if
you
think
about
making
a
release
like
this
upcoming
release,
is
pretty
massive.
A
lot
of
new
any
number
of
new
architectural
components,
lots
of
new
functionality.
It's
wonderful!
C
C
And
so
like
in
the
the
fact
that
hey
there's
a
there's,
an
approach
and
strategy
and
sort
of
a
general
agreement
that,
like
hey,
we
shouldn't
be
merging
prs
that
are
failing
checks
occasionally
or
I've,
I'm
I
admit
to
being
faulty
on
that,
certainly
in
the
past,
and
even
now,
particularly
if
or
really
only
generally,
only
if
the
failure,
the
check
that
has
failed
has
nothing
to
do
with
the
code.
That's
in
the
pr,
then
it's
like!
Well,
it
wouldn't
matter
anyway.
C
That
check
was
already
failing
or
would
be
failing,
irrespective,
and
so
it's
like
okay
but
yeah,
if
someone's
submitting
something,
that's
causing
a
check
to
fail.
That's
a
you
know
anyway,
that
that
type
of
articulation
in
a
document
like
this
makes
sense
in
potentially
a
different
sheet.
What
we
would
say
is
hey
in
terms
of
like:
what's
the
what's
the
release
process,
how
do
you
make
a
release?
Well,
mechanically.
C
You
just
go
over
to
github
and
you
type
in
the
tag
that
you're
going
to
release
and
you
click
the
button
and,
like
all
this
workflow
happens.
But
when
do
we
know
and
sort
of
look,
do
we
look
at
to
code
cov
or
do
we
look
to
cyprus
or
we
do
do
we
look
to
a
spreadsheet
to
to
say
this
feels
pretty
good
like
we?
We
did.
We
did
some
significant
diligence
and
we've
been
being
kind
of
consistent
with
this
diligence.
C
Sometimes
it's
it
yep,
some
of
that
so
there's
testing
yeah
sure.
But
but
when
you
look
at
a
release-
and
you
say,
hey
release
manager,
if
someone's
playing
that
role
greek
green
light,
are
we
comfortable
or
kind
of
not
like
where's
our
comfort
level?
What's
the
risk,
you
know
that
that
release
manager
might
not
just
point
to
test,
but
they
might
also
say
well,
so
we're
looking
good
on
the
tests.
C
C
You
know
so
we
don't
necessarily
have
some
of
that
defined
kind
of
written
down
and
just
take
some
simple
github
issue
labels
to
and
then
and
then
when
we
say
well,
what
is
a
blocker,
it's
like
well
well,
a
blocker
is
when
things
just
don't
work
and
it's
like
well,
maybe
it's
okay,
if
that
section
of
the
code
doesn't
work
because
nobody
uses
it
or
whatever
the
so
so
yeah
yeah,
those
are
all
kind
of
things
to
go,
related
and
kind
of
going
in
there.
C
Okay,
the
document
started
the
last
the
document
that
the
title
of
that
document
could
end
up
being
either
master
test
strategy
and
release,
governance
or
release
process
or
release
practices
or.
A
C
E
Oh
bit
time
when
we
add
a
test
to
all
the
respective
projects
and
everything,
we
can
also
set
up
a
limit
that
every
pull
request
has
to
cross
so
that
we
again
strive
for
maintaining
that
code
quality.
So
that
is
something
that
can
be
a
part
of
this
release
so
like.
If
every
pull
request
has
to
get
merged,
it
has
to
cross
some
minimum
threshold
value,
like
whatever
we
set
with
the
consensus.
A
C
It's
possible
that
there
are
there's
possible,
there
are
exceptions
to
the
rule
or
like
and,
and
some
of
that
can
be
written
down
as
well.
It's
like
hey,
look,
that's
not
a
that's
a
it's
a
it's
a
very
high
priority,
but
technically
not
a
blocker
like
how
do
we
you
know?
Should
we
go
ahead
and
just
you
know
vote
on
that.
Is
that
that
sort
of
thing
or
is
it?
You
know,
there's
a
little
bit
of
yeah.
The
last
word:
governance.
E
E
Yeah
so
like
so,
what
I
suggest
is
that
initially
we
should
first
strive
to,
let's
say
cover:
let's
say
if
we
take
40
percent
to
be
our
ideal
goal.
So
what
we
can
do
is
first,
we
should
start
writing
all
the
tests
for
the
respective
repositories
and,
let's
say
we
achieve
40
percent
of
the
tests.
E
According
to
the
coverage
reports,
and
from
that
point
onwards
we
know
that
code
coverage
has
to
increase
with
some
particular
delta,
with
every
pull
request
associated
to
it,
and
it
should
be
greater
than
or
equal
to
at
least
40..
There
shouldn't
be
any
code
which
worst
case
reduces
the
test
service
right.
So
it's
got
to
be.
There
has
to
be
some
positive
delta.
It
can
be
of
whatever
threshold
we
want,
but
it
should
be
at
least
above
40,
because
that
is
that
one
level
that
we
already
have
achieved
before
we
set
this
condition.
A
E
So
I
I
think
that
is
one
thing
that,
because
now
that
we
have
coverage
so
again
the
entire
goal
of
having
code
coverage
and
everything
is
just
that
we
could
improve
the
code
quality
more
and
more.
Over
and
above
with
all
the
projects
associated.
A
Yeah
thanks
for
proposing
that
she
bank,
I
think
it's
good
for
implementing
in
the
measure.
B
I
want
to
know
something
like
a
path
to
follow
in
order
to
start
starting
proficient
helping
with
with
this
working
group,
because,
for
example,
me
personally,
I
don't
have
experience
creating
continuous
integration.
B
So
I
don't
know
what
is
the
first
thing
to
learn
so
so
I
can
help
or
I
can
start
helping,
and
maybe
I
am
saying
that
you
are
adding
node.js
test,
so
I
can
start
writing
nodes.
Yes,
for
example,
but
maybe
the
next
step
should
be.
I
don't
know,
create
an
action
or
a
little
action.
Something
like
that.
So
that
is
my.
A
A
A
I
I
have
the
link
here
in
in
the
code,
but
I
think
there
is
a
block
with
with
images
about
this
content,
but
this
is
a
good
start
to
to
writing
tests
in
measuring.
So
here
I
explain
how
to
write
the
first
stairs
the
first
test,
sorry
about
the
provider
ui
screen
and
how
to
run
the
test.
That
is
the
the
comment
that
you
just
write
jesus.
A
So
then
I
recommend
to
to
watch
these
videos
in
order
to
be
familiar
with
with
this,
with
cyprus
and
with
this,
and
then
I
think
we
can
create
a
a
test
with
with
cyprus.
A
Yeah
with
that
article
and
also
with
these
videos-
and
I
think
with
that
you-
you
have
a
good
start
if
you
have
a
another
question
to
how
to
implement
a
new
test
that
is
not
implemented
yet
you
can
reach
out
and,
and
we
can
work
together.
Okay,.
A
E
What's
the
current
approach
to
build
the
stuff
and
push
it
on
like
docker
on
any
other
distributions
and
downloads
that
we
have
like
either
it
has
to
be
in
a
zip
version
or
something
like
that?
What's
our
current
approach
with
it
approach
with
that
sorry
to
like
build,
and
so
let's
say:
if
we
hit
up
a
version,
let's
say
like
we
finally
decided
to
release
version
0.5.
E
So
what's
the
approach
that
we
follow
to,
you
could
say
build
out
all
the
various
builds
to
be
downloaded
and
to
be
installed
or
probably
push
up
our
own
docker
image?
What's
the
current
processes
that
we
follow
is
it
is
the
process
even
automated?
Until
did
we
do
it
like
something
you
know,
so
is
it
like
automated?
As
of
now.
A
A
C
Yeah
yeah
schubert.
We
should
begin
to
articulate
those
in
the
well,
so
there's
a
build
and
release
strategy
document
that
defines
a
number
of
things.
C
I
mean
it'll,
interrelate,
probably
heavily
with
the
master
test
strategy.
Okay,
I
call
it
mass
all
right.
We
use
the
word
master
test
strategy
because
in
acknowledgement
we
could
use
a
different
word
other
than
master
it
doesn't
matter.
But
to
is
like
an
overarching
like
we've
got
so
many
repos.
We've
got
a
lot
of
different
languages,
but
a
lot
of
the
approach
would
be
the
same
like
if
we
were
to
say
hey.
We
really
feel
comfortable.
C
Like
you
know,
the
general
goal
is
to
have
zero
blockers
and
less
than
five
percent
or
less
than
ten
percent
high
priority
known
high
priority
issues
with
a
certain
test
cut,
like
whatever
the
combination
of
like
how
we
feel
good,
about
making
release.
That's
probably
going
to
apply
to
like
most
of
the
repos
and
most
of
the
projects,
and
so
that
master
test
strategy
would
articulate
those
things,
and
we
would
you
know,
as
people
contribute
in
different
places,
the
same
sort
of
policy.
C
E
C
Stable
release
channel
is
all
automated
save
for
the
decision
to
the
manual
decision
to
say:
let's,
let's
cut
one,
it's
time
to
cut
a
release.
Let's
do
it
even
the
the
version
the
number
versioning
there's.
It's
auto
suggested
that
since
we're
following
semantic
release
or
semantic
versioning,
there's
a
anyway
go
read
the
go,
go,
read
the
building
release
strategy,
doc,
it's
it'll
tell
you
a
lot
of
what
I'm
saying
now.
C
One
thing
that
I
do
want
to
get
to,
if
I
can
draw
your
attention
this
way
is
well,
is
nighthawk
get
nighthawk
and
the
building
of
nighthawk,
which
no
small
thing
and
for
as
much
as
I
want
to,
and
it's
something
we
should
give
a
lot
of
attention
to
it.
Get
nighthawk
has
a
project
we'll
accomplish
a
few
different
things,
but
centric
to
some
of
the
effort
that
goes
into
it
is
ci
in
the
building
of
it.
D
Yeah,
so
I
promised
yesterday
to
put
more
pressure
on
me
not
too
much.
I
started
before
the
meeting
I'm
way
behind
than
I
was
before
christmas,
but
yeah.
So
now
I
have
a
laptop
just
for
night,
walk
with
16
gigs
with
ubuntu
18,
and
I
can
switch
it
to
windows
on
the
mac.
I'm
not
sure
if
I
would
be
able
to
build
it.
I
just
pick
up
my
mac
from
the
service
and
they
didn't
fix
it,
but
it
would
probably
start
without
so
the
display
is
not
working.
They
didn't
find.
D
China
is
not
delivering
now
in
these
days.
So
that's
fine!
Okay,
a
part
of
this
uses.
I
understand,
I
have
to
build
it
and
also
we
we
need
to
have
a
pipeline
that
is
picking
up
nighthawk
and
a
pipeline
that
is
actually
doing
the,
which
I
think
you
already
did
the
one
with
get
nighthawk
that
that
one
with
the
with
us,
with
the
c
plus
plus
extension
written
in
go.
You
already
have
a
pipeline
for
that
right
or
not.
C
Well,
yeah,
not
real
yeah,
with
the
with
the
for
the
golang.
That's
inside
of
that
repository
and
the
repository
that
we're
speaking
of
everyone
is
it's
either
it's
in
it's
in
the
layer.
It's
if
I
oh
slash,
nighthawk
go
or
or
it's
go
nighthawk
I
forget
which
one
the
reality
is
we
will
probably,
if
we
haven't
already,
we
will
probably
change
that
to
be
get
nighthawk
like
the
repo
name,
probably
get
nighthawk
the
go.
That's
in
there
is
is
fairly
small.
I
think
there
is
workflow.
C
I
think
that
builds
that
that
go,
which
is
the
very
the
easy
part.
The
hard
part
is
that
we'll
need
we'll
need
to
go
digest.
How
it
is
that
envoy
does
its
builds,
so
that
then
we
can
understand
how
nighthawk
does
its
builds,
so
that
then
we
can
say
good,
we'll
augment
those
nighthawk
builds
with
different
target
architecture,
different
target,
os's
different
target
new
packages,
so
they're
really
like
in
terms
of
this
us
or
that
that
repo
actually
building
nighthawk,
I
could
be
mistaken
and
there
could
be
a
workflow
in
there
already.
D
Yes,
they
are
building
it
when
they
build
the
envoy
right
now.
I
didn't
get
got
to
that
step.
Yet
I
I'm
still
behind.
E
D
D
Building
or
also
how
it
is
already
built,
both
both
of
them
yeah
yeah,
so
well,
we
will
need
to
I'm
just
talking
about
by
the
memories,
because
I
didn't
got
where
I
was
where
I
was
before.
D
There
was
a
night
walk,
hawk
version
and
that
one
was
built
when
the
envoy
was
built
and
yeah.
So
what
I
would
like
to
to
see
is
when
the
envoy
is
getting
built.
Where
is
the?
What
actually
all
the
steps
that
I
do
are
done,
because
I
didn't
sew
them
all?
It
is
with
circle,
ci
and
something
else,
and
also
with
basic
basil,
bezel.
D
F
Don't
have
too
much
advance
on
this
right.
C
Yep,
there's
a
okay,
so
let
me
I'm
gonna
we'll
if
we
run
out
of
time
I'll
continue
we'll
continue
this
in
the
slack,
but
there's
a
a
google
doc
for
the
get
nighthawk
project.
That's
floating
around
slack
and
project
I'll.
Try
to
I'm
trying
to
find
it
yeah
here
this
one
right,
yeah
there.
It
is
very
good
and
so
yeah.
She
won't
jump
in
and
yeah
great
time
to
jump
in
and
help
there's.
C
So
the
some
some
initial
steps
are.
The
goals
are
to
produce
different
distributions
of
nighthawk.
Nighthawk
is
written
in
c
plus
plus
when
nighthawk
is
built,
as
that's
a
it's
a
separate
project,
but
but
this
one
get
nighthawk
will
really
be
the
face
of.
There
is
no
project
site
for
that
open
source
project.
There
is
you
know
it's
we're
doing
just
that,
we're
trying
to
help
distribute.
C
It
is
one
of
the
one
of
the
goals
and
it's
the
first
thing
to
start
with
in
part,
because
mesherie
itself
uses
nighthawk
and
it
needs
a
better
distribution
than
it
has.
We
have
a
hard
time
getting
it
built
and
getting
it
inserted
into
measuring.
So
in
this
dock,
that
rodolfo
is
sharing
is
there's,
I
think,
there's
an
area
where
we
took
some
action
items
and
these
those
right
there
are.
Oh
actually
it's
not
it's,
not
that
documented
it's
it.
I
don't
think
it
is.
E
It's
like
we
need
to
like,
have
it
built
in
various
operating
systems
and
then
try
to
test
it
out.
Is
it
the
required
goal
right.
C
Yeah,
yeah
and
so
we'll
use
you
know,
github
work,
get
up
actions
and
workflow
to
be
able
to
do
that.
So
one
of
the
things
is
just
digesting.
How
is
nighthawk
being
built
today,
and
the
part
of
the
complexity
is
that
nighthawk
is
as
a
project
is
a
sub
project
of
envoy
and
as
such,
it
also
reuses
envoy's
toolchain
for
its
builds.
C
So
in
essence,
when
you
understand
nighthawk's
build
process
and
its
tooling,
you
also
will
then
understand
envoy's,
build
process
and
tooling,
and
we
don't
necessarily
have
to
improve
on
that
or
to
significantly
change
that
like
we're,
not
necessarily
looking
to
influence
and
have
them
change
it
rather
we're
trying
to
all
augment
with
yeah,
maybe
getting
this
into
the
hands
of
a
bunch
of
other
people
to
make
it
convenient
to
get
at
nighthawk.
E
C
Specifically
from
meshary
to
get
at
nighthawk
as
well
we're
going
to
do
a
number
of
other
things
with
nighthawk
some
data
science
things.
So
there's
there's
some
there's
a
couple
of
faucets
facets
to
this
project,
a
couple
of
aspects
to
it,
but
the
initial
crux
of
it
is
like
yeah
churning
out
a
bunch
of
builds
due
to
or
and
even
packaged
things
like.
You
know,
to
the
extent
that,
to
the
extent
that
a
an
rpm
made
sense
or
to
the
extent
that
whatever
that
is.
E
Something
that
can
be
downloaded
and
fired
up,
something
like
that.
E
C
Nice
and
then
yeah
so
there's
just
some
initial
tasks.
Steps
are
like
hey,
just
read
the
readme
for
nighthawk
and
how
it's
built
read
the
readme
for
how
envoy
build
is
done
start.
You
know
the
the
nighthawk
go,
repo
that
we
have
here,
embarrass
yourselves
embarrass
you
with
a
bunch
of
workflows
that
don't
work
and
don't
you
know
just
start
trying
to
build
the
sucker
and
the
the
individual
that
is
the
core
maintainer
behind
nighthawk,
his
name's
otto
and
he's
in
our
slack
auto
vendor
vanderschoff.
C
If
you,
if
you
search
for
auto,
you
know
you'll
be
there
and
the
the
performance
channel
is
kind
of
the
one
that
because
nighthawk
is
a
performance
character,
characterizer,
that's
sort
of
the
one
where
we're
talking
about
get
nighthawk
and
you
know
create
some
issues
on
the
repo.
If
you
like,
and
that
way
you
can
be
clear
about.
C
Like
I
mean
whoops
in
some
respects,
we
should
just
create
some
issues,
an
issue
that
says
produce
a
nighthawk,
build
a
nighthawk
build
or
distribution
for
compatible
with
centos
produced
a
nighthawk
build
compatible
with,
and
we
should
first
go
look
to
avashek
the
the
base
image
that
we're
using
for
mashri.
That's
sort
of
the
first
goal
like
just
because
we
want
to
get
that
get
consistent.
Nighthawk
builds
placed
into
the
mesherie.