►
From YouTube: GitHub Satellite India 2021 - The world's most elaborate CI workflow for an Angular library
Description
Presented by Lars Gyrup Brink Nielsen, Frontend Architect @ Systemate A/S
Using a GitHub Actions workflow running 50 jobs per workflow run, Node.js, and SonarCloud, Lumberjack maintains end-to-end compatibility across several versions of Angular and TypeScript in a single codebase.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
Hello,
what
a
lovely
day
I'm
lars
brink
from
system
made
in
denmark
and
today
I'm
going
to
be
sharing
how
we
applied
github
actions
to
a
library
I'm
maintaining.
So
this
is
about
a
library
called
lumberjack
and
let's
see
a
few
features
of
that
library.
It's
a
logging
library
for
angular.
It
has
six
configurable
logging
levels,
very
robust
error
handling
and
it
has
a
plugin
based
architecture.
A
As
you
see,
on
the
right
hand,
side
of
the
screen,
your
application
is
communicating
with
the
lumberjack
api
and
behind
that
is
one
or
more
log
drivers,
and
to
demonstrate
that
plugin
architecture
built
into
the
library
is
two
common
drivers.
A
browser
console
driver
that
will
display
the
logs
in
the
browser
console
and
an
http
log
driver
that
will
use
your
backend
with
a
simple
interface,
and
the
nice
thing
is
that
the
community
provides
more
drivers,
for
example,
for
azure
application,
insights
and
google
firestore,
and
you
can
even
build
your
own.
A
That
means
that
we
support
multiple
major
and
minor
versions
of
angular
from
one
major
version
of
lumberjack
version,
2.x
right
now,
a
bit
more
about
lumberjack.
We
have
six
d6
log
levels
and
angle:
has
the
concept
of
development
mode
and
production
mode
in
development
mode?
All
the
log
levels
will
be
active
by
default
in
production
mode.
The
debug
and
trace
levels
are
disabled.
A
So
we
wanted
this
cross
version,
compatibility
with
angular
type
script
and
related
dependencies,
so
we
looked
for
github
actions
to
solve
this
problem.
This
is
the
problem
we're
trying
to
solve.
As
you
can
see
here,
in
the
the
right
hand,
side
we
have
a
compatibility
matrix
between
angular
cli,
angular,
node.js
and
typescript.
A
A
This
was
an
initial
stable
version
of
our
library
and
we
thought
this
could
quickly
become
unmaintainable
because
several
versions
of
angular
released
each
year.
So
the
solution
was
we
wanted
to
use
the
angular
cli
workspace
structure.
You
see
part
of
our
repo
here
on
the
right
hand,
side,
and
we
wanted
a
single
source
code
based
solution.
So
you
can
see
we
have
the
lumberjack
app
is
a
demo
app.
It
has
an
end-to-end
test
suite
in
the
next
folder.
A
It
has
a
schematics
target
application
I'll
get
back
to
that,
because
it
also
has
an
end-to-end
test
suite
and
in
the
bottom
we
see
there's
a
bunch
of
tools
that
some
node.js
scripts
integrating
our
different
tool
chain
in
our
ci
workflow.
And
finally,
so
we
have
the
single
source
code
based
solution
and
will
have
a
github
actions.
Job
run,
per
combination
of
dependencies.
A
So
we
have
in
total,
50
jobs
being
run
per
ci
run
through
49
of
them
are
github
actions.
The
last
one
is
run
in
sonar
cloud.
We
have
between
10
and
30
jobs
run
in
parallel
we're
an
open
source
project,
so
we
get
basically
unlimited
github
action
minutes
from
github.
So
thank
you
very
much
for
that,
or
this
would
not
even
have
been
possible.
A
A
It
runs
a
production
library
built
using
the
latest
versions
of
all
the
tools
and
angle
and
so
on,
and
then
it
uploads
a
build
artifact
with
that
package,
which
is
exactly
the
package
that
will
later
be
published
to
npm
the
lint
job
runs
formatting
checks
and
checks,
the
lensing
rules.
It
also
uses
the
latest
versions
of
tools,
the
tool
chain
and
all
the
dependencies.
A
A
The
first
job
that
doesn't
depend
on
the
build
job
is
the
lib
or
library
job.
It
uses
the
latest
major
note
just
version
supported
by
angular
version
12.,
and
it
has
these
all
these
eight
versions
of
angular,
which
combined
have
fif
five
versions
of
typescript
supported,
so
we'll
have
a
ci
run
for
this
job
per
combination
of
dependencies.
A
Then
it
installs
the
typescript
version
and
other
related
dependencies
with
that
setup.
Out
of
the
way
now,
we
can
run
the
main
content
of
this
job,
which
is
run
the
unit
and
the
integration
test
for
our
development
projects,
which
are
test
utilities
internally.
For
the
library,
then
this
the
unit
and
integration
test
for
the
library
itself
and
finally,
we
even
have
unit
and
integration
test
for
the
angular
schematics
that
are
used
for
code
generation
and
code
mods.
A
A
A
So
typescript
has
this
concept
of
path,
mappings,
which
allows
code
to
import
code
using
a
package
name,
but
the
code
might
be
in
the
same
repo
if
you
set
up
the
path
mappings-
and
we
have
that
in
the
repo.
But
we
want
to
delete
that
so
that
the
next
step
step
here
makes
sense,
so
we're
downloading
that
build
artifact
from
the
build
job.
A
That's
the
package
that
will
ship
to
npm
we're
moving
it
into
node
modules,
folder
and
the
reason
for
that
is
this
next
step,
the
angular
compatibility
compiler,
it's
a
bit
of
a
temporary
solution,
because
angular
is
currently
migrating
from
the
previous
generation.
Compiler
called
view
engine
to
the
current
generation,
angular
compiler
called
ib
and
right
now
we're
in
a
situation
where
angular
libraries
are
compiled
with
the
previous
generation.
A
With
all
of
this
set
up
out
of
the
way
now
we
can
run
the
demo
applications
unit
and
integration
tests,
and
we
will
also
do
do
a
production
build
of
that
application.
So
we
have
an
end
to
end
on
the
unit
and
integration
test
level.
We
have
an
end
to
end
setup,
which
is
as
close
as
you
get
to
real
application.
A
The
next
job
is
the
end-to-end
testing
job.
We
see
the
same
setup
as
before,
only
one
version
of
node,
but
that
is
eight
matrix,
lags
in
total
and
we
have
exactly
the
same
setup
as
the
previous
job,
but
now
we're
running
end-to-end
tests
using
the
tool
called
protractor
that
will
use
a
real
browser.
In
this
case
we
install
the
latest
version
of
google
chrome.
Then
we
run
all
the
end
to
end
tests
for
our
demo
application
using
the
real
package
bundle.
A
The
final
job
we
have
is
the
schematics
and
time
testing
job
and
we
support
almost
every
version
here
in
this
setup.
There
is
one
detail
missing
about
angular
9.0
because
of
the
jest
issue
with
typescript,
but
we
feel
pretty
conf
com,
confident
that
that
we
support
even
version
9.0.
Since
we
we
are
testing
9.1
in
this
job.
We
have
the
same
setup
as
the
two
previous
jobs,
but
now
we
run
the
end-to-end
test
for
the
schematics
and
schematics
are
used
through
the
command
line.
A
A
A
You
have
probably
seen
this
setup
node
action
from
github
before
and
you
might
only
have
passed
it
a
single
version,
but
here
we
have
the
ci
matrix
and
github
actions.
So
we
have
two
versions
of
node,
so
there's
there
will
be
two
jobs
and
each
of
them
will
specify
version
of
node
that
we
interpolate
using
matrix.node
version.
A
A
But
if
you
look
closely
at
this
action,
it's
called
ng
worker,
slash
angle
versions,
action,
it's
a
package
or
a
github
action.
We
created
specifically
for
this
library,
but
as
we'll
see
in
a
minute
that
there's
it's
meant
to
be
reused
across
any
angular
library
for
for
ci
setup.
So
that's
pretty
nice.
A
We
have
this
purpose-built,
github
action
that
can
be
reused
and
we
have
already
got
an
interest
from
two
very
popular
angular
libraries.
So
we
look
forward
to
collaborating
with
them
for
them
to
use
our
github
action.
We
have
a
fast
parallelized
git
of
actions,
workflow
and
each
combination
of
dependencies
is
run
in
isolation,
both
both
for
our
unit
and
integration
test,
our
end-to-end
test
and
even
the
entrance
for
the
angular
schematics,
so
working
with
price
version
compatibility
is
suddenly
easy.
A
We
can
release
features
and
patches
across
eight
angular
versions,
six
typescript
versions
and
two
major
node.js
versions
from
a
single
source
code
base
and
every
time
we
manage
to
use
backwards,
incompatible,
api
and
syntax.
It's
immediately
detected
well,
not
locally,
but
as
soon
as
you
pass
it
to
you,
push
it
to
the
ci
within
six
minutes.
You'll
know
whether
it's
compatible
with
all
the
different
versions
and
if
it's
not
you'll,
know
exactly
which
combination
of
dependencies
has
the
issue
and
you're
even
technically
able
to
reproduce
that
using
the
github
action
locally.