►
From YouTube: 2020-05-14 Ops Cross Stage ThinkBIG!
Description
04:35 - Separation between AWS environment variables and Secrets Management by Jackie Meshell
28:00 - Use cases for pipelines view in GitLab by Dimitrie Hoekstra
A
Okay,
so
welcome
everyone
to
the
ops
cross
testing
big
session.
This
is
our
third
session
that
was
actually
initiated
from
initially
from
package
from
Ian,
so
he
could
have
still
en
thanks
a
lot
for
that.
We
are
experimenting
with
running
these
sessions
in
order
to
bring
some
alignments
and
catch
up
and
give
birth
to
some
new
ideas
that
are
related
to
the
cross
stage
in
ops.
A
A
As
I
said,
we
are
trying
to
discuss
things
that
we've
heard
from
users
or
some
of
the
challenges
that
we
are
having
in
the
stage
groups
and
kind
of
like
discuss
them
in
a
bigger
crowd
between
the
stage
clothes
because
I
feel
like
we
are
not
really
having
enough
of
this
cross-department
discussion.
So
this
is
a
great
opportunity
for
that.
A
We're
also
having
the
think
big
label
created
specifically
for
this
issue.
So
please
add
this
label
to
the
any
ideas
that
are
coming
out
from
this.
We
can
track
them
for
the
later
success
yeah
and
we
are
also
constantly
working
to
improve
the
sessions
of
the
reserve
at
respective
Linklater,
but
I've
imagined
that
also
at
the
end,
at
the
end
of
the
session.
So
we
have
the
agenda
for
today's
session,
mostly
coming
from
the
old
CI
CD.
So
thanks
Jackie
thanks
Dimitri
thanks
orede
and
other
folks
who've
been
involved
in
preparing
the
agenda.
A
I'm
really
happy
to
see
topics
coming
in
from
ops
part
thanks,
Victor
and
Maria
for
bringing
in
discussions
for
the
next
month's
also
really
excited
for
that.
Also,
what
I
want
to
say
that
sometimes
the
topics
are
not
really
relevant
for
all
the
crowd
that
we
have
invited.
We
are
having
actually
like
30
people
invited
for
this
session,
so
feel
free
to
pick
the
thing
big
sessions
that
are
really
relevant
to
your
stage
group
or
where
you
could
feel
you
can
contribute
or
where
you
want
to
listen.
A
It's
also
fine,
it's
okay
for
us
to
skip
that
if
you
feel
like
okay,
this
topic
is
not
really
relevant
for
me
and
also
that
the
agenda
document
is
really
growing.
So
I
use
the
left
section
of
the
Google
Doc.
We
have
some
tips
for
the
presenters
added.
This
was
coming
as
a
feedback
from
the
previous
sessions.
We
wanted
to
help
people
to
prepare
for
these
discussions
to
make
sure
that
we're
bringing
in
people
prepared,
so
they
can
take
the
most
out
of
these
sessions.
A
A
B
So
there's
a
couple
of
different
projects
going
on
right
now
that
touch
variables
in
general,
not
really
environment
variables.
The
environment
variables
is
a
piece
I
care
about,
because
that
is
directly
related
to
release
orchestration.
But
CI
variables
are
the
greater
concept
of
ci
CD
variables
inside
of
Gayla,
so
CI
CD
variables
span
progressive
delivery,
release
management
and
and
verify
and
that
CI
variables
are
used
to
execute
jobs
in
a
pipeline.
B
So
with
all
of
those
considerations,
we
have
begun
investigating
the
futures
that
aren't
interested
in
leveraging
the
Hashi
core
fault
integration.
What
are
their
expectations
for
robust
secrets,
management
inside
of
get
lab
natively,
another
kind
of
tangential
thing
that
we're
also
noticing
I
organized
our
environments,
page
and
environments,
dashboard
issues
into
several
phases
of
epics.
Yesterday
we
learned
that
a
lot
of
the
environments,
page
and
environments,
dashboard
issues
had
the
CI
variable
label
on
it,
indicating
that
there's
some
sort
of
bug
or
impactor
touching
see
ICD
variables.
B
Whenever
you
look
at
environments
holistically
release
management
is
very
focused
on
static
environments
and
environments
as
a
construct
for
deployments
inside
of
get
lab
rather
outside
of
gate
lab,
because
you
can
deploy
to
a
static
URL,
that's
a
target
environment
to
any
cloud
provider,
but
review
apps
is
also
a
type
of
environment.
It's
a
dynamic
environment
that
progressive
delivery
owns,
and
it's
really
about
checking
your
code
or
your
merge
request
in
such
you,
while
you're
working
on
your
development
to
help
support
the
incremental
delivery
of
a
feature
request.
B
Your
stage
definitely
touches
variables
in
some
some
cases,
as
well
as
far
as
how
jobs
are
permissioned
and
how
tokens
and
authentication
occurs
between
the
systems
and
the
runner
and
I
think
the
the
think,
big
parts
that
we
should
be
considering
here
is
establishing
dris
for
specific
scopes
so
that
we
know
who's
going
to
carry
the
torch
across
the
line.
Whenever
an
issue
has
a
CI
variable
tag
on
it.
I
also
think
another
opportunity
is
for
us
to
think
about
when
we
redesign
secrets
vs.
B
B
A
C
So
Jackie,
you
said
something
that
I
just
have
a
question
about
you're
saying
since
there's
whenever
week,
whenever
there's
anything
that
touches
variables
that
could
potentially
impact
across
the
different
groups
that
we
want
to
have
one
DRI.
Not
only
coordinating
that
and
you
know,
carrying
the
torch
for
it.
Keeping
everyone
informed
with
that
one
DRI
by
the
definition
of
DRI
also
make
the
decision.
I
mean
there
are
impacts
from
having
one
DRI
make
a
decision
that
that
affects.
B
I
wasn't
really
thinking
one
DRI
for
the
thinking
could
create
their
scopes
and
maybe
even
get
rid
of
the
CI
variables
tag
so
that
we
truly
owns
these
issues,
because
when
I
see
yeah
variables
tag
yeah,
it's
it
misleads
me.
It
makes
you
believe
that
maybe
it's
somebody
else's
thing
and
really
it's
not
like
it
could
be
purely
secrets,
management
or
it
could
be
purely
environment.
But
it
has
a
CI
variable
tag
on
it,
and
it
leads
me
to
believe
that
it
could
be
owned
by
somebody
else
and.
C
When
you
say
tag,
are
you
talking
about
our
our
labels?
You
know
on
our
issues.
I
haven't
seen.
Ok,
interesting,
do
you
have
anything
I
should
click
through
to
one
of
your
issues
to
see
I
haven't
come
across
and
if
I
have
I
haven't
noticed
it
issues
that
I've
looked
at,
that
has
that
CI
variable
label?
Ok
ever.
D
For
you
know,
specific
product
areas,
which
is
an
effort
currently
in
progress,
I,
feel
being
pushed
by
nadya,
but
you
know:
there's
there's
one
thing
as
being
the
DRI
and
pushing
this
effort,
and
you
know
doing
the
designs
and
getting
this
thing
rolling
versus
who
is
the
subject
matter
expert
and
should
be
included
in
order
to
be
you
know
to
know
if
this
effort
is
gonna
benefit
the
larger
picture
here
and
I
think
you
can
have
conceptually
Adi
right
or
both
like
they
can
be
DRI
for
the
stage
group.
That's
gonna.
D
You
know
work
on
a
part
of
the
feature
for
that
stage:
group
that
is
gonna
impact,
for
example,
environment
variables,
but
then
there's
another
one
where
you
can
say
alright.
If
you're
gonna
work
on
this
product
specific
area,
then
you
need
to
at
least
include
that
person
and
get
approval
from
the
person
in
order
to
push
it
feature
that
touches
that
area,
because
I
think
otherwise,
for
example,
say
that
secret
variables
are
always
going
to
be
pushed
by
CI
the
CI
station,
for
example.
That
means
we
will
not
always
be.
D
You
know
the
best
people
to
push
the
ideas
and
etc
forward.
While
we
would
be
the
best
person
to
say
hey
these
new
additions,
you're
planning-
yes,
they
might
be
a
good
idea,
but
have
you
thought
of
this
or
hey
I
would
not
do
this
because
it
isn't
this
because
we
have
done
these
in
these
design
ideas
because
of
certain
past
inputs
them
and
decisions,
etc.
So
what
I'm
wondering
basically
is
still
the
art?
D
E
Think
approval
is
required
and
everybody
can
edit
anything.
We
have
the
maintainer
process
in
order
to
make
sure
that,
like
kind
of
crazy
things
don't
get
through,
but
part
of
the
kid
lab
magic
is
that
everybody
can
contribute
like
if
you
think
of
our
contributors
out
in
the
world,
you
know
they
don't
have
to
go.
E
E
E
B
E
D
Is,
to
be
honest,
like
the
maintainer,
the
idea
of
the
maintainer
is
something
that
would
align
with
how
I
how
I
was
thinking
about
it
and
is
something
that
kind
of
aligns
with
that
right
like
and
to
be
honest
like
if
we
look
at
the
concept
of
a
maintainer
inside
of
a
merge
quest
that
does
kind
of
align
with
getting
approval
to
get
something
merged.
So
I'm
wondering
where
we're
shifting
the
line
here,
I.
E
B
Just
like
organically,
as
a
part
of
a
change
being
submitted
and
added
to
our
product,
like
this,
isn't
an
upstream
thing.
What
I
heard
you
say
to
meet
you
to
say
have
been
my.
My
misunderstanding
is
that
we
would
want
to
have
kind
of
like
a
designer
or
product
maintainer
of
an
area
that
would
approve
the
scope
prior
to
a
change
being
committed,
but
I
think
what
we're
suggesting
here
is
that
we
rely
on
the
current
framework
of
a
merge
request,
getting
approved
by
a
maintainer
and
merged
to
get
less.
B
D
I
would
say,
like
I,
think
what
we're
looking
for
is
to
include
a
person
before
we
even
get
to
a
merge
request
and
to
have
the
person
involved,
not
so
so
much
as
like
a
strict
as
a
merge
classed
as
like
hey,
you
need
to
sign
it
off,
but
I
would
say
like
hey
generally.
This
person
should
be
included
and
should
be
aware
of
this
change
upcoming.
D
B
I
think
that
makes
sense,
I
think
we're
all
talking
the
same
language.
It's
really
looking
at
our
gitlab.
Like
I
just
checked
in
our
handbook,
I
think
we
really
are
talking
about
the
directly
responsible
individuals
for
these
various
product
areas
and
they
don't
necessarily
have
to
align
with
the
ways
that
we
have
categories
organized
today.
A
B
Not
really
a
suggestion
which
is
kind
of
unlikely,
typically
I,
don't
just
point
out
problems
and
poopoo
and
everything
so
sorry
L
don't
mean
to
do
that
right
now.
I
would
say
something
that
I
think
would
be
helpful
is
if
we
look
at
all
of
the
overlaps
for
variables
and
identify
like
what
is
the
intent
of
these
overlaps
and
if
we
should
even
have
the
CIA
variables
label
anymore,
because
I
think
that's
a
very
myopic
view
from
my,
but
it's
the
biggest
thorn
in
my
side.
B
Currently,
this
secrets
management
is
an
overlap
with
CI
variables,
but
it's
also
mostly
in
release
management's.
So
maybe
that's
an
example
that
we
can
start
working
on
between
verify
progressive
delivery
and
release
management.
To
see
like
does
this
label?
Is
this
label
even
relevant
for
these
areas
anymore?
Should
we
just
regroup
that.
C
C
B
C
B
This
kind
of
this
is
kind
of
some
that
we
talk
about
like
right
when
I
first
joined,
there's
an
issue
about
like
environment
scoped
variables
and
if
it's
an
environment
issue
or
if
it's
an
actual
like
variable
issue
and
I,
think
it
could
just
be
my
problem
that
maybe
I
get
confused
by
the
CI
variables
label
and
don't
really
know
if
I'm
free
to
make
like
all
these
changes
on
this,
and
that
could
just
be.
That
could
be
any
problem.
E
E
Things
and
they've
been
useful
in
areas
where
something
does
actually
bridge
multiple
stages
and
categories.
The
only
I
would
say
the
only
labels
that
apply
ownership
would
be
the
category
of
labels
like
category
:.
Whatever,
then
that
maps
to
a
clear
owner,
I,
don't
know
if
anybody
actually
cares
about
this
CI
variables
label
or
even
really
any
of
the
other
topic
ones
or
if
they
all
just
sort
of
predate.
E
That's
not
the
case
or
you
could
even
update
the
description
of
the
label
and
say
like
this
is
a
topic
that
but
does
not
map
to
an
ownership.
If
you're
trying
to
figure
out
the
ownership
that
I
look
at
the
category
label,
something
like
that
might
be
an
option
to
you,
but
really
just
deleting.
It
might
also
be
an
option
if
it's
230
issues
that
it
really
doesn't
matter,
we've
got
like
10,000
issues
or
20,000
she's
in
the
product
right
I.
Don't.
D
C
D
Would
say,
like
there's
been
a
lot
of
those
those
kind
of
labels
that
have
been
assigned
to
say
like
hey.
This
is
this
is
concerning
variables
is
concerning.
Environments
is
concerning
the
merge
quest
widget.
This
is
concerning
the
merge
quest
page
there's
just
no
process
for
these
labels,
but
I
do
think.
They're
personally
I
do
think.
D
There's
value
in
being
able
to
group
issues
by
these
kind
of
topics
and
as
we
have
those
labels
already
in
place
personally,
I
would
advise
for
not
throwing
that
value
away,
but
creating
a
process
and
getting
something
like
topics
issues
involved,
and
then
we
can
sign
ownership
of
those
topics.
Labels
to
category
labels
in
order
to
sign,
like
hey
people
from
that
state
who,
who
own
those
categories
which
those
topics
belong
to
should
be
at
least
involved
in
those
discussions.
E
B
I
feel,
like
the
other
person
here,
that's
good
that
cares
most
about
this
is
Demetri,
so
I
think
him
and
I
will
take
this
forward
and
we'll
build
something
that
makes
a
lot
of
sense,
whether
that
is
rebranding
this
label,
so
it
means
something
for
this
audience
since
this
predated
or
creating
the
process
that
he
mentioned.
I
have
no
problem
owning
that
I
think
Ori.
B
What
might
be
interesting
to
hear
your
perspective
is,
as
we've
been
working
on,
deploying
to
AWS,
how
do
you
perceive
the
differences
in
like
variables
and
environments
with
the
work
that
you're
doing
and
how
it
sits
in
release
management
versus
progressive
delivery?
Hey
do
you
feel
like
there's
something
wrong
and
how
we
have
scope
split
there
or
is
their
ownership
set?
You
think
we
should
be
sharing
more.
Oh.
G
People
have
been
using
the
specific
AWS
environment
variables
even
before
we
started
this
whole
the
climate
AWS.
So
I
really
don't
think
that
it's
such
a
big
deal.
We
have
worked
on
specifically
in
purpose
of
delivery,
untyped,
AWS
variables
and
well
I.
Think
it's
great
I
think
it's
a
bad
practice.
I
think
we.
G
B
G
G
Yeah
and
people
were
using
them
in
kubernetes
secret
optics,
so
I
just
need
to
read
them
somehow.
I,
don't
really
like
I
mean
I
care
where
they're
stored,
because
that's
how
I'm
gonna
read
them,
but
but
I
I,
don't
think
from
everyone
that
we
interviewed.
No
one
was
using
the
environment
variables.
I.
G
G
I
didn't
say
that
I
was
they
didn't
go
through
the
whole.
Here's
everything
that
in
my
pipeline,
I
just
asked
them
about
there's
specific
deployment
AWS
and
that
was
not
used
with
environment
variables.
Again
we
interviewed
between
8
to
10
people,
which
isn't
a
huge
amount
of
people,
so
there's
definitely
valid
use
case
for
environment
variables,
because
we've
been
getting
feedback
about
templates
and
everything
type
variables
as
well,
so
people
are
using
it
I,
don't
know
it
goes
every
way
every
like
it.
Every
choice
is
right.
G
B
A
A
H
D
Thank
you.
So
let
me
give
a
brief
introduction
across
various
state
troops.
I
have
received
feedback
that
there
have
been
thoughts
around
fake
pipelines
for
specific
uses
of
our
product,
so
say,
for
example,
security,
a
specific
security
pipeline
also
from
release
and
in
terms
of
like
progressive
delivery
that
have
been
ideas
floating
around
I'm,
not
stating
how
you
know
feasible.
They
really
are,
and
if
it's
a
good
idea,
yes
or
no,
but
it
I-
think
it
is
a
very
valuable
topic
to
discuss
cross
functionally
and
to
see
like
hey.
What
is
the
know-how?
D
How
far
does
this
idea
reach,
because
from
the
beginning
on
when
we
got
CI
to
get
lab,
we've
been
building
on
our
you
know
upon
our
get
lab,
CI
llamo
and
our
pipeline
visualization
and
there's
everyone.
Everyone
goes
into
there,
but
the
product
is
going
wrong
so
large
that
there
might
be
use
cases
for
a
more
dedicated
pipeline
view
or
some
subset
of
the
pipeline.
That
gets
highlighted
in
a
in
a
subtle
way
that
improves
the
you
use.
I
I
So
this
is
like
a
new
thing
that
we
can't
like,
on
the
mind,
scan
or
a
synchronized
skin,
as
user
can
just
create
it,
it
could
be
similar
to
create
a
pipeline
and
for
the
MVC
we
use
the
concept
of
run
the
scan
inside
a
pipeline,
but
in
the
future,
we'll
probably
want
to
detach
it
from
pipeline,
because
we
think
the
idea
of
running
a
security
test
is
not
exactly
the
same.
That
people
think
to
build
a
pipeline,
and
the
reason
is,
if
user
credits
and
see
it
and
check
on
details.
I
If,
like
then
a
pipeline
will
create
it
and
there
is,
there
is
no
kimete.
So
all
the
pipeline
created
will
have
a
commit,
but
for
the
security
skin
it
creates,
it
doesn't
have
a
commit.
So
we
might
like,
at
the
beginning,
just
thinking
about
ok
at
a
label
there
to
tell
this
is
special
job
that
runs
in
context
of
security
and
then,
like
I,
show
the
results
under
the
Security
tab,
which
we
currently
have
when
the
security
job
is
in
part
of
like
about
pipeline
which
trigger
the
Bekaa
meat.
I
I
That
is
appropriate
to
do
something
like
that,
or
should
we
do
something
to
hide
this
one,
and
it
also
leads
to
a
bigger
question
that
is
linked
in
this
issue
here
that
we
actually,
we
don't
know
that
why
a
security
specialist
will
come
to
a
pipeline
and
the
security
Channel
Rick
real
information.
We
didn't
have
any
like
search
down
at
this
point,
particularly
in
the
area,
to
ask
people
hey
when
you
use
skill
up.
Do
you
particularly
go
to
the
peplum?
I
You
Security
tab
to
check
your
thing,
I'm,
also
wondering,
or
something
pop
up
in
your
research.
When
you
interview
like
target
the
user
use,
the
Python
Manly
to
dimension
ever
mentioned,
like
a
security
thing,
could
be
like
something
the
caramels,
so
I
think
there
are
like
kind
of
2
question.
1
is
really
the
with
this
MVC
and
otherwise,
more
general
I.
C
I
haven't
come
across
an
a
user
that
mentioned
anything
about
the
security
tab,
but
that
may
be
because
the
type
of
person
we
were
had
recruited
for
for
any
interview
that
I've
sat
in
on
our
conducted
was
not
someone
who
would
be
interested
in
the
security
town.
You
know,
although
I
wonder
if
the
team
that
the
group
I
forgot,
that
name
of
them,
but
the
either
the
secure
defend
team
has
any.
D
I
do
know
that
in
the
past
like
before
pipelines
became
a
thing,
we
only
had
jobs,
and
then
you
know
we
introduced
give
up
ages,
job,
which
is
actually
a
non
inspectable
job.
It's
just
a
job
that
pushes
your
page
to
the
deployment
server.
We
have
it's
not
inspectable,
but
it
does
its
job
kind
of
in
a
similar
way.
D
I
feel
that
security
is
kind
of
like
that,
but
on
the
pipeline
level,
on
the
other
hand,
I
would
say,
like
the
reason
why
we
have
always
been
expanding
upon
the
pipeline
comes
because
you
get
so
much
for
free,
so
I
think.
Indeed
the
question
will
relies
and
like
hey.
Is
there
use
for
this
or
not?
Because
if
we're
just
gonna
throw
it
away
a
whole
lot
of
value
based
on
an
assumption,
then
it
might
not
be.
F
I
think
I
have
a
related
question,
which
is
I'm
sure
you
run
plenty
of
user
interviews
and
mostly
because
look
at
pipelines
when
something
fails
and
when
I'm
doing
some
hobby
projects
and
something
phase.
But
to
me
basically
pipeline
is
a
back-end
background
task,
that
is,
a
user
of
grid
lab
I'm,
not
really
interested
in
I'm
interested
in
merge,
request,
I'm
interesting,
saying
that
there
is
a
pipeline,
that's
green
or
red,
but
I'm
not
interested
in
pipeline
per
se.
This
is
just
my
personal
understanding
and
I.
F
Don't
know
what
hard
users
think
about
the
pipelines,
but
if,
if
this
hypothesis
is
correct,
then
using
this
pipeline
is
just
a
perfect
thing,
because
the
pipeline
is
is
basically
not
not
a
core.
It's
a
core
feature
of
gitlab,
but
not
not
a
user.
Focusing
feature
of
good
luck
had
to
say
that
that's
pretty
nicely
put
I.
E
Think
that
the
moment
you
get
the
green
is
the
more
like
getting
your
pipeline
to
green
is
like
the
more
exciting
moment.
I
saw
somebody
tweet
today
is
something
like
that
feeling
when
you
get
your
first
green
checkmark
on
your
pipeline
or
something
like
that
and
I.
Think
that
that's
very
true
and
then
the
outcome
of
whatever
like.
If
you've
got
a
pipeline,
that
updates
your
website,
then
you
are
just.
F
E
E
E
See
IMO
really
needs,
like
you,
user
experience,
love
design,
love
thinking
about
it
as
an
API,
managing
it
from
yeah.
It's
our
interface
for
people
to
encode
their
intentions
to
get
lab.
It's
it's
just
so
important
that
that's
actually
where
I
would
to
answer
you
to
actually
answer
your
question
to
meet.
You
know
that
Victor
helped
me
get
there.
The
the
see
I
am
will
I.
Think
is
where,
where
I
see
that
overarching
thing
that
ties
everything
together.
D
E
D
D
E
D
E
And,
and
and
if
not
exact
but
I,
do
still
think
at
least
to
a
certain
extent,
the
troubleshooting
interface
is
also
the
github.
Cia
is
like
the
CIA
mo
code
itself,
like
the
features
that
we
have
in
there.
The
linter,
like
kind
of
develop
the
development
environment
for
gitlab,
CIA
MO,
is
sort
of,
but
not
exactly
the
troubleshooting
environment
as
well.
D
So,
to
bring
a
little
a
little
bit
on
a
different
time
on
the
other
side
of
this,
I
don't
worry.
You've
created
an
issue
on
newer
vision
or
potentially
I
don't
say
it's,
you
know
a
real
thing
you
want
to
get
into,
but
it
was
an
idea
floating
around.
What
was
a
value
proposition
above
us
getting
there
of
a
progressive
delivery
specific
pipeline
because
kind
of
interchange.
This
idea
from
different
perspective,
so.
G
G
Some
benefits
that
we
could
get
from
breaking
off
the
deployment
part
from
the
the
mo
file
is
actually
on
Jackie
side,
which
is
a
lot
of
people,
have
different
permissions
for
who
was
allowed
to
deploy,
and
that
can
make
that
super
easy
if
it
was
a
separate
file.
So
in
the
previous
meeting
we
talked
about
includes,
which
could
be
a
way
to
do
that
so
have
like
Master
main
template
that
caused
the
CI
portion
and
independently
and
the
CD
portion
independently
and
me,
maybe
even
additional
stages
can
be
broken
down.
G
It
does
add
some
complexity
of
how
you
know
things
are
gonna
work
and
what
gets
called
before
what
I'm
thinking.
So
it's
just
in
an
idea
stage.
At
the
moment,
it's
not
like
something
I
actually
did
any
solution,
validation
over,
but
that's
a
benefit
that
I
see.
I
don't
know,
maybe
we
could
also
leverage
child-parent
pipelines,
maybe
allow
doing
like
multiple
deployments
in
parallel.
So
there's
like
a
few
options
that
this
could
can
introduce.
D
D
Think
the
ones
were
related.
That's
why
I
brought
them
up
here
thanks
for
that
I
wonder
if
other
people
see
it
like,
hey
I
would
not
go
into
direction
into
that
direction
because
of
X
or
Y
I.
Think
that
is,
you
know
where
the
value
in
these
kind
of
needing
shine
to
like
hey
did
we
think
of
this?
Do
we
think
about
I
would
love
if
anybody
has
some
ideas
in
that
sense,
to
speak
out.
A
I
Maybe
if
you
have
experienced
heard
it-
and
it's
like
secondary
research
from
internally
to
get
some
information
but
I
think
from
everyone
I
hear
here
is
like
it's
actually,
okay,
to
use
a
pipeline
like
in
the
direction
that
which
is
not
like
very
how
to
say
that,
like
the
euro
way
that
we
use
it,
but
as
a
job
or
something
that's
running
and
use
a
car
more
about
the
result
and
pepper
myself,
which
is
one
or
stop,
is
fair
our
success.
So
there's
no
like
nothing
blog
to
go
to
this
direction.
I
D
D
If
you
implement
security
that
way
your
github
CI
yellow
will
not
tell
the
complete
story
of
what
was
what
pipelines
will
trigger,
because
there
might
be
the
pipelines
triggered
by
the
kid.
Let's
see,
I
am
well
that's
the
fine
and
then
there
will
be
additional
ones
which
will
be
created
because
you
have
n
abled
certain
feature.
Is
that
a
desirable
thing
or
is
it
not
in.
I
Firms
or
carpet
user
like
or
personas
it
should
be.
Okay,
like
people,
you
really
don't
like
they
don't
check
pipelines,
they're,
not
like
release
manager
or
something
that's.
They
will
go
to
that
page
to
look
for
something
but
I.
Don't
also
don't
want
to
make
this
page
overcrowded.
Let's
say
that
in
the
future
like
there
is
a
security
specialist
come
here
like
just
immediately
start
n
security
without
and
on
the
pipeline
page
is
suddenly
like
10
Security
pipelines,
which
is
not
like
related
with
all
of
their
bulbs.
That's
like
the
release.
I
C
I
I
Pretty
much
like
now,
I,
don't
think
it
will
happen,
because
we're
only
well
have
one
security
test
in
the
vault
and
there's
no
reason
to
like
run
this
several
times
in
one
project.
At
the
same
time,
and
in
the
Futurist
comes
when
there
are
more
security
scans,
are
tests
introduced,
I
think
we
need
to
have
a
solution
that
doesn't
make
this
page
overcrowded
either
a
tab,
shooter
or
something
I,
don't
know
we.
C
By
author,
the
two
filters
we're
starting
with
for
MVC
on
pipeline
filters,
is
filtered
by
author
and
by
branch,
I
believe
yeah.
So,
in
that
regard,
I
think
what
you're
trying
to
get
to
Dmitry
is
it
doesn't
matter
how
much
is
detailed
on
the
pipeline
page
in
the
future,
the
user
can
just
filter
out
what
they
don't
want
to
see.
I
prefer
to
have
everything
there
on
the
pipeline
page.
D
Yeah
yeah
I
think
a
lot
of
these
things
are
it's
hard
to
solution
validate.
On
the
other
hand,
like
does
this
align
with
the
vision
we
have
free
code
lab.
Is
this
something
we
desired
or
think
that's
gonna
work?
We
don't
know
we
can
go
one
direction
and
say
like
alright,
let's
try
it
out
and
see
if
it
works.
On
the
other
hand,
plaits
we
can
also
perhaps
there
you
know
people
would
say
like
hey.
No,
no,
this.
D
This
does
not
correspond
with
the
bigger
vision
we
have
for
CI
and
CB,
and
the
for
absolutes
I
should
say
in
this
meeting
right
and
that's
why
I
wanted
to
bring
it
up
but
I'm
from
my
personal
perspective,
I
would
say
it
like
hey,
let's,
try
it
out
and
did
some
research
where
we
can
more
people
who
are
modern
to
this
or
at
least
know
about
it.
You
know
the
more
feedback
we
can
get
I
think
it's
already
been
a
worthwhile
discussion.
So
far,
I
think.
A
Come
on
feel
free
to
invite
involve
all
of
the
people
who
have
been
providing
feedbacks
here,
yeah
for
some
advices
in
the
future
or
yeah,
or
we
can
also
maybe
try
to
find
more
people
inside
get
lot
more
opinions,
but
it
seems,
like
peoples
are
on
the
call.
Many
up
much
of
the
same
page,
I
hope
this
was
been
helpful
and
yeah.
If
you
would
like
to
move
this
discussion
into
an
issue-
or
there
is
already
one
actually,
please
tell
people
there,
so
we
can
continue
it
in
the
discussion.
A
I
A
Right,
well,
we
are
at
the
end
of
our
time.
I
just
want
to
thank
everyone
for
joining
and,
as
ice'
mentioned
in
the
beginning
of
the
session,
if
there
are
any
issues
coming
out
of
this
meeting,
please
apply
the
thing
big
label.
We
want
to
see
how
helpful
these
sessions
are,
how
much
value,
how
much
outcome
we
are
having
out
of
this
and
also
to
resurrect
respective
issue
and
for
your
feedback
that
I
left
at
the
end
of
the
notes
for
today's
session.
I
hope
this
was
useful.