Limit shared TravisCI resource to 1 build per run

eclipse / steady

Analyses your Java applications for open-source dependencies with known vulnerabilities, using both static analysis and testing to determine code context and usage for greater accuracy. https://eclipse.github.io/steady/

Apache License 2.0

517 stars 123 forks source link

Limit shared TravisCI resource to 1 build per run #79

Closed greg-a-smith closed 5 years ago

greg-a-smith commented 5 years ago

Is your feature request related to a problem? Please describe. Because of the way TravisCI works with open source, the SAP org is limited to 5 concurrent jobs. This can prevent other repos from getting any resources for extended periods of time.

Describe the solution you'd like Would you be willing to look into changing the travis configuration so jobs run serially or limit the number of concurrent jobs, so that TravisCI resources can be distributed a bit more?

Describe alternatives you've considered There really aren't other options with TravisCI since the SAP org is open source.

Additional context When one or two repos take all 5 concurrent jobs, it really becomes a bottleneck for other repos.

See the (admittedly aged) tweet here:

https://twitter.com/travisci/status/424990533447327744

jbadan commented 5 years ago

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

bcullman commented 5 years ago

cross-posted issue to this repo as well:

https://github.com/SAP/cloud-commerce-spartacus-storefront/issues/868

Naramsim commented 5 years ago

@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)

Naramsim commented 5 years ago

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

https://github.com/SAP/vulnerability-assessment-tool/commit/37de409cec5d7e2ee1a886980decb3aceb3135f1

serenaponta commented 5 years ago

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.

jbadan commented 5 years ago

@Naramsim That seems like a fair compromise to me 👍

bd82 commented 5 years ago

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,