►
Description
Weekly update issue for feedback: https://gitlab.com/gitlab-org/incubation-engineering/no-code-low-code/meta/-/issues/23
0:05 Why workflow automation
1:14 Why taking an MVC approach
1:58 Demo
3:52 Limitations & gaps
A
Hi
folks
welcome
to
the
incubation
engineering
update
on
local
and
no
code.
I'll
share
some
update
on
the
workflow
automation.
So
let
me
quickly
reiterate
on
the
million
dollar
question:
why
workflow
automation
at
gitlab,
we
automate
a
total
of
130
business
shoes
that
carry
our
day-to-day
operations,
for
example,
apply
and
backlog
label
to
an
issue
in
order
to
acknowledge
the
future
requester.
We
have
in
fact
open
source.
A
This
repo
contains
all
these
rules
to
demonstrate
and
instructions
for
the
setup,
but
the
customers
are
telling
us
there's
quite
a
bit
of
overhead
to
set
it
up
and
they
just
want
it
out
of
the
box.
To
be
honest,
we
have
lots
of
customer
asking
for
it
one
of
the
most
uploaded
issues
that
gitlab
is
configure
label
to
be
removed.
When
an
issue
is
closed,
it
has
attracted
192
uploads.
A
So
far,
unfortunately,
we
haven't
closed
this
Gap,
since
we
don't
want
to
introduce
yet
another
hard-coded
checkbox
on
the
settings
page,
and
we
know
that
we
want
a
more
generic
and
extensible
solution.
Finally,
our
competitors
like
GitHub
and
jira,
have
already
offered
similar
capabilities
for
some
time
now
and
their
customers
love
it.
If
you
like
to
read
more
about
the
justification
or
the
product,
Vision
I've
linked
excellent
summary
from
Kate
weaver
or
group
4pm
from
the
plan
and
project
management
team
in
the
issue
of
this
update.
So
let's
talk
about
why
taking
an
MVC
approach?
A
To
be
honest,
it's
a
significant
undertaking
to
build
a
zapier
equivalent
into
gear
lab,
but
we
have
to
start
from
somewhere.
One
option
is
to
build
from
the
ground
up
by
rolling
out
an
event-driven
architecture
with
event:
bus
standardized,
schema,
encoding
protocols,
routing
strategy,
transformation,
rule
language
and
visual
flow
Builder,
while
building
up
the
confidence
for
investing
to
this
more
full-fledged
architecture.
A
So
the
question
is:
do
we
have
a
viable
MVC
to
pursue
and
the
answer
is
yes,
our
Ruby
Jam
gitlab
triage
has
been
in
service
for
five
years,
with
a
rich
set
of
declarative
rules
and
extensibilities
through
the
Ruby
expression
and
plugin
system.
So
in
my
opinion,
the
jam
is
a
great
starting
point
to
bring
highly
configurable
workflow
automation
to
our
users
today.
So
let
me
quickly
show
a
demo
from
my
Dev
environment.
A
Now
with
that
configured,
let
me
now
create
a
new
workflow
and
click
on
configure
pipeline.
So
now
I've
got
a
workflow
that
is
from
the
template.
You
can
see
I'm
trying
to
add
a
backlog
label
to
a
newly
created
issue
and
have
a
condition
when
the
issue
is
still
open
and
without
any
label
applied
and
I'm.
Gonna
I
have
two
labels,
backlog
and
Def
I'm
gonna
mention
Roots.
Maybe
let's
change
that
to
mention
a
more
realistic
scenario,
which
is
a
team
with
that.
A
A
Just
save
that,
let's
go
back
to
our
previous
issue
and
just
hit
close,
you
can
see
immediately
the
automation
remove
backlog
label
and
this
is
about
the
demo,
and
there
are
still
some
gaps
needs
to
be
closed
before
the
productionization,
as
I
mentioned
earlier,
you'll
be
great.
If
we
could
remove
the
menu
token
configuration
steps,
we
also
need
to
find
a
way
to
bring
the
automation
from
the
product
level
to
the
group
level,
and
so
those
rules
can
be
applied
to
all
the
products.
In
a
group
the
execution
is
currently
based
on
polling.
A
So
it's
it's
been
efficient,
so
we
should
modify
the
3rd
gem
in
order
to
process
a
payload
to
respond
to
events
so
and
that
shouldn't
be
too
hard.
Another
concern
is
the
the
circular
execution,
so
as
one
update
triggers
another
one
indefinitely,
we
need
to
find
a
way
to
prevent
that
as
well.
We
need
to
figure
out
how
to
enable
users
to
monitor
the
workflow
execution
for
debugging
purposes,
and
that
is
really
important,
so
I'm
reusing
the
the
set
template
editor
for
editing
the
workflows
and
that
components
need
some
generalization.