►
From YouTube: OMR Architecture Meeting 20200423
Description
Agenda:
* Overview of Azure CI pipelines for OMR (#4995) [ @fjeremic ]
* Add GitHub Actions to Eclipse OMR (#5088) [ @fjeremic ]
A
B
So
this
is
just
gonna,
be
a
pretty
much
have
informal
walk
through
not
really
code
architecture
related,
but
on
the
less
related
to
Omar
and
the
build
architecture.
So
the
first
first
thing
I'm
going
to
talk
about
is
the
work
we
did
to
add
either
pipeline
support
for
the
x86
platforms,
Windows,
Linux
and
Mac
OS.
So
azure
has.
B
Partnered
with
with
github,
to
provide
10
free
concurrent
jobs
for
all
open
source
projects
on
github,
so
this
is
a
great
resource
we
can
take
advantage
of.
Currently
we
only
have
Travis
CI
and
up
there
running
for
Linux
and
Windows,
only
we
don't
have
Mac
OS
automated
builds
unless
are
triggered
by
ourselves
via
Jenkins.
B
So
this
is
kind
of
to
fill
the
gap
between
those
and
another
thing:
that's
different
about
the
the
Azure
pipelines
is
that
they
run
the
full
suite
of
all
more
tests,
whereas
the
azure
or
where's,
the
Travis,
and
up
there
only
run
either
built
or
some
linting
jobs,
or
a
small
subset
of
the
tests
that
we
run
so
azure.
Pretty
much
runs
the
exact
same
pipeline
that
we
run
on
our
jenkins
builds.
So
if
you
run
so,
if
you
fail
on
Windows
Linux
or
Mac,
are
you
gonna
fail
on
the
Jenkins
builds
as
well?
B
B
So
what
this
cache
file
does
is
it
currently
just
holds
a
holds
a
sha
within
the
repo
and
what
we
do
is
driven
the
pipeline.
We
we
have
this
file
along
with
the
current
the
current
architecture
running,
so
are
there
Linux
or
Mac
OS,
and
that
determines
which
see
cache
file
we
load,
unfortunately,
due
to
restrictions
of
Iser
pipelines
themselves,
the
the
cache
that
we
store
is
actually
read
only,
which
means
that
once
you've
created
a
cache
first
secret,
you
actually
can't
write
to
it.
B
The
next
time
you
trigger
a
build,
so
those
kinds
of
kind
of
gives
us
a
workaround
in
that
we
can
update
this
file
as
we
go
along
to
kind
of
refresh
the
cache
so
to
populate
it
on
the
next
build.
So
I'll
show
you
how
that
works.
So
if
I
click
on
the
check
mark
up
above
here,
I
can
see
that
the
azure
pipeline's
builds
are
down
at
the
bottom.
You
can
see
the
the
a
player
build
at
the
top
and
I
think
there's
a
Travis
build
somewhere
in
here
as
well
before
the
Azure.
B
So
if
I
click
on
the
details
here,
it'll
actually
bring
me
to
the
actions
get
of
actions
page.
So
azor
is
integrated
with
the
github
actions,
so
you
can
there's
two
ways
to
check
status
either
on
the
actions
page
or
to
the
azure
pipelines
themselves
and
the
test
summary.
It's
reported
by
processing
the
output
of
the
C
test,
XML
files
that
we
generate,
so
you
can
see
that
there
was
130
thousand
tests
ran
and
all
the
past,
which
is
what
we
want
to
see.
B
The
interesting
stuff
is
when
we
dig
deeper
into
the
pipeline
itself.
You
can
get
a
whole
bunch
of
different
stats
for
what
happens
here.
The
durations
of
the
various
builds.
So
we
can
take
a
look
at,
for
example,
the
Linux
job
and
see
all
the
steps
that
it
does,
this
kind
of
all
encoded
inside
of
the
pipeline
file
or
definition
itself.
So
some
of
the
things
that
we
care
about
here
is,
for
example,
the
save
and
restore
of
the
see
cache.
B
So
this
is
the
job
which
hashes
that
file,
sure
pipelines
cache
file
with
a
container
shop
and
then
it
extracts.
So
you
can
see
here
it
extracts
the
Linux
version
of
the
cache.
So
if
we
ever
want
to
refresh
the
cache,
we
can
just
write
to
that
file
and
it'll
refresh
the
cache
on
the
next
build.
We
can
also
automate
tests,
for
example,
once
every
week
once
every
month,
just
in
a
new
commit
on
top
of
the
master
just
to
refresh
the
cache
file,
so
we
can
kind
of
automate
that
refresh
leave
the
cache.
B
But
currently
that's
not
done
it's
all
manual.
So
you
can
see
here
that
once
the
cache
is
loaded,
there's
190
Meg's
worth
of
information
in
there.
Both
2k
files,
and
once
we
actually
build
the
project,
we
have
the
stats
again,
you
can
see
that
roughly
200
or
so
compilations
or
hit
in
the
cache.
Obviously,
what
that
number
to
stay
as
high
as
possible,
so
probably
periodically
refreshing
caches
is
really
beneficial
to
the
build
times.
B
Of
course,
if
you
modify
like
a
header
file,
that's
a
very
core
to
the
project,
like
header
file
that
everyone
includes
as
soon
as
that
to
modify
you
just
are
gonna
start
hitting
cache
misses,
that's
not
good.
We
kind
of
have
to
keep
that
in
mind
when
we're
reading
code
to
try
to
limit
the
number
of
includes
that
we
actually
have.
B
So
this
is
pretty
much.
It
there's
a
whole
bunch
of
different
stats.
We
can
gather
here
analytics,
for
example,
often
that
we
passed
the
pipeline
how
long
the
pipeline
takes
on
average.
This
one
was
pretty
interesting
kind
of
gives
the
breakdown
of
of
the
failures.
Are
they
related
to
the
test
or
the
build
itself?
Is
it
our
people
contributing?
Are
the
failures
due
to
testing
errors
so
catching
bugs,
or
is
it
just
compile
errors
things
like
that?
B
So,
as
time
goes
along,
we'll
be
able
to
build
more
and
more
stats
to
figure
out
what
kind
of
problems
people
are
having
and
can
improve
on
that
as
well
any
questions
pipelines
so
I
guess
what
the
goal
was
here
was
to
kind
of
streamline
and
improve
the
throughput
of
feedback
on
contributors
requests.
So
I
noticed
that
quite
a
lot
of
time,
people
would
be
waiting
for
out
there
or
Travis
CI
to
complete
their.
B
They
have
feedback
on
whether
their
tests
are,
for
example,
failing
or
whether
so
I
saw
submitters
even
sometimes
say
you
know,
I'm,
just
not
gonna
wait
for
out
there.
This
thing's
gonna
take
forever
I'm
just
gonna
merge
without
letting
that
chip
pass
so
kind
of
the
azure
pipeline.
Since
he
has
more
resources,
the
intent
was
okay.
We
can
get
the
information
to
the
contributor
much
faster.
A
B
B
C
C
B
B
C
B
C
B
C
Think,
like
from
the
github
action,
this
one
is
trigger
like
go
to
a
can
trigger
the
door,
but
we
build
and
we
can
also
can
also
trigger
the
Jenkins
and
also
run
those
like
build
and
test
directly
on
the
github
hosted
machines.
So
yeah
I
think
that
maybe
more
straightforward,
but
probably
the
azure
have
more
support
more
powerful.
B
Some
things
like
caching
is
really
easy.
With
with
hydro
pipelines,
the
definition
I'm
not
sure
how
equivalent
this
would
be
on
on
github
actions
yeah
because
they
have
a
custom,
see,
makes
job,
for
example,
yeah.
So
they
have
a
custom
task
for
creating
the
cache
I'm,
not
sure
if
there
will
be
an
equivalent
and
get
of
actions.
F
B
C
B
You
portion
the
second
piece
is
a
proposal
to
add
some
github
actions
to
the
Omar
project,
so
this
is
kind
of
the
the
actions
tab
that
we
talked
about
just
now.
We
could
have
done
the
Asscher
pipelines
as
a
github
action
itself,
so
github
actions
is
another
free
resource
that
we
can
use,
which
is
completely
free
for
open
source
projects
and
I
believe
they
kind
of
use
the
same
infrastructure
as
as
the
azure
runners.
Do
it's
completely
free.
B
They
don't
really
specify,
though,
how
many
parallel
jobs,
for
example,
or
how
many
actions
can
run
at
the
same
time,
or
things
like
that,
so
Sun
I
have
kind
of
a
sense
which
I'll
explain
in
a
bit
of
how
much
resources
they
do
permit,
but
it's
pretty
useful.
It
doesn't
seem
to
have
any
restrictions,
at
least
by
looking
at
the
docs.
So.
B
Cool,
that's
that's
good
to
know.
Okay,
I'll
talk
about
limitations
on
the
types
of
triggers
that
I
saw.
This
is
kind
of
a
a
way
to
automate
and
improve
the
project.
Efficiency
on
some
of
the
tasks
that
we
commonly
do
so
I'm,
proposing
to
add
three
different
kit
of
actions
and
I'll,
just
kind
of
walk
through
each
and
every
one
of
them.
So
the
first
one
is
to
mark
steel
and
and
and
and
close
sale
issues
in
PRS.
B
So
what
I
notice
is,
after
a
while
our
project
and
many
other
projects,
the
number
of
issues
and
the
number
of
pull
requests
grow
to
kind
of
an
unmaintainable
amount.
And
if
we
look
at,
for
example,
the
oldest
pull
request,
you'll
see
that
it's
probably
like
a
year
or
two
old.
So
it's
from
July,
14th
2018,
some
of
these
PRS
might
be
stale.
Some
of
them
might
require
quite
a
lot
of
work
to
rebase
on
top
of
the
current
master
branch.
B
Some
have
just
maybe
been
forgotten
about
or
from
contributors
that
are
no
longer
willing
to
contribute
to
the
project.
So
we
should
probably
close
those
off
or
figure
out
what
to
do
with
them
and
similar
thing
with
issues.
For
example,
often
people
open
up
an
issue,
ask
a
question.
The
question
gets
answered,
but
they
don't
close
the
issue
off
so
it
makes
it
seem
like
there
is.
You
know,
600
problems
in
know
more
when
you
know.
B
So
what
it
does
is
kind
of
it
looks
through
all
the
PRS
and
all
the
issues
and
if
it
exceeds
a
certain
number
of
days
where
nobody
gets
commented
on
and
there's
been,
no
action
led
to
it.
What
it
does
is.
It
applies
a
stale
label
to
the
issue,
and
then
it
puts
a
message
saying
you
know
this
issue
has
been
X
number
of
days
old.
If
you
want
to
keep
this
issue
open,
please
either
comment
on
the
issue
or
remove
the
stale
label.
B
Otherwise,
it's
going
to
be
closed
and,
for
example,
30
days
and
here's
an
example
of
a
stale
tissue
and
how
this
thing
looks
like
this
is
just
a
test
issue
on
my
own
repo
that
I
created,
hope,
tomar
and
create
a
bunch
of
pull
requests
and
issues
test.
How
these
things
work
out
and
what
you'll
see
happening
is
github
actions.
Plot
will
come
in
and
say
you
know
this.
This
issue
is
180
days
old.
B
It
applies
to
stay
label
now.
Other
committers
can
remove
the
state-level.
If
we
still
want
to
keep
the
issue
or
if
a
contributor
who
doesn't
have
the
power
to
remove
a
label,
they
can
just
comment
on
the
issue
and
it
will
not
get
removed.
So
this
is
just
kind
of
a
way
to
keep
track
of
these
stale
issues
and
after
30
days
passes
on
this
issue.
It'll
just
automatically
be
closed
by
plot.
B
B
B
Configurable
and
I'll
show
you
exactly
how
this
works
so,
instead
of
the
github
workflow,
it's
just
a
yamo
file
which
actually
specifies
what
action
do
you
want
to
use
this
one's
called
stale
and
it
specifies
a
repository
and
a
version
number.
So
some
comes
from
it's
the
the
actions,
slash
sale
repository
and
you
specify
a
message
how
many
days
you
want
to
wait
before
you've
marked
a
stay
under
shoe
sale
and
how
many
days
after
that,
do
you
want
to
close
it?
You
can
configure
it
labels
as
well.
B
So
it's
really
easy
to
add:
I
get
AB
action,
it's
just
a
workflow
yellow
file
which
specifies
what
it
does
and
in
the
background
what
this
thing
is
is
actually
just
an
unnotice
application
which
works
on
top
of
the
github
a
api's
to
carry
out
all
these
tasks,
that's
kind
of
the
first
one.
Now
this
one
runs
as
a
cron
job,
so
I
have
it
specified.
You
know
run
every
hour
yourself,
a
job
every
hour
scans
through
a
list
applies
labels.
A
B
G
Have
a
concern
with
that?
If
that
token
has
a
right
access,
then
some
and
okay.
So
if
like,
for
example,
this
workflow
was
triggered
on
a
pull
request,
someone
could
probably
you
know,
modify
this
yml
file
and
somehow
make
some
changes
to
the
repository
abusing
that
right
axis
and
open
a
pull
request
which
would
trigger
that
job.
What
is
that?
B
That's
actually
a
huge
limitation
of
github
actions
which
actually
the
get
up,
focused
and
really
ambition
for
whatever
reason
or
not.
So
what
happens
on
a
fork
if
you
have
a
fork,
when
you
submit
a
request
changing
one
of
these
files,
your
token
actually
gets
downgraded
from
a
rewrite
token,
to
a
read-only
token,
which
severely
limits
what
you
can
do
with
it.
For
example,
token,
we
don't
need
okay,
you
can't
add
labels,
you
can't
I,
don't
think
you
can
even
comment.
You
can't
leave
requests.
B
This
actually
severely
limits
what
kind
of
actions
can
do
and
the
next
action
is
kind
of
a
great
example
of
that
so
explain,
explain
now
what
we
did
to
work
around
that
issue,
so
the
pull
request
label
our
is
I
could
have
action
which
labels
pull
requests
based
on
the
files
that
are
changed.
So
this
is
kind
of
a
comment
task
for
us
committers.
You
know
you
go
in
a
PR,
a
new
PR
comes
along
somebody
changed,
for
example,
the
port
library.
Okay,
you
go
inside,
you
look
in
the
files
change.
B
Do
you
see,
okay,
all
the
files
change
in
the
port
library?
Let
me
add
the
comp
or
tag
to
it
or
the
label
to
it
to
the
PR,
so
this
can
be
actually
completely
automated
by
the
pull
request
labeler.
So
what
it
does
is
again,
it
scans
the
list
of
requests
coming
in
and
text
what
files
have
been
changed
and
if
it
matches
a
file
to
a
particular
label,
it
just
labels
the
PR,
so
here's
an
example
of
a
PR
modifying
drill
tests,
so
the
good
actions
bot
came
in
it's.
You
know
this.
B
This
PR
is
modifying
a
file
inside
of
the
FE
test,
compiler
drill
test,
so
it
applied
the
contest
and
contrl
labels,
and
this
is,
of
course,
completely
configurable
as
well.
If
they
go
back
to
the
root
of
the
repository
again
in
the
in
workflow
file,
there's
a
label
or
e
animal,
and
this
kind
of
defines
the
the
file
change
to
a
label,
nothing
and
I'm
kind
of
God
through
our
several
labels
and
figure
out.
B
A
A
B
Think
the
moment
it
would
I'll
have
to
double-check
the
implementation
but
I
think
I
didn't
it
would
that
would
be
one
limitation
of
the
github
action.
It
cannot
remove
labels
either
so
resentful.
If
somebody
accidentally
pushes
you
know,
I
change
to
some
file
and
then
the
bot
comes
in
and
adds
a
label,
and
then
the
contributor
realizes-
or
you
know,
I
didn't
mean
to
do
that
and
they
for
support
a
change
to
remove
that
change.
The
label
won't
be
removed.
B
Committer
would
have
to
do
that,
but
I
mean
doesn't
change
even
today,
commander
would
have
to
manually
do
that
anyways,
yes,
I
understand,
you're
concerned
about
a
github
or
a
committer
manually
wanting
to
override
what
about
those
so
I'll
talk
about
the
limitation.
Nazim
mentioned
right
now.
It's
a
good
point.
So
this
this
this
pull
request.
Labeler
is
actually
get
up.
Action
which
I
created
and
the
reason
why
we're
not
using
the
upstream
one
is
because
of
that
limitation.
B
This
is
called
a
cron
Leibler,
so
they're.
The
repository
explains
exactly
what
the
limitation
is
with
the
action
slash
label
it
probably
want
that
get
of
actions
actually
advertises
to
use
and
on
their
repository
or
on
their
action.
What
they
suggest
using
is
a
trigger
which
runs
only
when
they
pull
request
is
opened.
If
you
think
about
it,
this
is
really
what
you
want.
You
want
the
little.
B
You
want
to
run
the
label
or
label
the
files
and
then
be
done
with
it.
This
would
kind
of
solve
the
problem
that
you
mentioned
arrow
in
that
if
a
committer
or
later
comes
along
and
removes
labels
well,
the
bots
never
gonna
run
on
that
PR
again,
so
it
doesn't
matter
but
going
back
to
Ana's
Eames
question
earlier
because
of
the
limitation
of
your
token
getting
downgraded
from
a
read/write
token,
to
a
read-only
token,
when
you
open
up
a
request
form
of
work,
this,
this
action
actually
doesn't
work
and
there's
a
giant
issue
here.
B
So
this
kind
of
limits
us
in
how
much
data
were
allowed
to
process
because
the
Chrome
based
label
our
uses,
the
github
API,
which
only
allows
30
requests
per
minute
to
be
completed,
so
the
the
labeler
is
kind
of
a
or
this
cron
job
is
kind
of
aware
that
you
know.
I
only
have
a
certain
number
of
requests
which
I
can
do
and
certain
number
of
requests
that
I
could
process
and
who
knows
about
that
so
the
next
time
it
runs
it
processes
different
different
set.
G
I
I
was
also
concerned
about
the
fact
that
we
have
a
limited
sorry
if
the
get
up
tokens
were
being
actually
used
to
also
use
the
via
API
to
get
the
information
needed
to
do
this
job
yeah.
There
was
the
grade
of
rate
limitation
in
place
that
we
needed
to
be
aware
of
so
yeah.
Well,
thanks
for
referencing
that
yeah.
B
So
I've
configured
this
one
on
my
test,
repository
to
run
every
five
minutes,
so
I'll
show
you
how
that
looks
like,
for
example,
here
is
another
PR
modifying
the
port
library,
win32
directory
and
it
chose
to
add
you
know:
windows,
port
and
x86
to
that
one
again,
this
is
just
configurable.
So
the
way
this
works
is
on
the
actions
tab.
All
the
chrome
jobs
are
listed
here,
so
we
have
three
of
them
and
I've
set
it
to
run
every
five
minutes.
B
You
know
sometimes
see
that,
for
example,
the
Porco's
labeler,
sometimes
github
doesn't
have
enough
resources,
so
it
ends
up
waiting
longer
than
five
minutes.
This
one's,
for
example.
You
know
seven
minutes
ago
in
30
seconds
ago,
so
it's
kind
of
like
six
and
a
half
minutes.
It
waited
I,
sometimes
do
see
jobs
piling
up
depending
on
the
time
of
day.
B
G
So
one
more
question,
sorry,
and
so
one
more
question
I
had
was:
you
could
set
up
multiple
secrets
and
like
to
multiple
you
get
up
tokens
for
each
workflow
so
that
it
can
like
we
can
do
more
with
github
actions
such
as,
let's
say
something
to,
for
example,
do
whitespace
checks,
so
that
would
require
just
checking
for
all
the
changed
files,
which
would
also
require
using
github
API.
And
if
it's
triggered
on
a
pull
request,
then
it
has
to.
It
will
be
running
quite
a
bit.
So
maybe
we
could
have
example.
G
B
G
B
Think
yeah,
due
to
the
limitation
of
of
the
actions
tokens
getting
downgraded,
though
it's
really
like,
for
example,
the
whitespace
check
I'm
sure
that
that's
a
read-only
operation,
but
if
you
want
to
act
on
it,
for
example,
if
you
want
to
add
a
label
or
submit
a
comment
or
something
like
that,
that
requires
right
access,
so,
in
which
case
you
wouldn't
be
able
to
do
that.
We.
A
B
A
E
B
B
So
if
you
look
inside
of
the
repository
for
the
second
or
third
getup
actions
here,
it
references
the
issues
where
the
get
the
folks
on
the
github
action
development
team
talked
about.
So
it's
actions,
label
or
twelve
and
I.
Think
there's
another
one
for
the
first
time,
contributor,
I,
think
it's
for
you
I,
think
yeah.
This
one
so
I
suggest
having
a
read
through
both
of
these
issues,
they're
kind
of
hidden
in
there,
but
they're,
probably
the
most
downloaded
answers
by
the
get
the
team
on.
Why
that
wouldn't
work.
B
Okay,
I
think
the
the
last
action
that
I'm
proposing
we
add
is
the
first
time
contributor,
this
one's
kind
of
kind
of
a
welcoming
greeting
to
any
new
contributors
to
a
project
and
what
I
found
is
in
the
past.
If
I,
look
at
the
contributions
from
first-time
contributors,
I
usually
see
a
couple
of
things
that
are
almost
always
wrong:
they
don't
know
that
they
need
to
sign
the
ECA.
B
They
don't
know
even
how
to
do
it,
they're,
not
adhering
to
their
contribution
guidelines
or
pull
requests,
and
they
have
no
idea
where
to
ask
for
help
so
they're
kind
of
just
the
three
things
I
was
able
to
think
of.
Of
course,
there's
probably
tons
more.
We
can
customize
this
message
in
any
way
we
want.
So
what
this
this
github
action
does
again.
It's
based
on
a
chrome
shell,
which
we
have
to
implement,
and
it
just
scans
a
list
of
pull
requests.
B
If
it
determines
that
you're
a
first-time
contributor,
it
just
displays
a
nice
welcoming
message
saying
you
know:
hey
thanks
for
the
contribution.
If
you
haven't
had
a
chance,
please
take
a
look
at
our
guidelines
or,
if
these
a
check
files
close
to
the
legal
consideration
suction,
to
figure
out
what
you
need
to
do
to
make
it
pass,
and
it
gives
us
links
to
how
to
attract
to
compete
with
the
community.
Join
our
slack
works,
basic
cetera
and
then
in
mark
marks.
B
So
yeah
that's
kind
of
all
the
get
up
actions
that
I
thought
we
should
kind
of
start
with.
Just
to
get
our
feet.
Wet
I
will
take
the
to
do
about
the
labeler
and
prevent
it
from
flying
labels
to
pull
requests
which
already
have
labels
present.
That
should
be
pretty
easy
to
get
them,
but
other
than
that
any
feedback
is
welcome.
We
can
just
start
off
with
probably
one
of
the
github
actions
and
continue,
so
you
have
more
as
we
find
them
useful.
G
So
when
you
were
talking
about
the
first
part
about
Asher
and
moving
away
from
privacy
and
Charlie,
so
I
can
immediately
see
that
we
can
make
use
of
pail
of
actions
to
run
the
linty
job
and
use
github
machines
for
that.
So
what
do
you
think
of
like
having
that
as
one
of
the
starting
points
and
then
disabling
the
Travis
here,
I
linter
job.
B
A
G
Yeah,
so
you
can
specify
files
like
paths,
that'll,
be
part
of
the
trigger
parameters,
so
you
can
say
trigger
on
pull
request
on
these
specific
files,
or
you
can
even
say,
exclude
on
for
these
specific
directories
or
only
run.
If
you
know
something
is
merged
into
master
or
some
like
that,
so
yeah
it
for
feature
related
feature
specific
or
I
mean
that
specific
job
triggers
it's
pretty
trivial
to
set
that
up.
B
B
B
B
F
I
think
that
one
of
my
concerns
is
just
not
having
to
continuously
go
and
make
sure
that
things
that
are
created
as
the
backlog
of
to-do
items,
making
sure
they
don't
get
cleaned
up,
because
that
seems
like
a
an
error-prone
process
right,
especially
given
the
amount
of
volume
that
I
get
on
my
github
light.
Trying
to
sift
through
all
of
this
would
just
be
another
nightmare,
I'm
wondering
if
that's
one
way
we
can
think
about
it
is
with.
B
So
this
job
has
a
bunch
of
configuration,
so
one
of
the
ones
I
highlighted
here
is
you
can
exempt
PRS
from
getting
marked
as
steel
based
on
messages
based
on
labels
based
on
other
things.
That's
kind
of
already
built
into
the
tool.
I
know
for
backlog
items
were
pretty
vigilant
about
marking
it
as
such,
like
Help,
Wanted
or
backlog,
or
something
like
that
yeah,
but
I
mean
if
an
issue,
for
example,
if
it
hasn't
been
looked
at
in
two
years,
what
are
the
chances
it's
gonna
get
looked
at
at
all.