►
From YouTube: CNB Sub-Team Sync: BAT
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
I
don't
see
any
new
faces,
stylus
updates.
A
You
bring
up
so
we
have
the
initial
implementation
of
the
profile
go
back
ready.
I
think
there
are
a
couple
of
questions
or
issues
open.
One
is
writing
integration
tests.
A
What's
the
plan
there,
because
shell
scripts
obviously
don't
work
like
baskets,
won't
work
on
windows
and
then
we
have
a
very
different
interface
for
windows
profile
day.
I
think
we
have
dot
profile.
batch
files
and
windows.
A
I
I
don't
know
how
that
interface
works
to
be
fair,
so
that's
still
going
to
be
open,
but
yeah.
I
think
that's
pretty
much
it
in
terms
of
status
updates.
B
The
bill
pack
does
doesn't
pass
detection
if
we
can't
find
bash
anyway.
So
is
that
a
big
issue.
B
Is
that
better
now,
yeah
yeah?
I
was
saying
that
the
profile
there's
like
profile
functionality
in
the
existing
life
cycle
from
the
previous
api
right
for
windows.
Basically-
and
this
build
pack
does
not-
I
guess,
replace
that.
So
that
would
be-
and
I
guess
definitely
like
a
net
functionality,
loss.
A
B
A
B
A
A
A
B
A
But
yeah
that's
I'll,
ask
them,
but
on
salesforce
I
I
know
because
joe
was
the
one
who
was
more
concerned
about
this
functionality
being
lost.
Is
that
anything
make
any
strong
offers
on.
B
I
mean
on
the
technically
we
I
we
just
care,
we
don't
have
windows
containers,
so
we
just
care
about
linux.
Obviously,
from
a
spec
thing
like
it
is
kind
of
sad
to
lose
windows,
but
also,
I
wonder
how
many
people
are
using
this.
B
Like
I
just
don't
know
how
much
how
many
people
in
cmb
are
using
windows,
I
I
feel
like
window
support
was
very
much.
A
vmware
was
a
target
customer
use
case
yeah,
but
you
know
like
if,
if
we
actually
there's,
there's
always
the
like
people,
we
don't
know,
I
guess
technically
that
aren't
part
of
things,
but.
B
In
some
ways
I
feel
like
we'll
have
to
think
about,
or
I
think
what
the
maybe
natalie
knows
or
yeah.
I
think
if
we
wanted
this,
we
would
have
to
look
at
how
it's
implemented
in
life
cycle
right,
yeah
and
kind
of
reverse
engineer
that,
because
I
imagine
adding
whatever
lifecycle
is
doing,
is
probably
not
super
complicated
right
like
once.
We
look
at
the
go
code.
A
A
A
A
Yeah
and
replacing
that
for
linux
was
possible,
but
we
lost
some
functionality
there
as
well
like
if
you're,
creating
functions
for
some
reason
in
bash
and
then
using
functions
in
subsequent
shell
commands.
That's
not
something
we
support,
so
something
we
could
have
supported.
A
B
Is
that
because
we
maintain
support
for
windows,
98
turns,
I
think
it's
just
because
powershell
has
larger
dependencies
to
kind
of
pull
it
in.
But
I
know
it
was
like
a
discussion
with
micah
like
I'm
trying
to
recall,
but
he
was
kind
of
I
don't
know
if
he
still
works
at
vmware,
but
he
was
kind
of
the
main
driver.
A
B
A
A
B
Now
do
you
have
thoughts
on
I
mean
we
can
do
it
after.
I
guess
the
declarative
built
by
testing,
but
the
natalie's
slack
threat
on.
I
guess
the
spec.
A
B
A
A
A
It
works
for
everything
yeah,
it's
it's,
it's
nothing
more
specific!
So
you
you
can
declare
files
like
these,
so
I've
not
written
anything.
Actually.
I've
just
added
the
necessary
pack
and
container
structure
test
executors,
which
I'll
explain
in
a
while
what
they
are,
but
it's
built
on
top
of
this
tool
called
venom,
which
is
a
general
purpose,
declarative
integration
test
tool,
so
you
can
define
files
like
these
and
it
will
run
them
for
you
and
it's
got
a
bunch
of.
A
A
So
like
you
can
you
can
write
something
that
uses
these
executors
and,
like
just
reuse
it.
So
it's
like
a
function
essentially,
so
you
can
have
created
the
following
ones:
there's
a
something
that
gives
you
back
a
random
image:
name,
that's
compatible
with
a
clean
image
command,
something
that
lets.
A
You
run
back,
build
with
some
predefined
arguments
and
something
that
lets
you
run
contain
a
structure
test
which
is
another
tool
that
google
maintains
that
lets
you
easily
define
again
declaratively
defined
integration
tests,
but
just
for
containers,
so
you
can
do
things
like
run
a
command
and
check
the
output
check
for
the
existence
of
certain
files
check
for
the
file
contents
check
for
licenses,
environment
variables
or
the
container
config.
So
you
can
check
for
labels,
environment
variables,
exposed
ports
and
so
on.
A
A
B
A
B
For
these
assertions
here,
why
are
you
testing
that
the
bill
packs
should
we
call
these
piccata
ones.
A
Because
I'm
here
I'm
running
a
specific
builder
and
I
want
to
check
if
certain
build
packs
were
detected
and
used.
A
Yeah
so,
like
the
pack
executor
that
I
have
provides
like
the
logs
the
exit
code
from
pack,
the
actual
pack
command
that
was
used
to
run
it
and
back
inspect
output.
A
A
A
B
A
Something
yeah
so
like
not
that's
from
the
output
of
back
build,
though,
for
container
tests.
What
I
end
up
using
is
just
this
container
structure
test,
which.
A
Has
the
like
sort
of
things
that
I
just
talked
about,
so
it
returns
a
exit
code,
zero
or
one,
but
it
also
returns
this
output
json,
which
I
again
pass
it
back
so
like.
If
you
wanna
check,
if
a
certain
test
passed
or
failed,
you
can
also
do
that.
A
A
B
I
see,
can
you
in
container
test
just
like
move
around
on
the
file
system?
I
assume
as
well
and
not
execute
what
oh,
just
like
check
existence
of
stuff
on
the
file
system.
A
And
even
for
the
command
test,
like
it's
got
a
pretty
good
support.
So,
like
you
can
run
some
setup
commands
before
you
actually
run
your
main
command
and
then
you
can
check
the
expected
output,
error
or
exit
code,
or
you
can
also
set
environment
variables
before
the
command
is
run
and
you
can
set
up
so
tear
down
command
as
well.
A
A
No
we're
not,
but
this
was
just
an
exercise
to
see
if
we
can.
A
A
A
A
B
Yeah,
the
downside
of
that
I
guess
is
like
you
would
have
to
update
it
every
time
yeah.
How
often
is
that.
B
A
A
B
A
A
B
We
have
a
bunch
of
we
used
to
have
a
tweeted
tool
called
hatchet
for
classic
build
packs,
which
was
this
ruby
runner
that
would
basically
orchestrate
and
run
stuff
on
the
roku
platform
for
pun
and
integration
testing.
And
then
we
wrote
a
thing
that
kind
of
interacts
with,
like
the
docker
socket
to
kind
of
do
that,
and
I
think
and
wall
wrote
a
thing
in
russ
that
does
something
similar
with
like
sockets
and
other
things
in
rust,
with
some
rust
library.
A
B
A
Oh
okay,
which
one.
B
Oh
just
these
are
the
these
are
like
the
tests
for
our
maven
bill
pack.
Okay,
so
we
have
like
a
test
runner
that
basically
calls
and
runs
pack
some
built-in
fig
and
then
I
think.
A
B
I
I
think
this
is
so
the
first
one
is
the
built-in
fig,
I
think,
that's
stack,
heroic,
build
packs.
20
is
like
the
builder
okay
and
then
the
second
one's
the
app
I
think,
dope
packs
vec,
is
just
use
these
build
packs.
So,
okay
use
the
heroku
jvm
build
pack,
which
is
not
the
current
build
pack
right
and
then
crate
is
use.
This
build
pack
so
put.
A
B
A
Like
that's,
that's
what
this
library
is
so
like
you
can
define
your
own
libs,
so
they're
like
fixtures-
I
don't
know
if
trust,
has
some
similar
concept
but
like
reusable
pieces
of
test
code
that
you
just
want
to
run
again
and
again.
So
the
syntax
that
you
see
here.
A
Same
thing
for
like
like
it,
also
allows
you
to
range
over
things,
so
you
can
define
an
array,
and
once
you
have
your
like
this
library
or
custom
executor
defined,
you
can
range
over.
That
array
run
like
run
your
custom
executor
for
each
of
those
things
and
then
check
the
output
code
sharing
works.
It's
just
like
you
have
to
essentially
figure
out
somewhere
to
keep
these
files
right.
A
A
B
Yeah
there
there's
a
lip
scene
brs
or
something.
A
B
You
imagine
you'd
want
to
define
this
somewhere
yeah
and
then
reuse
it
right
so
like
in
every
single
venom
test.
You're,
not
writing
that
out
each
time
right
so
like
you
would
probably
want
to
write
a
thing
that
defines
this
and
then
basically
use
that
and
like
use
that
I
guess
lib
kind
of
venom,
file,
yeah
and.
A
B
Yeah,
I
mean
in
theory
like
a
v
whatever
of
this.
If
we're,
actually
wrapping
venom
yeah,
potentially,
we
could
implement
our
own
plug-in
system
on
top
or
something.
A
A
A
A
A
B
A
I
mean
yeah
so
like
I
wanted
to
replicate
everything
that
occam
did
but
make
it
venom
native.
They
use
venom,
but
they're
like
it's
like
another
orchestration
layer
on
top
of
venom,
and
then
they
add
support
for
container
structure
tests
and
back
separately
and
rather
than
these
being
three
separate
things
I
just
wanted
when
them
to
be
the
top
thing
and
to
include
back
and
right.
B
A
B
B
B
A
B
A
B
Yeah,
no,
I
mean
I,
I
think
this
is
cool.
B
I
I
wonder
for
ease
of
use
like
if
we
do
want
to
do
the
wrapping
thing
like
you're,
suggesting
yeah,
it's
more
overhead.
We
have
to
keep
it
updated,
but
I
feel
like
it
just
feels
super
gross
to
like
have
to
vendor
some
thing
in
every
bill
pack
and
then
just
like
what
happens
when,
like
potentially,
we
might
change.
Like
that's
a
thing
right,
it's
like,
I
think
we
might
potentially
update
or
change
these
lip
things,
especially
as
pack
changes
as
whatever
maybe
we'll
have
more
opinions,
as
it's
being
used
more
too.
A
A
B
A
That's
achieved
it
bundles
the
venom
binary,
so
you
can
just
update
it
by
downloading
the
binary
vendors
contains
a
copy
of
container
structure
test
contains
a
copy
of
these
files.
So,
like
every
time
I
have
to
update,
I
just
update
the
container
image
rather
than
everything
else
again.
This
is
not
something
I
want
us
to
support.
I
was
just
showing
that,
like
this
was
an
experiment.
They
did.
A
Mean
I
wanted
to
show
it
off
and
ask
whether
it
looks
sane
and
whether
we
want
something
like
this
and
to
start
the
discussion
on
this,
because
I
feel
like
we
started
this
rfc
and
then,
like
nothing,
happened
beyond
that.
So
I
just
wanted
to
continue
on
it
like
show
a
proof
of
concept
to
motivate
that
rfc
that,
like
doing
something
like
this
is
doable,
and
it's
not
a
lot
of
work.
B
Like
I
actually
don't
know
how
joe
is
doing
integration
tests
for
his
bash
bill,
packs
yeah
and
I
know
salesforce,
where
joe
is
also
doing
other
bill
pack
stuff.
He
has
literally
like
in
the
same
bill
pack
thing
like
python
bash
and
go
code,
and
so
it's
just
like
something
like
gymnastic
would
probably
be
nice.
If.
A
B
A
A
Guys,
let
me
show
you
so
this
is
this.
B
Yeah
well
because
I
feel
the
the
oh
yes,
the
parallel
wait,
but
does
it
auto
split
the
stuff
for
you.
A
A
A
B
A
A
A
B
Yeah,
I
guess
partly
it's
just
like
my
bill
pack
builds
generally.
Don't
need
to
be
the
speediest
thing
like
most
people
are
willing
to
accept
some
performance
hit
for
like
builds
versus
run
time.
Like
I
definitely
pref.
I
definitely
if
I
had
to
pick
care
more
about
performance
runtime,
not
that
I
don't
care
about
performance
for
builds,
but.
B
I
feel
like
that
probably
doesn't
matter
that
much
for
build
time.
Yeah
run
time's
gonna
be
a
different
issue,
but.
B
A
B
B
Yeah
there's
you
can
definitely
use
mucil
muscle.
However,
you
pronounce
it
yeah
like
we,
we
compile
our
stuff
with
muscle
for
production.
Okay,
because
that
way,
we
can
then
use
it
on
multiple
stacks
and
not
be
dependent
on
the
lib,
the
geolocy
underneath
for
obvious
reasons.