Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Eclipse Che software factory


On Thu, Apr 30, 2020 at 7:03 PM Nick Boldt <nboldt@xxxxxxxxxx> wrote:
Moving to docker-based ts builds instead of docker-wraps-maven-based-builds-that-assemble-ts is for sure an improvement!

Going a step further... do we even need to publish the server artifacts to Maven Central? Or is the primary way of consuming Che server as a container image? @Mario Loriedo @Sergii Kabashniuk 

I think that it was said during the community call that the only project we are aware of that gets server artifacts from maven central is rh-che (hosted che). We need to address that if we want to avoid publishing artifacts to the maven central.
 
>   For example, we can have Github action that can build a docker image with the apache server and content of these repositories on each commit and each tag. 

Can we also use GH actions to do releases? If so, great! If not, do we really want to have ONE tech for CI and another for release builds? Will that be more overhead than using CentosCI cico scripts for both nightly/CI and for releases? Related: https://github.com/eclipse/che/issues/16817 @Sergii Kabashniuk @Florent Benoit 
 
For che-docs, my understanding is that:
a) there's little to no value including the docs INSIDE the server since that makes them outdated really fast and the CI process is already publishing them live to eclipse.org with every update to GH.
b) we have no real need to have old docs (eg., how did things work in Che 7.3 vs. 7.9 vs. 7.14?) since we have the sources in GH and people could (if they wanted) rebuild the docs from an older branch to see how things have changed. 

So for Che 7.13, I guess we could simply stop releasing a che-docs artifact into Maven Central? @Fabrice Flore-Thébault  ?

Re: parent pom and depmgmt, I see that we've already merged a change to move the depmgmt pom content into the root pom for the che server repo. 


The effect of this change is that any poms out there that refer to the depmgmt pom 7.13.0-SNAPSHOT are now broken and need to be updated... for example this one: https://github.com/eclipse/che-dashboard/blob/master/pom.xml#L19

But this is a good thing, since there's no need anymore for a pom based build of the dashboard! :D Related: https://github.com/eclipse/che/issues/16816 @Sergii Kabashniuk 

Thanks for looking into ways to make Che easier to build and consume! Sorry it took me a week to get around to replying. :) 

Any other input from the rest of the community?

Nick




PS: As an aside (because it's a product issue, not a project one) I've opened this jira around how we will consume the new dashboard and workspace images: https://issues.redhat.com/browse/CRW-865 -- please feel free to comment or point out my incorrect assumptions. :) 

On Fri, Apr 24, 2020 at 8:00 AM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
Hello.
I believe that most of you should agree that in the modern world
the speed of software development is constantly increasing.
That means not only faster features implementation but also
a faster way to deliver them. Things that were ok decades ago
 - several releases per year, can't satisfy customers and
developers need anymore. Now we are releasing 1-2 times
per iteration (3weeks). But I'm sure we can and should do it faster
 1-2 releases per day and such a speed should not surprise anybody.
I believe our ultimate goals should be release and deliver of each commit.
But that is probably long term goal, that we should aspire.

In this letter, I would like to concentrate on problems
and solutions that can help us to achieve the goal of several
releases per day. One of the bottlenecks
that I'm aware of is the maven releases complexity multiplied
by a number of mavenised projects. I think Nick and Mykhailo are
doing a tremendous job to automate that. However, due to
the nature of the maven and Maven Central, I think we are
very close to the physical limit and can't significantly decrease
the time of this process. That is why I would
like to propose an alternative that can help us
release faster.
 
I believe that the main source of improvement can
be in a fact that most of the mavenised projects
that we release now are don't have to be maven artifacts.
That is:
- che-docs
- che-dashboard
- che-loader
- new dashboard ???
Some of them may be released not that often like: che-parent.
 

I can see several possible alternatives for che-docs,che-dashboard,che-loader

- Github releases.
  Tags: Can be released as zip archives attached in Github releases.
        That archives can be reused during che server docker image build.
  Snapshots: To build che server with the master version of  che-docs,
        che-dashboard, che-loader we can build them all together
        and use relative paths like
        here https://github.com/eclipse/che/blob/master/dockerfiles/che/build.sh#L18
        for example   ${DIR}/../../che-dashboard/dist/
- Github Maven/NPM repository.
   I believe the synergy of integration with
   Github's actions + Github artifact repository can give a significant increase in release time.
   The only drawback I see that to consume these artifacts you have to provide  Github token all the time.

- Docker images.
  We can reuse quay.io and Docker images as the format of redistribution of che-docs,che-dashboard,che-loader.
  For example, we can have Github action that can build a docker image with the apache server and
content of these repositories on each commit and each tag. 
 Che server docker build can reuse these images as builder images.
 Later we can talk about reusing these images as individual servers as we have with che-plugin-registry or che-devfile-registry.
 Or these servers with static content can be combined with a single Apache-based container. 
These docker images can be also parameters of CR of che-operator.
 That can allow having Happy-path testing on multiple repository PR checks.
 
Personally I prefer a docker-image based approach.

With che-parent we can do several things
 - Move dependencies management from che-parent to che.
    Like https://github.com/quarkusio/quarkus/blob/master/bom/runtime/pom.xml
   That can allow us to not release che-parent that often.
 - We can replace che-parent with jboss-parent
   Like this: https://github.com/quarkusio/quarkus/blob/master/pom.xml#L5-L10
   With that, we can deprecate che-parent at all and have maven user experience
   from best in class maven engineers  https://github.com/jboss/jboss-parent-pom

wdyt?

--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat

skabashniuk@xxxxxxxxxx    

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev


--

Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: CodeReady Workspaces 

IM: @nickboldt / @nboldt / http://nick.divbyzero.com



“The Only Thing That Is Constant Is Change” - Heraclitus
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev

Back to the top