[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [che-dev] Working towards Happy Path as PR check
|
Would it be possible to use GitLab's CI or GoCD?
https://about.gitlab.com/product/continuous-integration/https://www.gocd.org/Sent from ProtonMail mobile
-------- Original Message --------
On Jul 24, 2019, 1:45 AM, Mario < mario.loriedo@xxxxxxxxx> wrote:
Serhii and Gennady,
That's one more day without automated e2e tests.
And I don't feel safer.
Thanks Radim,
Yes, that's my impression as well - to launch the tests ASAP we need "publicly accessible" (that's why CRW is not an option) node/cluster.
However, I feel like using codenvycorp CI is too risky for that since it seems we have no one who is able to secure its workability if something goes wrong.
I'd see having dedicated infra on some public cloud (which can be reused for releasing in future when we shut codenvycorp down) as the best option for this.
If I'm not mistaken, codenvycorp CI is running on AWS EC3 instances as jenkins slaves. That's the only place where we were (so far) able to run the tests in somewhat stable manner.
Another obvious option is CRW jenkins (Used for CRW productization&testing). There we are facing lot of issues tied to nested virtualization and also often Openstack outages/problems. We are trying lot of possible workarounds/approaches to make it more reliable, but without any big success so far. On top of that, this CI is private (not ), so this is not very good for community project.
Eclipse CI? So far I didn't have time to investigate deeply (try running minikube/minishift there). What worries me there is possible shift to new infra (jobs running in containers - this does not allign with running mini(shift/kube) :-D) - This one definitely needs more investigation.
Last thing I was pretty hopeful was to run the tests against some public cloud infra (GKE, AKS, EKS, ..). To do that, somebody would have to pay for that (Mario sugested me to try with GKE, where there is 300$ trial period - but to do that, I have to provide credit card during registration and I'm not comfortable with putting there my personal card ;-))
According to what Serhii and Vitalii said it is highly NOT recommended to use
codenvycorp.ci for other than Che release tasks since it is not maintained for a long time.
So, if something goes wrong we may be in very bad position for GA release.
I might be wrong but are we sure it is a good time to add the risk and touch it just before long awaited GA release?
Are there no other options of infrastructure for (undoubtedly important) Happy Path testing?
Hi Radim,
Sorry, I don't think using current
ci.codenvycorp.com for anything production related is a good idea.
In general it has no any SLA and as solely (kind of support for it) person I simple have no knowledge of how important part of it works. So if something breaks on Codenvy CI it might take weeks for repair. Unfortunately person who did setup Codenvy CI left company and now Codenvy CI run as-is till something serious breaks, then it need to simple be shut down.
In particular for that job in question it had specific purpose like semi-manual run of series of job for comparing stability of it to central CI infrastructure. Because of this it was made in dirty and hackish way without any security, monitoring and backups in mind. It's nothing close to production grade.
Cloning of job is virtually impossible because job designed to be sole job on that slave. I doubt it can run with other job (even cloned) at the same slave.
I see that migration
codenvy.ci to central CI has no timeframe and and has enough manpower allocated to it.
From that I seeing it's very low priority effort.
Sorry, but adding new jobs to Codenvy CI isn't the option, even temporary (How temporary? Do you have due date and manpower for moving out of it? Which priority agreed for that move?).
If that job is critical for che7 and onward then it's even worse, please just don't use codenvy CI for anything critical.
Hi!
So far we have not been very successful on running Happy Path on internal CI (running on top of Openstack), but job we have on
ci.codenvycorp.com is looking rather good (last 30 runs succeeded withou failure), so we think we can move a step further and enable this as a (mandatory) PR check on che repository (followed up by che-theia repo).
Thanks!
For Che QE
Radim
--
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev