markusjura
commented
7 years ago Any thoughts on how to automate this? I'm thinking It's conceivable that we could make commits and even release conductr-cli without making changes to sbt-conductr and thus not triggering any of the CI jobs here
We have enabled daily build for sbt-conductr: https://travis-ci.org/typesafehub/sbt-conductr/settings
If within 24 hours no PR is submitted in sbt-conductr then this daily build cron job will run against the master branch.
I wonder if it makes sense to have another CI job setup that runs integration tests of all of our projects when any one of those projects changes? I know it would take a while to run but seems like any change to find bugs is worth it.
I generally think this is a good idea. I feel it is just a matter of priorities. Today morning I just wrote this to Chris (prod-suite slack channel):
Generally I like the idea of moving them to a private repo. This speeds up the sbt-conductr tests. We could use this private repo as our general prod-suite integration test project. We then can run nightly builds (on Jenkins) to validate the entire Production Suite and possibly also apps such as Lagom, Akka, Play running on ConductR
huntc
Reverting PR https://github.com/typesafehub/sbt-conductr/pull/227 because it actually makes sense to test the conductr-cli master branch. sbt-conductr heavily relies on the conductr-cli and we do not have integration tests in the conductr-cli project. So the sbt-conductr integration tests are also the integration tests of the conductr-cli.
Therefore it makes sense to use the latest commit of the master branch instead of the latest conductr-cli release.
This way, we will catch errors before releasing a new conductr-cli version.