►
From YouTube: Che Community Meeting - August 30, 2021
Description
1. Che-docs publishing now content from release branch. The main branch can accept content for the next release.
(Publication still executed from the master branch, but using content from the release branch) #2022 - Fabrice (5 min)
2. SSH key creation from dashboard vs from Che Theia plugin - Sergii Kabashniuk (7min)
3.New and noteworthy section to the community meeting - Sun (5 min)
A
B
A
C
C
C
It's
that
now
we
have
shea
dogs,
end
user
guide,
etc.
If
you
want
to
produce
several
several
versions,
then
you
will
have
j
dogs
version
and
then
the
end
user
guide
or
if
we
do
that
we
have
to.
We
have
to
manage
all
the
relic
direction
from
the
previous
url
and
be
sure
we
don't
create
for
four
errors,
because
all
the
four
or
four
errors
are
managed
by
eclipse
server
and
we
we
don't
have
the
hands
on
it.
So
we
have
to
do
all
the
directions
correctly.
So
that's
my
only
little
concern
is.
B
C
D
C
C
B
B
C
Is
completely
hard
coded
and
arbitrary
hardcoded,
but
we
so
that's
some
that's
something
to
do,
but
we're
so
for
this
kind
of
change.
We
are
really
have
to
think
about
the
redirection
issue,
because
it's
a
it's
a
it's
it's
a
big
deal
because
we
don't
have
the
ants
on
the
hd
access
on
the
on
the
server.
So
we
cannot
put
a
hashtag
access
with
with
a
with
a
red
crackscroll.
It
doesn't
work
the
the
server
that
doesn't
allow
that.
B
C
Yeah,
because
that's
that's
not,
and
we
have,
we
have
the
bills
for
every
pull
request,
or
so
I
don't
know,
I
don't
know
if
it
would
be
helpful
for
yeah.
So
so
we
already
did
that
so
for
the
contributors,
we
already
have
the
the
the
build
in
the
pull
request,
and
I
don't
know
if,
for
the
users
it
makes
sense
to
see
the
next
version
the
next
build
correctly
but
yeah.
That's
a
good.
That's
a
good
request.
C
C
Yeah,
instead
of
investing,
we
have
to
enter
our
playbook.
We
have
one
for
development,
which
is
looking
at
the
at
the
current
branch
as
the
head,
where,
where
you
are
located
that
was
previously,
we
had
only
one
entire
playbook.
It
was
looking
at
head,
so
we
are,
we
had
only
one
development
playbook
and
we
used
it
for
publication.
C
C
C
C
B
I'm
not
exactly
so
it's
just
that.
I
don't
have
a
sort
of
a
good
experience
with
other
documentation
site
that
do
that
use
the
version
in
the
url
like
openshift,
for
example,
that
when
you
look
at
something
that
then
you
you
you
search
on
google
and
then
you
find
older
version
because
they
are
still
there.
The
old
links
with
the
old
versions,
so
yeah
and
yeah
and
code
ready
workspaces
as
well
so
on.
For
upstream.
C
C
You
know
the
dogs
that
are
generated
from
cod.
We
must
make
sure
that
this
dog
is
published
is
pushed
to
the
repository,
because
we
cannot
do
it
during
publication.
So
it's
it
must
be
in
the
code.
So
that's
that
was
also
the
big.
The
big
change
is
to
make
sure
that
when
we,
when
we
do
the
release,
we
we
changed
the
version
number
which
which
we
changed,
the
the
release
range
we
are,
we
are
searching
for
and
also
we
update
this
generated
dock
and
we
make
sure
it's
up
to
date
and
we
push
it.
C
A
E
E
That's
potentially
might
be
not
the
ideal
back
end
for
for
a
persistent
those
kind
of
data,
and
there
is
intention
to
deprecate
it
eventually
and
reason
for
that.
There
is
already
a
functionality
which
allows
to
mount
a
secret
as
a
file
and-
and
so
there
is
already
alternative
for
users
not
to
use
the
service.
We
store
in
a
database
but
use
the
kubernetes
secrets
to
store
the
ssh.
E
And
here
it
comes
to
the
more
ux
ui
question.
Whatever
we
would
like
to
keep
the
creating
ssh
keys
from
thea,
that
means
we
need
to
to
provide
necessary
permissions
to
a
workspace
service,
account
to
create
and
read
those
kinds
of
secrets
which
has
some,
I
don't
know,
might
be
difficulties
or
security
concerns
or
in
other
ways
to
put
that
responsibility
to
services
like
dashboards
which
and
give
him
each
a
necessary
permission
to
create
secrets
in
users.
Namespaces
any
that's
the
question
about
opinion.
B
B
C
E
E
For
instance,
it
can
be
useful
to
set
up
a
maven
setting,
xml
or
another
secret
which
can
be
consumed
by
another
tool.
And
that's
that's
the
problem
right
now.
There
is
a
plugin
in
thea
which
can
create
an
edit
a
secret,
but
it
has
a
predefined
name
and
we
can't
use
it
to
store
ssh
keys
or
marvin
credential
or
other
tools,
which
requires
some
some
sensitive
data.
B
E
E
A
Son
yeah,
my
opinion,
is
that
we
should
so
the
user
should
be
able
to
create
any
kind
of
files
and
store
it
as
a
secret
and
has
to
be
done
from
from
the
editor
like
when,
if
you
editing
a
settings
xml
file,
you
would
do
it
from
your
editor
right
and
same
thing.
If
you
want
to
generate
an
ssh
key,
you
would
do
it
from
either
from
the
command
line
or
from
the
editor.
So
I
don't
think
this
is
something
that
we
should
try
to
make
it
something
different
that
what
already
exists.
A
We
only
there's
already
some
tools
and
editors
that
can
generate
such
keys.
So
why
not
using
these
tools
and
then
what
the?
What
we
have
to
do
on
our
site
is
make
sure
that
it
is
stored
as
a
secret
and
having
the
right
user
interface
to
say.
Okay,
this
is
has
to
be
stored
as
a
secret
in
that
volume
on
the
mount
in
that
building.
A
E
Another
comment
that,
what's
how
powerful
we
would
like
to
see
the
the
service,
our
space
service
account,
which
can
read
secrets
so
that
will
be
allowed
to
list
all
the
secrets,
because
recently
I
think
igor
created
in
pr
to
allow
that.
But
eventually
there
was
a
discussion
to
not
allow
to
read
all
the
secrets.
A
F
I
have
a
comment
on
the
question.
The
comment
is
about
multiple
editors
and
everybody
us
having
to
re-implement
in
everyone
that
the
same
is
kind
of
true.
If
we
have
contexts
in
which
we
do
not
have
a
a
dashboard
right
thinking
of
factory
link
or
something
like
that
or
we
open
a
repository,
it
has
a
dev
file
in
it.
Where
you
don't
have
a
dashboard,
then
you
have
the
same
problem.
The
second
thing
is,
the
question
is:
why
would
the
the
dashboard
be
more
secure
inherently
than
the
editor?
G
F
What
I
mean
is
this:
you
have
a
browser
and
you
run
code
right
and
you
can
manipulate
that
code
any
kind
any
way
you
want
really
right
the
front
end.
So
if
you
actually
have
a
correct,
login,
etc,
you
can
you
can
on
the
other
side,
nobody
can
tell
it's
a
browser
it
might.
It
might
be
some
heck
of
a
thing
that
does
whatever
that
presents
to
be
a
browser,
but
it's
something
else.
You
could
open
the
debugger
and
change
variables,
etc.
F
F
F
E
Right,
I
can
do
a
summary
for
this
topic
with
the
main
thread
and
put
something
back
at
this
point.
I
have
two
ideas
that
the
juan
morris
is
just
to
change.
The
fitbit
backhand
from
database
to
to
kubernetes
and
stance
feedback
is
to
just
allow
flying
jt
plugins
to
draw
any
kind
of
secret
door,
edit
all
necessary
operation.
A
A
A
A
A
And
so
this
is
would
be
a
way
to
have
something
different
different
that
what
we
are
using,
what
we
are
doing
today.
So
today
we
are
just
talking
about
problems
and
topics
related
to
chad,
development,
and
that
would
be
something
which
would
be
more
about
sharing
the
new
thing
that
we
are
adding
to
che.
A
So
the
new
features
that
are
very
cool
and
that
that
you
want
to
show
to
anyone-
and
this
would
be
like
yes,
so
the
the
person
who
has
made
that
development
would
yes,
I
present
it,
and
this
is
really
optional
like.
If
you
don't
want
to
do
it,
you
don't
need.
But
if
you
want
to
show
that
you're
very
welcome
to
to
add
that
to
that
the
dutch
and
to
present
that
to
to
everyone
from
the
community,
how
does
it
sound.