►
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
Hello,
welcome
back
to
an
update
of
ai
assist,
let's
first
talk
about
doctor
and
where
it
fits
into
the
strategy
that
I'm
working
on
so
right
now,
I'm
working
on
docker
files
because,
as
I
mentioned
earlier,
I
think
there
are
three
common
denominators
amongst
almost
all
projects.
It's
that
they're
dockerized
they're
deployed
to
kubernetes
and
they
are
using
cicd.
So
I
started
by
collecting
data
in
this
case
docker
fast.
A
I
need
to
parse
them,
but
there
was
no
good
parser
around
that
suits
machine
learning
purposes,
so
I
started
building
my
own
parser
and
then
I
figured
well
now
that
if
I
parse
here
it
would
be
good
to
also
lint
or
analyze
these
docker
files
to
see
what
is
actually
already
a
violation
of
it.
So
then
I
just
built
a
simple
set
of
rules
to
get
the
most.
A
Faults
out
of
those
files-
and
that
became
the
product
doctor,
which
I
decided
to
publish,
to
create
awareness,
for
it
also
to
be
able
to
use
it
myself
and
others
to
get
feedback,
which
I
got
more
on
that
in
a
sec.
Now,
the
next
step
is
to
start
pre-processing,
which
we
can
then
use
for
training
models.
A
Once
those
models
are
there
and
they
are
good.
We
can
feed
them
back
into
the
into
into
doctor
and
ultimately,
the
goal
is
to
be
able
to
create
a
docker
file
purely
based
on
the
repository
and
the
code.
That's
in
it
no
manual
interference
should
be
needed
to
create
a
docker
file,
and
what
this
will
do
is
it
will
allow
developers
to
get
rid
of
the
concept
of
having
a
dockerfile
on
the
repository
and
just
having
the
dockerfile
be
generated
during
the
build
time
the
dockerfile
stored
as
an
artifact
in
the
in
the
pipeline.
A
There
are
no
vulnerabilities
because
it's
constantly
updated,
basically
at
build
time,
the
best
docker
file
for
that
application
at
that
moment
is
determined
and
it's
built
according
to
that
docker
file,
that's
the
the
bigger
version,
so
it
will
be
an
assistant
that
will
create
docker
files
entirely
for
you,
however,
at
this
point,
yeah
I'm
working
on
docker,
which
is
the
the
rule-based
system
which
will
allow
me
to
parse
docker
files
like
a
lot
of
docker
files,
so
can
find
patterns
between
them
and
learn
what
makes
them
good
or
bad
and
see
how
we
can
optimize
them.
A
So,
as
I
mentioned,
I
got
some
feedback.
I
posted
on
social
media,
which
I
never
do.
I
post
on
reddit
and
linkedin.
I
posted
in
three
subreddits
python,
docker
and
gitlab,
and
I
got
quite
a
good
result
after
a
week,
so
I
got
27
new
stars
on
the
doctor
repository.
I
got
six
new
issues
of
which
two
were
users
admitted,
and
I
also
got
a
few
duplicates
which
I'm
not
counting.
Here
I
got
over
on
the
25
000
total
views
of
doctor
144
shares,
which
is,
I
think,
great
people
are
sharing
it.
A
A
So
there
seems
to
be
quite
a
bit
of
enthusiasm
for
this,
just
purely
the
parser
and
analyzer
itself,
and
I
think
once
I
get
to
this
phase,
it
will
become
much
more
powerful,
let's
emphasize
where
doctor
currently
lives
and
probably
will
be
so.
I
took
this
image
from
from
our
ci
pipeline
page,
and
this
is
the
standard
process.
A
A
developer
makes
a
new
branch
pushes
code,
the
pipeline
runs
and
it
fails
and
then
they're
gonna
change
push
code
fixes
and
what
doctor
does
is
it
will
automatically
resolve
issues
not
all
of
them
right
now
it
resolves
docker
file
issues
and
potentially
also
shell
issues.
A
A
However,
doctor
can
also
run
in
your
ide,
so
you
can
just
even
prevent
the
pipeline
from
failing,
but
this
is
where
it
currently
lives.
How
does
that
compare
to
container
scanning,
for
example?
Well
container
scanning
happens
after
the
build
and
in
this
way
by
analyzing
the
dockerfile.
Here
we
don't
have
to
spend
time
on
a
build,
because
we
know
it's
going
to
be
a
bad,
build,
let's
not
waste,
ci
minutes
on
that.
A
Another
tool
that
we
have,
that
is
basically
in
the
same
area,
is
the
infrastructure
as
code
scanning,
which
I
found
to
be
very
interesting
so
for
my
playground
project,
I
have
enabled
it-
and
this
is
the
result
on
my
faulty
docker
file,
which
I
know
that
it
has
a
lot
of
faults
in
it.
So
all
in
all,
we
got
four
violations
of
rules,
but
if
we
take
a
look
at
doctor,
doctor
will
report
a
lot
more
violations,
and
probably
some
of
these
should
be
included
in
doctor
as
well.
A
So
if
we
take
a
look
at
what
doctors
found
in
this
branch,
so
if
we
go
to
the
pipeline
with
the
doctor
results,
we
will
see
that
there
are
a
few
more
results
like
this.
One
verify
that
no
credentials
are
leaking
by
copying,
insensitive
files,
yeah
it's
doing
a
copy
dot
and
if
we
don't
have
a
proper
doc
ignore,
it
could
very
well
include
sensitive
files,
which
it
says
on
the
next
one,
and
this
one
is
critical.
Verify
that
build
arcs
doesn't
contain
sensitive
information.
A
There
is
a
build
arc
here,
which
says,
I
think
it's
api
token,
and
then
it's
asking
for
a
secret
or
it's
an
arc
secret
that
shouldn't
be
there,
because
those
build
arcs
get
stored
in
the
history
of
the
dockerfile.
A
So
yeah.
If
you
take
a
look
at
infrastructure
as
goat,
there's
a
lot
of
overlap
with
it,
but
it
also
goes
a
bit
further
than
it.
Maybe
we
can
even
replace
our
dockerfile
scanning
with
doctor,
and
the
last
part
that
I
want
to
mention
for
this
update
is
that
I've
released
version
1.4.0
for
doctor,
which
adds
a
lot
of
new
features
and
bug
fixes,
which
was
great.
A
It
was
a
lot
of
fun
to
actually
work
on
stuff
that
people
ask
for
next
week,
I'm
on
pto
and
after
that
I
will
continue
work
on
this
and
see
how
I
can
start
working
on
something
that
will
be
automatically
generating
the
code
for
the
dockerfile.
Thank
you
for
watching
leave
a
comment
down
below.
If
you
have
a
question
or
reach
out
to
milslak
bye.