►
From YouTube: Technical discussion on CI Pipelines for packages
Description
A
A
It
can
come
from
a
ci
pipeline
from
a
gitlab
project.
It
can
come
from
an
external
process.
You
could
have
an
external
ci
pipeline,
building
the
the
package
and
pushing
it
to
the
github
package
registry
and
it
can
also
come
from
a
manual
process.
You
could
very
well
be
building
your
package
on
your
console
and
pushing
it
to
the
to
the
package
registry.
A
A
A
A
B
So
I
have
a
few
questions
because
I
think
it's
a
common
theme
to
actually
have
a
repository
for
a
package
and
to
build
a
package
in
the
continuous
integration,
continuous
delivery
pipeline
from
that
repository.
So
it
feels
a
bit
awkward
that
whenever
you
push
such
packet
from
a
ci
environment,
you
would
still
trigger
another
pipeline
to
validate
something.
I
know
that
it
might
be
suitable
for
a
big
different
use
case
right,
but
in
this
case
it
feels
you
know
a
bit
disconnected
from
the
usual
workflow
of
building
packages
and
publishing
them
within
the
ci.
A
So
in
the
demo,
one
of
the
jobs
is
running
package
hunter,
so
package
hunter
will
take
a
package
file
and
it
will
actually,
I
think
it
tries
to
install
it
and
and
check
what
it
is
doing
with
the
system,
and
it
was
a
bit
popular
a
few
months
ago
where
you
could
have,
for
example,
for
npm
packages.
You
can
have
a
b4
script
where
you
have.
Basically,
you
can
input
a
shell
command
and
you
can
do
whatever
you
want.
A
B
A
Yeah,
okay,
so
so
the
main
issue
I
faced
here
is
that
how
do
you
link
a
pipeline
object
with
a
package
file,
because
in
the
package
theme
we
have
mainly
two
files,
the
package
and
the
package
files?
So
here
I
wanted
to
link
a
pipeline
with
a
package
file,
and
the
issue
is
that
we,
as
I
said,
we
don't
have
any
any
concept
of
comicha
or
reference
or
something.
So
what
I
did
is
that
I
created
an
intermediary
object
with
which
I
called
a
push.
A
B
How
chat
ups
is
implemented,
in
my
opinion,
still
like
a
bit.
I
would
do
that
differently.
Perhaps,
but
right
now,
that's
an
established
pattern,
so
I
guess
that
we
can
at
least
replicate
some
parts
of
it
and
that's
fine
having
some
kind
of
an
identifier
or
a
sha
assigned
whenever
we
push
something
like
it
might
work.
But
then
there
are
like
a
couple
of
follow-up
questions.
Someone
might
ask
so,
for
example,
do
we
want
to
trigger
a
separate
pipeline
every
time
someone
is
pushing
the
same
thing?
B
B
The
main
challenge,
in
my
opinion,
is
not
really
how
we
implement
that,
but
the
ux,
because
someone
needs
to
somehow
associate
pipelines
with
the
push
events.
We
need
to
have
some
kind
of
a
view
for
that.
If
it
does
not
exist
already,
we
need
to
have
some
way
of
telling
users
what
the
status
of
such
pipeline
was
and
and
stuff
like
that.
So
it's
more
like,
in
my
opinion,
it's
more
like
you
know
a
ux
challenge
than
a
back-end
challenge.
Actually.
B
A
That's
fine,
of
course
I
will
reuse
the
video.
So
basically
we
have
a
screen
where
you
have
all
your
packages
and
you
can
see
if
what
is
the
latest
status
of
the
package,
it
will
pull
the
latest
package
file
uploaded
and
pull
the
pipeline
status
for
that
yeah.
Here
it
is
so
you
have
the
all
the
packages
and
you
can.
B
A
A
A
B
A
B
A
A
There
was
a
few
things
that
were
not
working
like
this
commit
column,
since
we
are
not
referencing
a
comment,
but
the
the
the
whole
ui
was
working,
the
links
were
working,
I
could
open
the
pipeline
and
this
screen
was
working
to
the
pipeline
details.
I
guess
it
is
so
there
is
already
a
good
part
of
the
ui
working,
but
you
are
right
that
there
are
still
some
questions
on
the
ux
for
this,
but,
like.
A
B
A
B
But
you
you
had
to
create
the
standard,
regular
ci
yam
file,
and
you
had
to
put
that
into
repository
under
some
kind
of
a
show
yeah.
So
there
is
a
sha
of
the
commit
being
used
to
read
the
ci
configuration
right.
So
that's
actually
the
connection
with
the
repository,
because
we
need
to
parse
labs
here,
yaml
file
from
the
repository
and
that's
the
version
of
the
pipeline.
A
A
B
I
think
if
you
want
to
be
in
line
with
what
we
are
doing
with
chat
ops
chat,
ops
is
using
the
standalone
standard
jam
file,
but
there
is
a
specific
job
that
only
can
run
for
chat.
Ups.
It's
very
not
polished
right
now,
because
in
order
to
indicate
that
that's
a
chat
of
job,
you
just
put
the
entry
only
chat,
only
chat.
A
B
Yeah,
so
I
I
think,
there's
some
value
in
replicating
how
chat
ups
works
and
it's
not
only
chatos.
We
do
have
also,
I
think,
some
kind
of
actions
being
done
when
you
edit
something
in
web
ide.
I
cannot
remember
exactly,
but
you
would
need
to
check
that,
but
whenever
you
do
something
in
the
web
idea
ide,
I
I
remember
that
we
also
create
a
dangling
pipeline.
B
A
A
Going
back
to
the
cold
yeah,
I
I
I
do
have
a
service
creating
the
pipeline,
and
this
is
the
the
location
where
I'm
not
happy
with
it.
So
I'm
using
the
regular
create
pipeline
service,
but
I
saw
that
some
properties
were
mandatory,
such
as
a
ref
and
I
use
before
sha.
But
I'm
not
sure
that
was
the
the
the
proper
way
and
well
I'm
just
putting
some
values
so
that
the
service
is
happy.
But
yeah.
B
B
A
A
B
B
You
would
need
to
you
know,
because
runner
is
able
to,
for
example,
retrieving
objects
from
object,
storage
and
it
can
retrieve
zip
files
for
gitlab
like
it
can
do
a
lot.
So
you
know
fitting
the
package
file
as
an
artifact
can
actually
make
it
almost
transparent,
almost
transparent.
So
I
guess
that
you
might
not
even
need
to
change
anything
yeah.
A
Yeah,
I
guess
I,
since
it's
both
areas
are
kind
of
new
to
me,
so
I
missed
a
lot
of
information
yeah.
I
implemented
something
similar
like
that,
which
is
an
api
that
will
just
pull
the
package
file
from
object
storage,
but
if
something
already
exists,
yeah
totally,
we
should
use
that
instead
and
this
will
avoid
any
change
on
the
owner
side.
A
A
B
B
A
Yeah,
the
most
common
type
is
a
zip
file,
but
the
file
extension
is
not
zip.
Like
the
the
java
jar
files.
They
are
just
regular,
zip
files,
but
if
you
don't
have
the
zip
file
extension,
but
but
okay,
I
guess
we
can
do
something
work
with
with
that
artifact
system
and
it
should
be
okay,
okay,
so
this
was
way
shorter
than
I
thought.