►
From YouTube: NEAR EVM Working Group Update [2021-04-16]
Description
Follow the latest from NEAR Protocol on:
Website: https://near.org/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol
A
Hello,
everybody
welcome
to
the
evm
working
groups
weekly
update.
This
is
our
first
update
in
two
weeks
today.
Last
week
we
were
very
busy
with
planning
for
q2.
So
let's
catch
up
here,
I'm
sharing
my
screen.
Hopefully
everybody
can
see
that
our
current
goal
has
changed
at
long
last
now
we
are
no
longer
working
towards
a
business
deployment.
We
are
working
towards
the
mainnet.
A
This
net
was
deployed
a
couple
weeks
back.
We
are
still
finishing
supporting
documentation
for
it
and
standing
up
proxy
servers
and
so
on,
so
that
people
don't
have
to
do
that
themselves,
but
we
are
shifting
towards
thinking
about
the
main
net
release
and
that
will
happen
during
q2.
We
will
share
a
more
detailed
roadmap
next
week.
B
Yeah,
so
on
my
site,
I
was
heavily
involved
in
management
of
the
aurora
release
as
you,
as
probably
some
of
you
have
seen
it
with
the
rainbow
bridge
release
it.
It
includes
not
only
the
product
itself,
but
also
some
partners
that
are
using
this,
and
also
some
incentives
for
people
that
are
starting
to
use
it,
marketing,
support
and
stuff
like
that.
So
I'm
trying
to
align
this
then,
together
with
arto
and
marcelo,
I
was
working
on
well.
B
I
was
designing
the
initial
draft
for
for
bridge
and
ear
certificate
tokens
inside
of
evm,
and
we
have
finalized
the
design
of
this
yesterday.
B
So
right
now
we
know
how
to
do
this
pretty
convenient
and
straightforward
way.
It
will
be
simple
to
implement
with
existing
bridge
infrastructure.
B
Yeah
and
also
I
was
fixing
some
of
the
bugs
with
the
rainbow
bridge
which
which
are
not
that
critical
here,
but
one
of
the
things
that
I
want
to
mention
is
that
berlin,
hard
fork
happened
yesterday
and
unfortunately,
it
caused
the
downtime
for
the
bridge
for
like
half
an
hour
or
something
like
that.
We
needed
to
update
geth
instance.
It
was
not
working
properly
yeah
but
in
general
everything's
good
moving
forward.
A
The
bridge
issues
to
do
with
the
brain,
hard
fork,
yeah,
okay
and
on
on
my
end,
I
was
unavailable
away
from
keyboard
most
of
last
week,
but
this
this
week,
catching
up
and
dida
did
a
whole
bunch
this
week.
So
we
did,
of
course
the
the
q1
review
and
q2
planning
which
will
present
next
week.
A
A
Most
importantly,
I've
been
working
on
the
relay
this
week,
so
the
relay
was
at
the
product
stage.
Still
a
couple
of
weeks
back
and
in
order
to
be
able
to
offer
public
endpoints,
we
need
to
move
that
towards
production
readiness.
A
So
there's
a
substantial
amount
of
work
on
on
that
improving
the
quality,
simplifying,
improving
the
go
ethereum
compatibility
so
that
we
return
the
same
error,
codes
and
and
so
on
and
validating
the
supported
methods
one
by
one.
So
the
most
most
recent
matrix
can
be
found
here.
A
This
this
table
is
up
to
date
and
a
lack
of
fun
entry
means
hasn't
been
fully
validated.
Yet
green
means
it's
fully:
okay,
yellow
means,
probably
working,
but
something
still
to
be
done
and
right.
We
want
support,
and
also
I
put
in
place
some
ci
for
all
of
the
aurora
projects
that
I'm
working
on.
I
recommend
everybody
does
the
same.
C
This
week,
testing,
how
is
our
and
I
successfully
complete
any
key
141
testing,
fundable
tokens
and
fixed
box
related
with
ep
7
12,
and
I
think
for
that
time
we
covered
about
80
percent
of
integration
tests
most
difficult
part
related
to
signing
message
for
ep
712,
and
I
think
in
our
first
first
part
or
of
next
week.
We
should
complete
our
testing.
A
C
I
I
mean
integration
tests
for
functionality
related
to
2s,
connector
related
to
fungible
tokens
and
for
near
accounts
and
ethereum
accounts.
A
Okay.
Let
me
mark
that
here.
B
You
again,
most
probably
later
during
this
call,
let's
discuss
the
eip712
because
it
seems
like
in
the
new
version
of
the
of
how
we
are
going
to
bridge
stuff.
Perhaps
we
do
not
need
this
functionality,
so
users
are
going
to
actually
use
some
other
ways
how
to
withdraw
funds
from
the
evm.
A
Yeah,
let's
put
that
on
the
agenda,
you
can
maybe
present
alex
the
the
design
for
the
elc
20
connector.
D
Yes,
and
so
the
evm
bully
sends
the
abortion
code
data
now
to
the
aurora
engine
for
begin
chain
and
begin
block.
I
also
added
exponential
backup
for
transactions,
because
when
you,
when
you
run
them
on
on
the
test
net,
you
know
sometimes
they
fail.
While
implementing
that,
I
also
found
a
bug
in
the
javascript
api.
D
The
aurora
engine
sets
the
chain
id
correctly,
and
so
it
basically
was
possible
to
replay
transactions
until,
like
said
to
begin
chain
all
the
blocks
and
then
the
first
transaction,
which
then
fails
with
fatal
error.
D
So
the
chain
id
check
works,
but
then
it
fails
with
like
some
internal
error,
which
is
still
marked
in
the
engine
as
a
tudo
and
basically
yeah.
We
can
go
from
here
in
multiple
directions.
I
think
the
the
most
pressing
one
is
to
have
better
error
messages
bubble
up
from
the
engine,
so
I
can
iterate
from
there
and
see
what
the
causes
are
and
other
things
that
we
need
is
run
it
locally
batching
and
transferring
genesis
state
to
the
engine.
A
Genesis
state
to
begin
with
the
run:
okay,
we
don't
have
ilya
today,
I
don't
believe
and
joshua's
updates.
Let
me
see
here
right
so
joshua's
updates
he's
working
on
the
bn
128
pre-compiles,
so
those
are
still
for
the
istanbul
hard
fork.
We
had
to
re-implement
those
for
context.
Here
we
had
to
implement
those
given
that
we
basically
rebooted
the
evm
implementation
in
february,
going
going
back
to
the
contract
even
as
a
contract
approach,
so
he's
pulling
over
the
code
from
from
near
core
that
we
we
had
there
previously.
A
E
Good
yep
this
week
I
was
doing
some
review
of
the
code,
obviously
just
to
make
sure
I'm
familiar
with
what
we've
got
and
I
was
reviewing
the
ease
connector
stuff
a
little
bit.
That's
all!
Looking
pretty
good!
I
submitted
you
know
a
small
small
addition
to
it
and
I
I
was
working
on
the
issue.
That's
opened
about
the
contract
size,
the
binary
size.
A
E
So
I
did
get
to
the
bottom
of
it,
but
the
answer
is
not
very
satisfying,
so
I
mean
I
I
don't
know
if
we
want
to
do
too
much
detail
here.
I
I
did
put
several
comments
on
the
on
the
issue,
so
I
can
go
into
more
detail
if
desired,
but
the
long
story
short
is,
we
probably
won't
be
able
to
fix
it
in
the
near
future.
We'll
have
to
wait
a
little
bit.
A
Okay,
yeah,
I
saw
the
comments
and
sounds
like
even
given
this
dependency.
We
are
not
likely
to
be
able
to
fix
it,
but
hey,
I
mean
at
least
it's
triaged
and
we
know
what
the
reason
is
and
we
can
plan
to
someday
to
fix
it.
So
this
is
good
okay,
so
the
this
has
been
troubleshooted.
Then
the.
A
A
A
A
Very
good
and
yeah:
let's
talk
about,
do
you
still
have
something
to
do
from
this
week's
to-do
list
or
or
you
can
take
new
tasks.
E
A
E
A
Okay,
you
evgeny:
how
do
you
feel
about
coming
out
of
draft?
Is
that
something
next.
A
A
Okay,
so
we
we
can
you're
not
planning
to
push
too
much
more
to
it
or
how
does
it
look
from
your
end?
It's
mostly
testing.
Now
I
see.
C
A
All
right,
then,
then,
what
I
would
plan
to
do
here
is
that
I
will
deploy
a
new
version
of
the
contract
as
it
is
now
to
to
desnet
embed
on
it
and
after
that,
we
we
merge
this,
and
then
we
give
it
some
time
to
to
stabilize
and
master
before
we
deploy
upgrades
so
much
much
happening
in
the
next
days
for
sure,
okay,
so
discussion
oops.
That
was
the
old
one
here
next
next
week
we
have
a
benchmarking
task.
That.
E
A
Need
to
talk
about
but
alex,
why
don't
you
begin
with
presenting
what
you
did
on
the
rc20
connector
I'll
stop
my
sharing.
B
Or
can
you
give
me
also
the
host
or
okay?
No,
I
can.
I
can
do
it
right
now.
Okay,
I
didn't
need
to
have
those.
Are
you
able
to
see
my
screen.
A
B
Okay,
so
this
is
a
little
bit
complicated
thing,
but
let's
I
will
try
to
to
spend
not
a
lot
of
time
here.
So
so
the
way
how
how
the
connector
for
the
erc20
connector
is
working
right
now
is
the
following:
there
is
a
locker
account
or
a
locker
contract
on
ethereum
site,
the
locker
account.
If
a
user
would
like
to
lock
some
tokens,
it
calls
the
lock
method
of
the
locker
account.
This
lock,
lock
method
does
transfer
from
the
sender
and
emits
the
event
this
event
there.
B
For
this
event,
then,
we
are
able
to
build
a
merkle
merkle
proof
which
can
be
submitted
on
the
near
side
to
contract
that
is
called
factory
to
the
method
deposit.
So
this
proof
is
submitted
there.
B
It
is
decoded
and
verifies,
and
at
the
moment
when
it
is
decoded
and
verified,
it
calls
the
ethereum
client
on
near
ethereum
like
client
and
near
and
approver
contracts,
and
then,
when
everything
is
done,
then
there
is
a
separate
contract,
which
is
the
nap141
that
corresponds
to
the
erc20
that
was
locked
on
the
ethereum,
and
then
this
contract
is
actually
maintained,
the
tokens
and
transferring
into
the
users.
B
B
So
here
is
the
way
how
we
are
going
to
update
the
factory
and
also
how
what
we
are
going
to
introduce
on
the
evm
side
in
order
to
to
allow
these
transfers.
B
So,
first
of
all,
we
are
going
to
change
a
little
bit,
the
way
how
factory
works
and
the
way
how
we're
going
to
change
it
is
the
following
in
the
lock-in
in
the
lock-in
event,
we
see
here
the
here,
the
the
recipient
of
the
transfer.
B
Previously
we
have
been
using
this
field
for
near
account
only
so
this
should
be
available
in
your
account.
Obviously,
we
do
not
check
it
on
on
the
ethereum
site,
so
this
is
just
a
string.
Now
we
are
going
to
treat
recipient
in
a
different
way.
B
B
In
this
case,
I'm
saying
that
the
message
is
no
yeah,
so
there
is
nothing
after
so
there
is
a
method
analyze
yeah
recipient
there
is,
there
is
nothing
after
the
column
or
the
column
is
absent,
so
we're
just
we're
just
maintained
we're
just
asking
nap
correspondent
nap140.
We
want
to
mint
some
tokens
for
for
the
user.
B
However,
in
case
there
is
something
after
the
column
or
and
the
column
is,
is
presented
there,
and
then
we
treat
this
as
a
some
kind
of
message
that
needs
to
be
transferred
to
a
smart
contract
that
comes
before
the
column.
So
literally,
we
are
calling
an
np141
function
that
is
called
ft.
Transfer
call
that
is
specifically
designed
to
transfer
some
tokens
to
a
smart
contract
and
call
a
function
inside
of
this
contract.
B
So
the
way
how
this
transfer
call
is
working,
yeah
and-
and
we
are
passing
message
to
this
to
this
call
and
also
a
predecessor
id
or
the
the
the
contract
that
or
like
the
the
user.
Who
is
calling
this
function,
calling
this
deposit
so
the
way
how
ft
transfer
call
is
working,
it
just
adds.
So
this
is
the
function
in
np141.
B
It
transfers
the
tokens
and
calls
a
function,
a
specified
function
that
is
called
ft
on
transfer
in
the
recipient
contract,
and
it
says
what
is
the
amount
that
was
transferred
and
it
passes
the
message
there
and
then
this
iftan
transfer
returns
the
unused
tokens
and
then
used
tokens
are
returned
back
to
the
user.
So
pretty
simple
call,
and
now
we
are
making
our
evm
to
have
an
ft
on
transfer
method
yeah.
B
So
in
order
to
so
so
I'm
saying
so
if
the
user
yeah
one
step
back,
if
the
user
would
like
to
transfer
something
to
to
the
evm
to
inside
of
the
evm,
they
need
as
recipient
here.
In
the
in
the
first
locking
event
say
that
this
is
aurora
column
and
then
some
additional
information
and
in
a
second,
we
will
see
what
is
the
additional
information
and
then
nap141
does
the
ft
on
transfer
call
of
aurora
contract
or
the
evm
contract.
B
So
we
have
this
function
here,
ft
on
transfer
and
from
the
message
we
are
actually
getting
the
information
who
who
was
who
was
sending?
Who
is
the
actual
recipient
of
the
transfer?
What
is
the
ethereum
address?
Who
is
the
recipient
for
inside
of
the
message?
We
will
see
the
fee
to
the
real
layer
and
since
we
have
their
predecessor
id
of
the
caller,
we
have
the
real
layer,
the
near
account
of
the
layer.
So
we
are
decoding
the
everything
here
from
the
message.
B
B
So
we
need
to
have
some
kind
of
mapping
of
tokens
of
nap
141
tokens,
2,
c20s
or
like
aurora
earset
one
is
yeah,
and
then
we
are
able
to
to
mint
some
tokens
there
and
in
case
fee
specified
fee
is
not
zero.
Then
we
can
find
a
respective
address
in
the
mapping
of
the
real
layers
yeah,
because
here
the
relayer
in
this
line
is
the
near
account
and
we
need
to
figure
out
where
to
send
the
fee
that
was
specified
by
the
user.
F
One
small
notes
of
theon
transfer-
I
think,
only
has
a
separate
argument
for
the
sender,
so
you
don't
have
to
encode
predecessor
id
in
the
message,
because
well
it's
normal
functionality
any
account
that
responsible
wants
to
know
who
which
contract
or
which
consented.
So
there
is
a
separate
field
for
that.
No
need
to
yeah.
B
So
we
need
to
check
I
I
we
need.
We
need
to
make
sure
that.
Well,
obviously,
we
do
not
want
to
use
the
sender
id,
because
it
has
some
implications
similar
to
to
ethereum
implications.
B
So
we
need
to
some
kind
of
understand
how
to
pass
the
the
the
person
or
like
the
the
account
that
was
called
in
the
factory
deposit
method
that
resulted
in
call
of
the
nep
ft
transfer,
call
that
resulted
in
call
on
ft
on
transfer
yeah.
B
So
let
let's
take
a
look
at
here
so
so
this
is
the
way
how
we
are
passing
the
information
to
to
evm
and
now.
The
question
is
how
we
are
going
to
allow
people
to
withdraw,
withdraw
tokens
from
the
evm,
and
in
order
to
to
do
this,
we
actually
need
to
add
a
pre-compile
that
we
can
call
exit
to
ethereum
pre-compile.
B
This
is
a
separate
contract.
It
will
be
on
a
fixed
address
located
in
evm
and
it
will
have
one
method:
withdraw
yeah,
so
you
see
erc20
a
mountain
recipient
and
this
precompiled
it
will
what
it
will
do.
It
will
actually
check
that
the
user
has
enough
enough
amount
of
erc20
yeah.
It
will
be
able
to
to
well
what
it
will
do.
It
will
remove
or
like
burn
some,
your
c20
from
the
user
and
call,
and
so
so
aurora
is
going
to
call
a
method
of
the
of
the
bridged
np141
that
is
called
withdraw.
B
This
is
the
natural
way
how
how
how
the
bridge
is
used
right
now,
a
user
needs
to
call
withdraw
of
the
token
contract.
This
specific
method.
It
is
very
specific
only
and
it
exists
only
for
the
bridged
tokens
yeah.
So
there
is
a
precompile
user
calls
it
with
an
ordinary
evm
transaction
that
can
be
signed
by
manomask
and
then
aurora
at
this
moment.
Does
the
cross-contract
call
to
withdraw
function
and
then
everything
everything
works
as
usual.
So
this
withdrawal
then
calls
factory
the
finish
withdraw
method.
B
Then
there
is
a
specific
receipt
id
created
and
then
the
receipt
id
from
the
receipt
id.
We
are
calculating
the
like
client
proof
and
we
are.
We
are
putting
this
proof
in
on
the
ethereum
side,
in
the
unlock
method
of
the
locker.
B
A
good
thing
about
this
is
that
we
potentially
we
can.
We
can
do
absolutely
the
same
for
also
not
bridge
tokens
yeah.
So
if
we
have
a
separate
nap141
for
this,
we
we
would
need
to
have
an
ability
to
transfer
this
inside
of
evm
and
outside,
and
the
good
thing
is
that
we
are
going
to
use
absolutely
the
same
methods.
We
are
going
to
simply
say:
ft
transfer
call.
B
So
if
a
user
who
owns
some
wrapped
near
will
do
an
ft
transfer
call
to
aurora
with
a
specific
message
which
specifies
the
in
this
case
zero
fee
and
also
the
message
who
is
going
to
be
the
recipients
of
this
funds
in
in
the
evm,
then
he
will
be
able
to
transfer
this
this
ramp
near
to
to
aurora
and
in
order
to
withdraw,
we
need
to
create
an
additional
precompile
which
we
can
call
exit
to
near,
and
it
will
work
almost
the
same
as
the
exeter
theorem
precompiled,
with
the
difference
that
it
is
go
not
going
to
call
withdraw
function,
but
it's
going
to
call
the
ft
transfer
function
and
this
transfer
will
transfer
tokens
from
aurora
to
the
near
user.
B
So
yeah,
to
conclude,
just
to
give
you
a
sense
of
what
contracts
are
holding,
what
tokens
yeah.
So
on
the
ethereum
side
in
case
p,
person
is
transferring
year,
c2
one
is
to
near
it
doesn't
matter
whether
it
is
going
to
be
a
a
near
native,
runtime
or
or
evm
or
aura.
The
user
eventually
transfers
his
tokens,
your
c22,
the
locker
account
and
year
c20s,
are
stored
in
the
locker
account
on
near
side
tokens
either.
B
In
case
user
would
like
to
work
with
aurora
runtime.
Then
the
contract
that
is
stored
in
his
tokens
is
actually
aurora,
so
aurora
stores
the
tokens.
However,
inside
aurora
we
have
erc20s
or
like
aurora
erc20s
and
inside
of
that
contracts.
We
have
the
specification,
the
mapping
of
what
what
ethereum
addresses
are
owned
and
what
tokens
so
yeah,
multiple
layers
dream
inside
of
a
dream,
but
this
is
the
most
natural
way
how
to
implement
this
and
make
it
a
interoperable
with
all
of
the
naps
141.
A
Okay,
did
you
already
discuss
this
with
marcelo
as
well.
B
Yeah,
that's
correct,
so
we
we
have
discussed
this
with
marcelo
and
yeah,
so
he
is
he's
pretty
clear
with
this.
He
understands
it
fully.
I
would
say.
B
Yeah,
okay,
he
will
probably
need
some
would
need
some
help
on
on
the
evm
side,
but
he
is
he's
keen
on
learning
this
stuff.
A
Okay,
well,
he
can.
He
can
come
to
me
as
a
first
point
of
contact
and
then,
of
course,
maybe
you're
getting
will
also
be
able
to
to
help
him,
and
I
certainly
need
to
need
to
align,
given
that
they
will
be
dealing
with
the
same
callback
functions.
B
Yeah
yeah,
so
so
this
is,
this
is
yeah.
I
wanted
to
just
wanted
to
mention
for
for
evgeny
that
for
f
well
breached
f,
as
you
can
see
here,
the
actual
nap
141
contract
and
of
the
aurora
contract.
They
need
to
be
merged
together,
so
we
are
actually
going
to
schedule.
B
The
ft
transfer
call
from
aurora
to
aurora
yeah,
so
this
is
going
to
be
a
little
bit
more
complicated
and
a
little
bit
messed
up,
but
in
general
everything
is
going
to
work
absolutely
the
same
way
as
with
any
nap141
here
and
as
you
can
see,
there
is
no
need
here
for
the
user
to
sign
eap712
transactions,
which
is
kind
of
cool,
though
at
the
cost
of
the
introduction
of
two
additional
pre-compiles
in
in
aurora
yeah.
B
So,
let's,
let's
sink
on
this
gained
with
you
and
once
again
go
step
by
step
with
this
stuff
and
understand
what
what
needs
to
be
changed
for
the
ether
connector.
B
A
Yeah,
all
right
so
for
next
week
a
couple
of
important
things
so,
of
course,
we're
going
to
to
finalize
and
publish
the
roadmap
and
okrs
for
q2.
That
will
no
doubt
be
of
a
wider
interest.
A
Now,
there's
a
there's,
a
question
and
an
ask
from
from
ilia
and
the
contract
runtime
team
that
we
we
need
to
figure
out
the
discrepancies
in
the
in
the
gas
use
with
aligning
with
bo
nikolai
and
alexa.
So
michael,
this
would
be
a
pretty
good
task
for
you.
I
think,
since
you're
you're
actually
pretty
familiar
with
the
overall
architecture
here
as
well,
so
I
went
ahead
and
created
a
ticket
for
you
here,
stick
at
31.
A
A
This
is
a
little
bit
open-ended
right
now,
but
the
scope
of
this
is
so
one
of
the
first
things
to
pin
down
would
be
what
is
the
realistic
scope
in
the
in
the
next
weeks,
but
mostly
as
I
understand
it,
we
just
need
to
get
some
actionable
intelligence
for
for
the
correct
runtime
team
and
they
will
take
it
from
there.
A
So,
presumably
you
would
need
to
sync
with
with
ilia
and
and
at
least
at
least
bo,
maybe
nikolai
and
then
produce
some
kind
of
reproducible
benchmark
that
they
can.
They
can
iterate
on
to
improve
things.
A
Okay
and
then
the
other
other
big
thing
next
week
is
the
relayer
deployment,
so
I've
taken
over
control
of
the
of
the
aurora.dev
hostname
and
set
up
already
dns
entries
not
yet
to
be
announced
today,
but
on
monday
monday
we
will
roll
out
the
testnet
and
bit
on
it
endpoints
and
just
needs
a
little
bit
more
work
for
production,
readiness
on
the
on
the
layer
code
base
and
then
we're
gonna
roll.
Those
out
partners
are
asking
for
them.
A
So
yeah
we
got
the
servers,
load,
balancers
and
dns
ready
to
go
just
need
a
little
bit
more
work
on
the
code
and
we
have
documentation
updates
that
need
to
be
done
now.
One
one
thought
I
had
alex
is
that
maybe
maybe
we
ought
to
to
actually
pull
pull
out
the
aurora
specific
documentation
to
a
sub
domain
of
aurora
dev
instead
of
having
it
in
the
near
docks.
A
It's
a
bit
incongruous
there
with
the
yeah
yeah
with
our
engine
there,
all
of
a
sudden
so
from
there
we
could
just
link
to
our
own
dock
site
and
put
everything
there.
What
do
you
think.
A
So
I'll
I'll
get
this
stood
up
and
it'll
be
easier
and
quicker
to
update
the
dopestand
as
well,
okay
yeah,
so
the
the
main
asks
from
from
partners
right
now,
the
main
asphalt
partners
have
been
get
their
layers
going,
which
I
haven't
wanted
to
do
prematurely,
because
I
knew
there
were
issues
with
with
that
code,
but
next
week
we'll
have
them
get
the
documentation
updates
so
that
they
can.
They
can
start
understanding.
What's
going
on.
A
Frankly,
the
first
pass,
I'm
doing
a
second
pass,
and
I
said,
let's
pivot
the
documentation
to
its
own
site
and
the
third
one
is
for
some
partners.
It's
very
important
about
particular
rpc
operations,
on
which
the
either
are
not
fully
fully
implemented
in
the
same
way
as
death
would
be,
or
they
need
performance
improvements
so
I'll
to
get
those
out
as
well
in
the
next
week.
D
Just
a
short
question
on
the
continuous
integration:
do
we
have
like
a
standard?
We
use
there?
What
I
should
use
if
I
set
it
up
for
the
bully.
A
Yeah,
it's
all
it's
all
using
github
actions.
You
can
just
take
a
take.
A
look
at
you
have
a
go
code
base,
but
it's
pretty
much
the
same,
that
github
workflows
and
then
just
a
little
bit.
Yummle
configuration
okay.
D
A
Yeah
and
of
course,
I
recommend
that
in
all
our
projects,
I
know
this
might
seem
old-fashioned
for
some
of
you,
but
let's
have
a
make
file
and
that
makefile
will
will
build
the
project
as
in
if
somebody
needs
to
figure
out
how
to
build
the
project
just
type
make,
and
it's
going
to
build
the
project
and
it
can
have
other
other
useful
things
like
the
unit
test
can
be
run
easily.
A
That's
make
check
is
the
standard
target
for
that
not
not
make
test,
but
we
can
have
a
test
as
well,
and
you
know
code,
formatting
and
so
on.
So
you
can
just
take
an
example,
for
example,
from
the
the
autorange
in
repo.
It's
not
that
difficult
to
write
make
files.
The
only
thing
is:
there's
an
invisible
tab
here,
that's
the
only
difficulty
box
make
files.