Generator-jhipster: 🚀 CICD: improvement

[pascalgrimaud]

Following my demo at JHipster Conf, I will improve the CICD sub generator.

Here the list of what will be done:

• you can only choose 1 pipeline instead of selecting all (if you want to add a new pipeline, simply relaunch the generator) -> it's easier to maintain.

• add Artifactory support (only for Maven for now)

• add Sonar support for GitLab CI and Travis CI -> now, it is very easy to push the Sonar analyze on SonarCloud

• remove GitLab stages, as it doesn't work well when choosing Sonar analyze -> it can be improved later and put it back

• change base Docker image from openjdk to jhipster/jhipster : we need libpng-dev for React and NodeJS for Sonar analyze, so it's better to use our own image which has everything

• remove the cache for node_modules inside Docker, because when you add new libs, you can have problem with permissions

• remove CircleCI V1 support, as it will not work after August 31, 2018, unless @jeantsai wants to help here for migrating to V2, as he did this module

[pascalgrimaud]

I'll try to support as much options / configuration as possible, but it will be hard to support all:

• Jenkins / GitLab CI / Travis CI
• Yarn / NPM
• Maven / Gradle
• perform inside Docker
• Artifactory
• Sonar
• Docker Push
• Heroku

[xetys]

Maybe a kubernetes deploy?

[pascalgrimaud]

It is not planned in this PR, but it can be done later if someone is motivated :)

[ghost]

suppose i am ... can i take the job ? :-)

[pascalgrimaud]

@rdfrancois : thanks but I should PR soon, so you can do the review and test if you want

[binakot]

It would be great to support the Docker Swarm deploy.
It's very similar to Docker Compose, but using different terms.
All you need is a slightly different way to write a yaml file and use docker stack command set.

[deepu105]

Wasn't focker swarm kind of abandoned in favor of kubernetes

On Sun, 8 Jul 2018, 11:12 am Ivan Muratov, [e-mail] wrote:

It would be great to support the Docker Swarm deploy.
It's very similar to Docker Compose, but using different terms.
All you need is a slightly different way to write a yaml file and use docker
stack command set.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/7904#issuecomment-403274044,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF0zzwf4i7XZdi72Sj_D3iOWjsuezks5uEc0MgaJpZM4U-Pja
.

[binakot]

@deepu105 Not quite. K8S is the most powerful and popular solution, but extremely difficult for small teams. My company is using Docker Swarm in production and it's very popular case for similar companies. With a staff of up to 25 people, where 3-5 developers do not make sense to use such a complex solution.

Docker does not currently have a plan to deprecate Docker Swarm

from https://github.com/docker/swarm.

[deepu105]

@binakot ok I did some research and you are right swarm is not dead but docker isn't doing much to keep it alive in terms of new features etc it seems. Anyway I think people like @PierreBesson @srinivasa-vasu @xetys and @pascalgrimaud are best to answer these

[binakot]

@deepu105 Yes, you are right. Swarm is not so popular and hype as K8S. It's developing slow and passive. In future it will be deprecated and forgotten. But it works and it's enough. Btw we got new release 1.2.9 one month ago.

[PierreBesson]

I am against supporting docker swarm. We already have so much to do to improve our kubernetes generator, I would much rather support only one docker orchestrator. The main problem is that it takes too long to test a full architecture manually and we still have no automated end 2 end test for kubernetes.

Personally, I have been really disappointed by docker swarm, especially the fallacy that the same docker-compose file can be used for dev and prod which was a completely bogus marketing claim. Also @bikanot you are saying yourself that swarm development is now maintenance only but this is happening less than 2 years after swarm mode was released.

It's true that kubernetes might seem more complex than swarm at first but orchestration is really hard and through my experience I realized that you really need an advanced abstraction like kubernetes to have success with it.
If you think kubernetes is too complex for your team then maybe you should use a PaaS to abstract away those concerns (and most teams should on fact do that).

[pascalgrimaud]

Same opinion as @PierreBesson about Docker Swarm
I'd prefer contributions to Kubernetes as we have very few people contributing on it.

About Docker Swarm, why not doing a module ? Have a look at https://www.jhipster.tech/modules/creating-a-module/
If your module becomes really popular, we can discuss about integrating to the main generator-jhipster.

Anyway, this ticket is for improving the CICD Sub Generator, with: Jenkins, GitLab CI and Travis CI support. Not adding a new Cloud Sub Generator :)

[magaton]

My vote goes to hashicorp nomad.
It is not complex, it does one thing and does it right.
Plays nicely with consul that jhipster already supports.
And the nicest thing is that it doesnt require docker. It can happily run
fat jars.

On 8 July 2018 at 17:57, Pierre Besson [e-mail] wrote:

I am against supporting docker swarm. We already have so much to do to
improve our kubernetes generator, I would much rather support only one
docker orchestrator. The main problem is that it takes too long to test a
full architecture manually and we still have no automated end 2 end test
for kubernetes.

Personally, I have been really disappointed by docker swarm, especially
the fallacy that the same docker-compose file can be used for dev and prod
which was a completely bogus marketing claim. Also @bikanot you are saying
yourself that swarm development is now maintenance only but this is
happening less than 2 years after swarm mode was released.

It's true that kubernetes might seem more complex than swarm at first but
orchestration is really hard and through my experience I realized that you
really need an advanced abstraction like kubernetes to have success with it.
If you think kubernetes is too complex for your team then maybe you should
use a PaaS to abstract away those concerns (and most teams should on fact
do that).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/7904#issuecomment-403297252,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD6b9S64xTBve-gCrrcwAQnFBUbiV5jPks5uEivSgaJpZM4U-Pja
.

[binakot]

Okey, guys, thanks for feedback. I couldn't disagree with you.
Btw I will think about to develop a module for Docker Swarm ☕️

[pascalgrimaud]

@binakot : cool ! don't hesitate to tweet and mention @java_hipster as soon as you release it

[PierreBesson]

@binakot @magaton +1 for a nomad and swarm module. If you want it can be hosted in our hipster-labs sub-organisation.

[jdubois]

I've also been very disappointed by the Docker marketing here, I trusted them and I feel they tricked me.
As far as I'm concerned Docker Swarm is dead, and I'd rather focus on upgrading our Docker Compose configuration files, as they use an older version.

[PierreBesson]

Oh and actually the docker-compose subgen still use the original hack of importing the app.yml files from each app and combining them in one 🤦‍♂️. This is not very good but it has worked for 2 years !

[jdubois]

Well, to me that hack looks a lot to what was announced at Dockercon: https://blog.docker.com/2018/06/design-applications-in-docker-desktop/ - maybe it would be worth to compare both
Anyway, this is very popular and we need to improve it, even if it already works great today.

[PierreBesson]

@jdubois Yes but we know how to do better ejs template imports. And really this "revolutionary feature" from docker looks underwhelming.

[pascalgrimaud]

I tested a lot of options. Everything seems to work fine, excepting the support for Gradle + Artifactory. I will probably submit a PR very soon, without this support, as I don't understand how to do it.

Maybe @atomfrede or @deepu105 you can help me later on this part? As you know well Gradle.