There's no point in having Travis build
krancour opened this issue · 5 comments
After #321 travis will be applying style checks and executing unit tests / code coverage.
But travis also currently does a make build and there's no good reason for that. It's probably a relic of a time when Travis had more responsibility than it does today. (Jenkins does more of the heavy lifting these days-- and that would include creating the binary and bundling that into a Docker image.)
Let's make our travis jobs a little fast by removing this unnecessary build.
cc @mboersma in case you see any obvious problem with this.
It's probably a relic of a time when Travis had more responsibility than it does today
I think that's true. Most other components still do this (redundant) make build in Travis, but it's not strictly necessary any more.
Indeed, this most likely applies to varying degrees for all other Workflow components as well.
To help inform a plan of action, I'll state that the default Jenkins job for a component only runs the bootstrap (if applicable), docker-build and docker-push commands.
Therefore, as it does not run the build target, we'd just need to be sure we aren't missing coverage of said target if it is removed from Travis.
Here is the meat and potatoes of said job logic: https://github.com/deis/jenkins-jobs/blob/master/jobs/component_jobs.groovy#L136-L143
@vdice docker-build always has build as a dependency, else the binary isn't available to be included in the Docker image. So Jenkins does do that already.
Ok. So I'll PR this once #321 is merged... just to avoid me having to remediate a merge conflict later.
This can be closed, as Workflow components, including this one, are no longer using Travis.