Limit shared TravisCI resource to 1 build per run about steady HOT 7 CLOSED

@Naramsim That seems like a fair compromise to me 👍

from steady.

Builds should be optimized in terms of resources as well as actual E2E time.
But you may be rushing to fix a problem that may not exist.

• Why assume travis is the only provider of build containers?
  -This SAP OSS project uses circle-ci: https://github.com/SAP/webide-client-tools for example.
  • Azure Pipelines seem to provide 10 parallel builds for OSS projects.
• Why assume that the number of travis parallel builds cannot be increased?
  • If there is a real need, it should be reported and handled by the github admin team...
• Why assume that it is always better to wait longer (sequential builds) instead of sometimes waiting longer (due to resource starvation)?
• And what happens when the number of active SAP OSS projects increases? this reduction of parallel builds is just a temporary measure...

Cheers.
Shahar,

from steady.

Updated confirmation of 5 jobs tweet: https://twitter.com/mobot11/status/1083783900319559682

from steady.

cross-posted issue to this repo as well:

SAP/spartacus#868

from steady.

@copernico @serenaponta What do you think if we get rid of 2 Travis jobs? We can drop the oracleJDK tests and the Docker without tests.

@greg-a-smith @jbadan @bcullman would it be good if we reduce our jobs from 5 to 3 but still run them parallelly? (Consider that one of these jobs takes only 1 minute)

from steady.

@serenaponta, in my opinion, we should disable the job docker without tests and not the one that does the tests.

37de409

from steady.

I commented out 2 out of the 5 jobs just as temporary solution to be able to push/merge. More in general, we could decide to go for the sequential execution and run outside of travis the long running jobs like docker with test, that's the reason why i currently commented it out.

from steady.