►
Description
‣ [TD] Enable Github Code Scanning? https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning (consumes Github Actions minutes)
• Easy to enable/disable - give it a try?
• Also have Code Climate
• More security focused
• https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security#about-advanced-security-features
‣ [EM] Naming progress
• Legal concerns for 2 of top 3 - Bifrost and Pharos
• Korifi is open
• Might need to check spelling
• https://www.exploring-greece.gr/en/show/41954/:ttd/PSILI-KORIFI-CHELMU for one example of Korifi
• We originally got the "korifi" spelling from https://www.sailingissues.com/yachting-guide/greek-chart-terms.html
‣ [JH] Merge vs. Rebase for PRs
• Put suggested flows in Slack to discuss then codify
• Best practice is to rebase your branch with main before pushing
• Question of whether to use merge commits or rebase merges to close PRs
• Cannot configure default option, but can disallow merge strategies
‣ [GC] Aggregated API spike update
Has impact on CF CLI
Has more pros than cons
Need to explore logging
B
Oh
yeah,
this
is
something
I
saw
in
this
like
a
pop-up
on
our
our
github
repo,
so
we're
already
using
the
pindabot
to
to
scan
for
cvs
and
our
dependencies
and
stuff.
But
this
is
a
new
thing
that
does
some
static
code
analysis
and
can
create
reports
and
issues.
I
was
wondering
if
folks
wanted
to
try
that
out
or
not
it
does
consume
github
minutes,
but
I
think
I
don't.
I
don't
know
what
our
limits
are
as
an
open
source
project,
but
I
have
a
feeling
we
have
plenty
of
them.
B
B
C
E
B
F
I'm
fine
to
try
it.
I
didn't
know
it
existed,
but
I
also
wanted
to
point
out
that
we
currently
have
code
climate
working,
so
we
can
also
take
looks
at
that.
I
think
I
really,
if
you
click
on
the
badges,
which
should
still
be
there
in
the
readme,
you
can
get
there
what
else,
and
also
these
linters
that
we're
using
yesterday,
I
was
going
through
some
chores
in
the
inbox
and
we
have.
F
B
B
A
A
G
Happy
did
you
want
to
talk
about
that
yeah,
the
it
was
mostly
like
yeah,
some
slack
messages,
but
it
looks
like
sophiaros
is
pretty
much
unusable
by
frost
as
well.
I
think
there
is
there's
companies
who
have
it
even
though
they're
not
in
the
cloud
native
space,
so
it
was,
it
was
like
we
could
like
potentially
go
for
that,
but
it
will
be
kind
of
risky
and
then
there
is
the
and
then
there
is
corifi,
which
is,
I
think,
our
second
choice,
which
is
apparently
wide
open
and
wide
open
means.
G
G
G
G
Yeah,
I
also
I'd
also
ask
them
ask
chris
to
in
general
like
give
us,
you
know
the
motivation
behind
what
the
red
flags
were
for
the
other
names
just
to
have
an
idea,
what
what
the
problems
were,
but
it
just
looks
a
lot
easier
to
go.
Just
go
to
just
go
with
qualify
just
or
creefy
just
because
it
seems
to
be
the
one,
the
easiest
one.
This
is
option.
E
Yeah,
I
think
what
did
he
say?
I
think
he
said
yeah.
It
was
for
the
other
two.
It
was
mostly
faro
seemed
to
have
a
pretty
credibly
direct
or
nearly
direct
collision
with
an
outstanding
product
or
project
and
with
by
frost.
There
were
just
enough
adjacent
things
in
this
space
that
it
like
it
might
be
possible,
but
there
would
be
more
risk
or
there'd
be
risk
that
you
know
we'd
apply
for
some
sort
of
trademark
and
it
wouldn't
go
through,
but
tarify
had
really
no
conflicts
at
all.
E
You
know
I
I
guess
from
my
perspective,
in
terms
of
like
moving
forward
with
something
that
we
think
is
going
to
work,
given
that
the
correct
spelling
would
be
with
the
greek
alphabet
anyway.
Maybe
we
don't
need
to
get
too
hung
up
on
the
transliteration,
especially
if
we're
looking
for
something
that
we
would
expect
to
have
the
highest
likelihood
of
being
pronounced
correctly.
E
G
When
I,
when
I
looked
around
for
the
right
spelling,
I
also
found
like
this
wordpress
hosting
company,
so
one
of
the
things
legal
was
saying
was
like.
If
you,
if
we
pick
up
the
wrong
spelling,
then
we
distance
more
from
from
them,
and
then
there
is
also
like
a
geographic
potential
problem
where,
like
there's
a
place
in
greece,
called
that
and
we
are
selling
something
that
is
not
from
there
and
there
could
be
like
issues
just
like.
I
don't
know
you
know
with
food.
G
E
G
A
A
G
A
G
A
E
A
G
A
H
H
Unless
there's
there's,
you
know
discrete
commits
that
have
discrete
meaning.
I
shouldn't
right.
We
shouldn't
like
merge
a
whole
bunch
of
commits,
but
there's
two
possible
flows
once
you've
done
that
you
can
either
do
a
rebase
or
you
can
do
a
merge.
The
merge
commit
leaves
makes
a
distinct
commit
that
has
a
record
of
who
merged
stuff
rebase.
Doesn't
we
seem
to
have
a
mix
of
people
doing
both
and
no
strong
opinions
about
what
the
best
thing
to
do
is,
I
feel
like
we
ought
to
be
consistent.
D
I
think
the
nicest
thing
for
the
history
is
to
rebase
first
manually
then
always
do
a
merge,
and
then
you
get
a
nice
linear
thing
and
you
can
see
the
group
of
commits
to
constitute
the
change,
but
then
with
the
slow
ci.
That
can
be
a
pain
because
once
it's
gone
through
and
then
somebody
else
beats
you
to
doing
a
merge,
then
you
have
to
rebase
again
before
you
emerge,
since
the
eye
has
to
go
green,
but.
G
D
G
F
G
F
G
Yeah
but
the
tests
yeah.
Of
course
the
tests
aren't
every
time.
Then
that
way
you
you
can
be
on
top
so
that
you
know,
there's
no
conflicts
or
anything
tests
are
green
and
then
you
can
still
merge
with
a
bubble,
because
if
you
rebase
and
merge
via
the
green
button
in
the
pr,
then
you
don't
get
the
bubble
or
if
you
do
it
from
you
know,
if
you
do
it
yourself
same,
you
don't
get
a
bubble.
G
Yeah,
it's
a
it's
more
complicated,
it's
less
complicated
than
it
sounds,
but
yeah.
That
seems
to
be.
If
we
want
to
have
like
best
of
both
worlds.
I
guess
like.
If
you
want
the
bubble
to
be
visible,
like
the
merge
commit,
then
we
should
always
merge,
but
also
keep
branches
up
to
date
by
rebasing,
either
manually
or
via
the
ui.
H
C
C
G
F
E
G
Yeah,
to
be
honest,
like
even
merging
without
the
rebasing
he's
even
more
faithful
to
what
actually
happened,
because,
like
the
whole
point
of
the
merge
commit,
is
also
to
contain
the
fixes
of
you
know
the
conflicts
that
emerged
because
of
the
diversion
right,
so
you
can
see
when
the
pr
was
spawned
like
from
where
it
was
spawned
and
then,
when
it
joined
back,
if
you
rebase
before
merging
you
get,
you
always
get
like
an
empty
bubble
like
the
which
is
kind
which
so
you're
still
altering
history.
It's
still
not
clear.
G
G
So
maybe,
if
we
do,
if
we
want
to
do
mergers,
maybe
we
should
just
do
plane
mergers
so
that,
but
the
history
becomes
kind
of
unwildly
because,
like
especially
if
people
start,
you
know
spawning
off
branches,
then
it
can
become
kind
of
chaotic,
but
that
chaos
is
what
really
happened
like
it's,
the
faithful
representation
of
what
happened.
If
you
do
a
straight
line,
it's
just
it's
not
really
not
what
you
what
happened
in
terms
of
like
reconstructing
what
happened.
D
H
H
H
H
F
G
H
A
A
A
G
Yeah,
so
we
we
experimented
with
mounting
our
api
as
an
aggregated
api
to
the
kubernetes
api,
so
which
is
this?
Basically
it's
this
way
of
extending
the
kubernetes
api,
with
whichever
endpoints
you
like,
which
is
really
nice
for
authentication,
because
basically
your
api
sits
behind
kubernetes
authentication.
You
don't
have
to
do
anything.
You
know
it
will
always
work
and
it's
secure
because.
G
F
C
F
G
C
C
But
then
you
have
the
yardback
rules
that
we
currently
have
for
workspaces
subs.
Whatever
customer
resources
we
have,
which
are
rules
on
those
resources,
and
they
have
nothing
to
do
with
the
permissions
to
access
date.
The
http
api
itself,
generally,
every
http
api
is
accessible
by
anyone,
no
matter
whether
authorized
or
authenticated
or
not.
G
G
G
G
C
G
G
G
So
if
you
want
to
go
that
in
that
direction,
you
know
once
we
decide
to
do
it,
there's
going
to
be
a
few
stories.
It's
not
a
lot
of
work,
but
it
has
impact
because,
like
it
kind
of
changes,
the
way
the
thing
works
substantially,
I
guess
so
like
the
network.
Now
we
try
to
expose
the
api
somehow
with
contour.
I
guess
we
would
have
to
stop
doing
that,
because
we
will
start
being
served
by
by
the
kubernetes
itself
and
stuff
like
that.
G
So
if
we
want
to
do
it,
there's
going
to
be
a
few
stories
to
work
on.
It's
still
unclear
to
me
whether,
like
I
think
it's
it
has
more
pros
than
cons,
but
it
feels
more
secure
than
what
we
have
now
and
even
just
from
like
from
an
optics
point
of
view.
It
just
looks
much
more
secure
because
there's
just
no
there's
no
need
to
explain.
Oh
we're
sending
keys,
but
it's
actually
fine
blah
blah
blah.
No
we're
doing,
and
it's
also
more
robust
in
terms
of
like
future
proofing
ourselves.
B
G
G
B
G
I
want
to
catch
all
those
like
doubts
that
we
have
about
this
solution
because,
like
one
is
large
uploads,
I
don't
know
if
you
managed
to
test
it
today
but
like
we
should
definitely
test
it
but
like
if
you
have
any
other
endpoints
that
we
should
test
to
see.
If
you
know,
for
example,
yeah
web
sockets
come
through
or
stuff
like
that,
we
can
do
as
part
of
this
spike.
Given
we
have,
we
haven't,
set
it
up.
B
B
G
Yeah
because
I'm
always
worried
that
we
were
like
yeah.
This
is
perfect,
let's
move
on
and
then
we
realize.
Oh,
we
just
can't
implement
this
endpoint
we're
screwed.
We
have
to
go
back,
you
know,
I
don't
know
if
there
is
any
systematic
way
of
catching
all
these
things.
I
guess
running
the
end-to-end
tests,
yeah.
B
G
B
A
Cool
well,
this
all
sounds
pretty
cool.
Hopefully
we
can
make
sure
that
it
will
work
for
us
and
then
sort
of
like
evaluate
the
options
as
to
mentioned,
we
need
to
look
at
logging.
So
we'll
start
looking
at
that,
but
yeah
sounds
promising
at
this
point.
We
are
out
of
topics.
We
have
a
little
bit
of
time
left.
If
someone
has
the
last
topic
to
add,
or
we
can
give
about
20
minutes
back
to
people,
and
we
can
start
looking
at
the
new
things.
We've
learned.