►
From YouTube: GitHub CI Discussion
Description
We discuss GitHub's announcement and how it impacts the Package stage.
A
Yeah,
so
we
Tim
and
I
had
a
chat
and
we
wanted
to
get
together
to
talk
about
github
recent
announcement
on
CI,
CD
and
automating
through
actions.
It's
you
know,
actions
that
they
utilize
to
do
that
and
I
thought
they'd
be
some
useful
chats
about
it
that
we
can
have,
and
particularly
around
the
I
think
there
was
a
marketing
team
did
an
actual
product
comparison.
Did
you
see
that
come
across
anywhere
ten?
There.
B
Was
a
comparison
of
Azure
DevOps
that
was
being
done,
that
I
saw
and
then
I
saw.
Jason
did
some
work
in
this
in
the
group
presentation
which
I'll
share
this
link
now
in
the
chat
here,
I'm
just
at
a
high
level,
but
I
yeah
would
be
valuable,
I
think
for
us
if
at
least
to
watch
the
video
and
then
just
to
discuss
them
on
a
higher
level
points
would
be
helpful.
Yeah.
A
B
Sure
well,
I
guess
I
can
give
my
initial
impression.
It
looks
really
cool
I
mean
it
seems
like
it's.
You
know
it
doesn't
come
out
for
another
few
months
in
broad
support,
but
it
definitely
seems
full-featured
I,
think
it's
in
line
with
what
we
saw
from
github
previous
package
registry
release
that
they're
really
focusing
on
the
network
effect
and
being
able
to
release
features
that
it's
not
just
you're
doing
this
as
a
private
organization.
It's
like
everything
that
you're
doing
should
be
consumable
by
the
github
community,
which
I
think
is
a
really
cool,
differentiator,
I.
B
B
It
certainly
seems
like
they're
pushing
that
and
the
packaged
registry
similar
it's
like
host
your
NPM
package
on
github
instead
of
NPM
registry
and
then
you'll
get
you
know,
you'll
have
all
the
github
comments
and
history
and
you'll
be
able
to
you
know
copy
or
your
documented
or
your
commands
right
from
the
github
page
and
search
from
github.
So
I
like
all
that
stuff,
I
really
really
like
Nick
and
I
had
a
debate
or
not
a
debate,
but
tonight
we
were
talking
to
Emilia
about,
should
we
include
documentation
on
the
container
registry.
B
Page
Nick
was
like
I
actually
like
having
the
documentation.
Next
to
what
you're
going
to
be
doing
and
github
double
down
on
that
like
when
you
look
at
their
actions
page,
you
could
see
all
they're
sort
of
based
template
files
for
each
language
or
right
there
and
the
main
page
I
thought
that
was
really
cool
too.
So
a
sign
that
we
could
include
doc,
contextual
documentation
in
our
UI
I
thought
was
another
big
takeaway
for
me.
I
should
stop
talking
here.
A
You
should
it's
great.
Thank
you
very
much.
I
found
the
last
couple
of
releases,
the
product
releases
that
github
has
done
to
be
pretty
interesting
because
they
do
have
their
own
style.
The
way
they
do
things
that
doesn't
necessarily
jive
with
it's
not
like.
We
would
copy-paste
what
they're
doing,
even
if
we
didn't
have
something
already
right,
like
just
wouldn't
fit
well,
with
the
way
that
Gill
out
those
things
in
terms
of
the
application
and
the
user
experience
my
kind
of
stuff,
but
some
of
it
is
really
really
cool
like
that.
A
Inline
documentation
idea
seems
like
a
good
thing,
there's
a
couple
of
other
examples
of
that.
Even
rekt,
simple
things
for
me
that
I've
experienced
going
through
Giller,
but
you
know
in
my
three
or
four
months
here
has
been
like
well
I,
want
to
edit
this
page,
but
I
have
to
then
go
into
the
repo
go,
find
the
page
and
then
click
web
it.
It
could
be
cool
as
a
as
you
get
lab
user,
with
an
account
to
be
able
to
just
have
the
edit
button
just
go.
C
A
A
B
I
think
one
thing
that
has
been
resonating
with
me
recently
has
been
people
wanting
to
use
our
service
with
either
J
frog
or
Sona
type
or
some
other
service
right,
and
the
one
thing
that
resonated
me
with
the
github
announcement
was
that
they
they
allow
for
auto,
rebuild
or
auto
published
dependencies
based
on
web
hooks
like
so.
If
your
npm
public
package
was
a
bump
to
version
it'll,
auto,
download
or
auto
rebuild
the
project.
B
I
think
I've
seen
a
bunch
talk
to
a
bunch
of
users
that
are
asking
for
that
sort
of
thing
like
if
they're,
using
docker
image
latest.
If
the
latest
gets
bumped,
pull
that
latest
version
in
and
and
run
their
CI
CD
pipeline.
So
those
sort
of
web
hooks
could
be
something
that
I
haven't
necessarily
thought
too
much
about
I
thought
that
was
lower
priority.
But
I've
been
hearing
that
from
from
users
as
an
important
piece
and
then
the
other
piece
is
like
yeah.
They
they
were
showing,
which
I
think
we
could
do
the
same
thing.
B
We
have
the
option
to
have
very
secret
value
variables,
environment
variables
respected,
and
we
have
that
same
thing,
but
we
don't
necessarily
make
it
easy
to
connect
to
J
frog
or
to
sono
type.
It's
a
little
bit
hard.
You
have
to
actually
like
connect
to
J
frog
and
then
use
the
J
frog
COI.
Maybe
that's
how
github
does
it,
but
I
think
easing
that
path
between
services
could
be
valuable.
B
A
Yeah-
and
he
was
talking
similarly
and
and
I-
had
a
conversation
with
him
because
I
know,
Greg
is
a
good
friend
of
mine,
but
I
might
a
conversation
would
have
said
separately,
just
sort
of
saying
you
know
what
is
it?
That's
holding
you
back
from
switching
to
get
lab.
You
know
because
he's
very
much
about
open
source
and
very
much
like.
Oh,
we
use
this,
but
he
uses
a
product
and
I
said:
why
do
you
use
it?
What
do
you
like
about?
He
said
because
it's
open
source?
That's?
A
Why
and
I'm
like
okay,
so
then
get
lab
and
he's
like.
Well,
if
you
added
this,
that
would
be
what
it
was
so
like
that
to
me
it
was,
and
that
was
all
tied
into
the
way
maven
setup
right
now,
and
it
was
part
of
your
conversation
and
I'll
fish
that
out
of
our
chat.
But
it's
it's
that
other
thing
we
like
there's
a
little
it's
funny,
because
we
offer
a
pretty
good
product
in
in
maven.
A
In
the
case
of
maven,
that's
relatively
mature
I
feel
like
compared
to
say
NPM
support,
although
that's
getting
there
with
a
lot
of
hard
work
from
people
which
is
awesome.
Thank
you,
but
there's
it's
like
little
matters,
little
edge
cases
where
I
feel,
like
some
companies,
you're
just
so
dependent
on
some
part
of
the
solution,
they've
developed
in-house
that
we
don't
offer
that
and
then
they
kind
of
go
yeah,
but
I
can't
switch.
Because
of
this,
you
go
okay.
If
we
just
added
that
and
we
get
this
range
of
customers
so
I
know.
B
B
So
what
J
frog
does
is
allow
them
to
have
one
centralized
master
settings
file
and
from
there
they
have
the
logic
that
says:
okay.
First,
look
at
the
maven
public
repository
then
look
at
bootstrap,
then
look
at
J
frog,
and
then
you
know
and
following
that
logic
was
really
valuable
for
for
him
and
having
some
sort
of
authentication
mechanism.
That
was
to
him,
that
was
the
biggest
problem
to
solve
was
how
to
have
a
single
authentication
to
rule
them
all.
And
then
how
do
you
have
this
logic
baked
in
for
your
team?
B
So
we
don't
currently
support
that
I,
don't
think
we
currently
are
just
or
if
we
do
we're,
not
helping
you
to
navigate
that
because
our
documentation,
this
point
says
like
okay,
your
settings
file
just
point
to
the
gitlab
bread
registry
and
you
can
pull
your
packages
from
at
the
project
level
or
at
the
group
level.
But
maybe
that
is
something
that
we
could
do
by
just
adding
in
an
additional
line
into
the
settings
file,
I'm,
not
sure
I'm,
doing.
D
Like
to
share
just
quickly
about
artifactory
decentralize,
and
so
that
they
do
have
three
posit
reason
as
far
as
the
the
maven
repository
goes,
it
is,
it
does
follow
the
repository
convention,
like
the
naming
convention.
Inc,
you've
got
your
release,
your
distribution,
your
snapshot,
so
now
that
I'm
sorry
to
have
an
interrupted
youth
fever
right
before
you
I
was
just
curious.
How
would
we
handle
that
on
packages
where
we
don't
have
say
repositories
like
snapshots
right
where
we
don't
have
to
worry
about
the
mutation
where
maven
would
be
different
than
NPM?
D
It
started
raining
so
basically
with
maven.
You
have
different
repositories
right.
You
have
one
where
your
artifacts
will
go
to
say
your
distribution
repository.
Then
one
will
go
to
your
snapshot
and
whatnot,
and
so
the
way
that
one
release
will
be
handled
on
my
event,
see
to
the
released
repository
will
be
handled
differently
than
what
is
in
the
snapshot
with,
and
that's
because
there
are
different
ways
of
the
weather.
D
The
artifacts
will
go
to
different
directories
based
on
the
release
type
right
and
that's
what
you
so
you
can
figure
in
your
in
your
XML
for
your
dependencies
on
NPM.
However,
we
would
only
have
a
few
set
of
repositories
we'll
have
if
we
were
to
go
the
centralized
route
where
we
would
aggregate
packages
based
on
whether
or
not
anything
has
changed,
we
wouldn't
rely.
We
would
need
to
rely.
We
would
not
need
to
rely
on
so
many
different
repositories.
We'll
have
one,
that's
local
one!
That's
central
and
one
that's
aggregated
right
for
cached.
Rather
one.
B
I
think
that
that's
true,
it
will
be
different
in
each
case.
I
think
what
this
person
this
person
was
referring
to
is
the
logic
for
when
to
pull
dependencies
and
J
frog
sort
of
acting
as
the
proxy
for
how
those
dependency
gets
pulled
like
the
logic
of
saying
pull
from
NPM
registry,
then,
if
that's
not,
there
then
go
to
bootstrap.
If
that's
not,
there
then
go
to
get
lab.
B
If
that's
not,
there
then
go
local
so
sort
of
having
that
logic
built
in
and
it
would
be
different,
I
guess
across
different
repositories,
because
naturally
the
public
ones
are
different
and-
and
like
you
see
mentioned
like
maven,
has
the
concept
of
snapshots
and
PM
doesn't
necessarily
have
that
concept,
but
I
think
in
the
end,
it
is
still
just
we're
just
pushing
things
to
certain
places
and
pulling
them.
So
it's
the
giving
the
flexibility
to
have
to
have
that
logical
thing
could
be
something
that
that's
helpful,
I
think.
D
We're
getting
there
as
I
think
we
can
actually
do
something
similar
to
that
just
with
what
we
have
as
far
as
the
docker
thing
having
latest
and
then
having
to
rebuild
one
good
case
that
you
had
discussed
earlier,
I've
seen
that
come
to
support
a
bunch
of
sounds
and
we've
offered
workarounds
where
we
would
just
need
to
retrigger
a
build
so
I
think
with
having
to
check
for
the
contents
of
a
repository
for
a
change.
I,
think
that
would
be
the
cache
we'd
say
see
if
anything.
B
We
could
probably
go
a
long
way
with
documentation
and
just
thinking
about
how
to
solve
those
problems
now
that
we're
talking
to
users
and
identifying
them
now
that
we
have
Gregg,
saying
well,
I'd
love
to
be
able
to
set
the
logic
for
how
to
you
know,
pull
dependencies
that
you
know
seven
different
levels:
okay!
Well,
we
probably
could
do
that
with
get
web
CI.
If
we
you
know,
if
we
have
a
good
example,
maybe
we
could
share
that
with
him.
I,
don't
know
what
anyone
else
think
of
anything
different
yeah.
A
I
mean
I
think
we're
a
little
bit
off
the
CIC,
the
github
announcement
subject.
This
is
actually
really
good,
so
I
didn't
want
to
get
in
while
everyone
was
chatting,
but
because
this
is
really
good
information,
and
thank
you
very
much
offering
that
Sara.
That
was
that
it's
great
I
think
Steve.
You
might
want
to
say
something
said
something
quickly
on
that
or
no
you
don't
have
to.
If
you
don't
want
to.
A
There's
something
to
investigate
right
there,
but
let's,
let's
sort
of
refocus
again
on
the
discussion
around
the
the
CI
CD
announcement.
I
think
we
were
sort
of
talking
about
the
way
that
github
implements
things
and
then
we
sort
of
started
talking
about
some
of
the
way
the
packaging
works.
I
did
share
the
link
inside
the
document
for
the
comparison
between
github
actions
in
Gila,
and
so
people
can
check
that
out.
It's
public
I
mean
on
outside,
so
anyone
can
get
to
that
who
happens
to
watch
this
video?
B
Feel,
like
I've,
been
talking
a
lot
and
one
of
the
things
that
I
love
about
github
is
that
they're,
so
developer
focus
like
it
definitely
seems
to
me
like
the
engineers
are
deciding
how
to
build
it.
It's
like
an
engineer,
focused
product,
so
I
am
curious
to
hear
other
people's
opinions
if
they
saw
it
and
yeah
I'm
curious
to
listen
for
a
little
bit
but
I'm
happy
to
provide
more
context
and
producti
stuff.
If
that's
helpful,
to
Ian.
E
Think
they've
definitely
kind
of
taken
the
approach
of
understanding
their
users
and
adapting
a
pipeline
that
fits
their
users
need
I,
think
just
kind
of
how
they're
talking
about
how
they
looked
at
it,
that's
kind
of
a
shallow
view.
So
we
are
it
kind
of
sounded
like
they
were
implements
sorry
implementing
a
solution
that
matched
their
current
workflow
I.
E
Think
we
have
an
opportunity
because
of
kind
of
the
unique
position
that
get
lab
has
to
give
a
better
experience
in
general
and
especially
because
we're
doing
that
kind
of
generative
research
we
can
kind
of
supersede
them
in
that
way.
So
they're
trying
to
you
know
bring
everything
under
one
umbrella.
We
already
did
that.
So
we
have
the
opportunity
to
get
this
like
really
seamless
integration
that
actually
solves
user
base
problems,
so
I
think
that's
kind
of
what
I
gathered
is
it.
E
A
Maybe
when
you
have
that
level
of
investment,
it's
a
little
easier
to
put
a
bunch
of
people
in
something
and
we're
sort
of
growing
everywhere.
It's
not
really
how
I
see
it.
Github
is
currently
doing
everything
they
can
to
catch
up
to
us
as
offering
a
single
solution,
and
that's
what
these,
what
these
acquisitions
and
product
announcements
are
all
about.
A
Let's
get
stuff
out,
there
see
what
people
want
to
do
and
what
really
gets
traction
with
our
customers
and
then
we'll
put
effort
and
resource
meaning
money
and
time,
and
also
people
into
that
effort
to
improve
that
area.
But
this
isn't
this
isn't
a
case
of
like
oh
now.
We're
behind
this
is
a
case
of
like
oh
wow
validation.
You
know
this
is
a
huge.
You
know,
you
know,
Microsoft
backed
company,
that's
going
hey,
we
ought
to
compete
with
gitlab
and
let's
put
effort
into
that
I'm.
A
So
from
that
standpoint,
I,
don't
my
initial
that
my
emotional
reaction,
that
was
the
first
thing
I
did
was
like?
Oh
no
and
then,
when
you
actually
think
about
it
and
talked
any
place
it
about
it,
he's
like
very
rightly
out
number
one
competitor
is
our
open
source
offering
a
number
two
competitor
is
you
know,
homegrown
solutions
that
companies
come
up
with,
you
know
mashing
everything
together
and
then
after
that
is
probably
give
github
in
terms
of
the
marketplace
that
we
are
really
targeting,
which
is
a
full
single
solution
for
the
whole
DevOps
lifecycle
right.
A
So
the
thing
to
be
aware
of
here
is
yes.
It
feels
a
little
scary
because
even
in
packaging,
when,
when
you
have
made
that
announcement,
they're
like
we
have
all
these
things,
I
still
haven't
got
access
to
the
beta
and
I'm.
Sorry
beta,
we
say
beta
in
the
States
I
suppose
you
know,
I
haven't
get
access
to
that.
I
requested
access
when
they
announced
it.
A
As
my
personal
account,
I
still
haven't,
got
access,
I,
don't
even
know
if
they're
doing
it,
what
it
looks
like
or
I
would
seen
that
so
I
think
I
think
what
we
ought
to
be
doing
is
thinking
about
what
github
is
and,
to
a
large
extent,
exactly
what
Ian
and
Tim
they
talked
about
is
like
okay.
What
are
they
doing?
Is
it's
different
that
this
part
of
what
they're
doing
actually
seems
super
cool?
Can
we
can
we
take
this
idea
and
use
it
for
ourselves
in
a
way?
F
I
think
you
did
a
good
job
of
summing
things
up
I'm
in
the
same
same
mindset
as
you
I
I,
like
the
competition.
There
was
exciting
for
me
to
watch
that
and
say:
oh
cool.
Were
there
validating
validating
us,
I
love
since
I
love,
how
the
article
the
gitlab
put
out
they
were
citizens
saying
this
is
great
for
everybody
right
what
a
cool
perspective
on
things.
So
I
really
appreciated
his
perspective
and
enjoyed
learning
about
that
I.
Think
for
me,
just
kind
of
you
know.
F
Looking
over
all
of
sea
ice
kind
of
on
the
front
end
I
saw
some
opportunities
where
github
was
doing
some
nice.
They
had
maybe
a
little
bit
more
of
a
polished,
UI
and
some
areas.
So
one
of
my
takeaways
was
we
could
improve.
Like
our
you
know,
our
our
job
law
collapsible
job
log
area,
things
like
that
some
issues
were
already
working
on,
but
just
kind
of
we
refocus
our
efforts
in
those
areas
to
tighten
up
the
UI
and
then
the
other.
F
The
other
thing
was
kind
of
reprioritizing
verify
a
little
bit
right
with
with
the
open
source
for
the
shared
runners
on
Windows
and
Mac
OS
things
like
that.
So
just
it
validated
our
approach,
which
is
really
cool
and
then
my
wheels
are
is
kind
of
turning
like
how
can
we?
How
can
we
see
what
they're
doing
similar
to
your
thoughts
dan?
B
Search
is
really
cool.
Like
look,
you
know
you
could
search
for
a
specific
package
across
the
platform,
so
you
could
do
like
package
and
then
find
and
DM
packages.
For
example,
we
don't
that's
an
area
I
think
that
we're
behind
probably
our
search,
is
not
great
and
then
I
like
the
idea
of
the
contextual
help
like
if
you
are
loading.
If
you're
working
on
a
JavaScript
project,
they're
gonna
recommend
a
node
template,
or
you
know
so,
I
think
there's
some
things
that
we
can
do
there.
We
we
sort
of
make
our
users
work
for
that.
B
We
give
them
all
those
templates,
but
we
make
them,
discover
them
and
find
them
not
that
it's
impossible
to
find
them.
It's
just
like
a
nice
to
have
right.
It's
nice,
one
uber
remembers
that
that
you
go
to
work
or
the
same
place
at
the
same
time
every
day,
it's
nice
that
to
make
those
recommendations
and
the
vulnerability
scanning
for
packages
is
another
cool
thing.
I
know
that
was
an
acquisition,
not
something
that
they
built,
but
we
had
a
conversation
with
NPM
yesterday
and
they're
really
pushing
that
piece
of
their
product.
B
The
vulnerability
scanning
and
security
aspect
I
know
we
have
some
of
that
built
in
to
get
lab
and
with
dependency
scanning
and
container
scanning,
but
we're
not
currently
handling
it
for
the
docker
image.
You
know
our
container
registry
or
package
registry,
so
that
could
be
an
area
that
we
start
to
think
about
as
well,
and
we
haven't
really
talked
to
our
users
about
that.
If
that's
something
that
they're
wanting
or
needing
or
feel
like,
they
have
good
enough
coverage.
But
it's
something
that's
like
that
could
be
something
that
we
prioritize,
especially
if
NPM
is
gonna.
A
C
I
was
timid
sort
of
touched
by
a
second
ago,
but
I
was
thinking
that
one
of
the
things
that
we
currently
don't
do
is
that,
for
don't
do
particularly
well,
is
detecting
what
kind
of
project
is,
perhaps
being
so,
what
kind
of
project
the
repo
is
representing?
So
if
it
was
like
a
NPM
package
or
something
like
that
and
then,
as
sort
team
said
suggesting
certain
files,
I
was
thinking
like,
for
example,
if
you
are
working
on
a
JavaScript
project,
we
could
just.
C
We
could
suggest
a
CI
file
that
would
have
a
way
of
building
JavaScript
and
perhaps
go
even
further
than
that.
So,
for
example,
if
it
was
of
UJS
projects,
we
could
detect
that
and
then
actually
say
have
you
considered
using
this
CI
file.
That
would
do
like
a
few
testing
and
we'll
just
basically
have
a
basic
template
into
some
common.
Like
CI
scenarios
to
encourage
more
usage,
you
can
even
go.
C
I
was
thinking
like
with
the
JavaScript
side,
especially
you
could
even
go
so
far
to
include
deployment
to
popular
services
like
meta,
Phi
and
stuff,
like
that,
which
is
like
they're
all
kind
of
gaining
in
popularity.
In
that
kind
of
thing
and
I
was
going
to
suggest
like
perhaps
we
could
do
that
with
the
actual
package
Weibo
as
well,
that
package
registry
as
well.
G
The
only
thing
that
I
was
thinking
about
it
was
like
how
well
this
kind
of
demonstrates
the
difference
in
how
we
work
versus
get
github
where
you
know
like
they,
they
sort
of
you
know
released
us
all
in
beta.
It
looks
really
nice,
but
it's
kind
of
like
you
have
to
have
permission
to
use
it,
and
you
have
to
wait
and
get
excited
and
there's
all
this
like
height
build-up
or
is
you
know
we'll
just
like
hey
here's,
this
thing?
G
G
Think
the
iteration
style,
like
you,
really
is
good
for
a
lot
of,
especially
these
larger
customers
to
be
able
to
like
have
these
conversations
as
we're
building
the
product
which
I'm
sure
github
is
having
conversations
with
people
as
they
build
it.
But
it's
nice
that,
or
at
least
I
like
the
idea
that
we're
like
having
those
conversations
in
the
open
to
an
extent
yeah.
A
Yeah
I
agreed
I
was
thinking,
as
you
were
saying
that
iteration,
but
also
transparency
and
saying,
like
yeah,
go
look
at
it.
Is
the
code
go
help?
If
you
want
you
know,
so
it's
a
it's.
A
very
interesting,
like
you
could
sort
of
say,
approach
of
whatever
word
you
want
to
use,
but
it's
very
different.
You
know
github
is
very
focused
around
the
open
source
community.
We
are
as
well,
but
we
also
here's
our
code
and
we
actually
open
source
ourselves,
which
is
quite
interesting,
but
yeah.
A
I,
agree
with
that,
and
thank
you
both
for
those
doors,
I
wrote,
I,
know
them
down
in
the
document
by
the
way
so
they're
there
I
think
my
in
my
head
at
least
from
forward-looking
and
we
should
wrap
up,
is
just
the
idea
of
where
they
going
next,
given
their
acquisitions
and
releases
recently,
where
they
going
accessing,
is
pretty
obvious,
which
line
they're
going
and
what's
interesting
to
me.
Is
they
haven't
bothered
to
update
their
issues
or
anything
which
I
even
before
I
was
working?
B
That
may
be
an
issue
that
went
back
and
forth
with
this
person
a
bunch
we
resolved
their
issue
and
then
we
reached
out
to
them
and
to
ask
them
what
their
experience
and
how
they're
using
maven-
and
this
guy
was
like
our
biggest
fan
right
at
the
beginning
of
the
call
he's
like
this
is
how
product
work
should
be
done,
talking
to
your
users
and
and
then
he
said,
you
know
I'm
so
impressed
with
gitlab
and
how
how
fast
you
build
product.
You
know.
B
Just
if
you
ever
need
a
comparison,
go
look
at
bit
buckets
release
page.
They
launched
like
one
measly
feature
a
month
or
every
few
months
he's
like
with
gitlab
I,
can't
even
keep
up
you're
launching
so
many
features
so
fast,
all
the
time
and
I'm.
It
was
great
to
hear,
because
you
know
we
hear
so
many
negative
comments
from
users
of
issues
and
stuff,
but
when
you
actually
talk
to
them,
we
actually
talked
to
their
our
users.