The idea I had was about modeling certain builds and things essentially only having the data from the
build.gradle file and not needing all of the “things” that the build will actually execute on. The way I was thinking of it was using Gradle as an API layer for extracting relevant information from a
An example would probably make more sense. One that I was thinking of was modeling the tasks that a user would want to be executed for a pull request.
(try to disregard the syntax)
tasks = [$.tasks.checkstyle, $.tasks,unitTest, $.tasks.buildDockerImage]
Imagine that this gets checked into an SCM system. A pull request is opened at a later time, and that event is sent to a downstream service. That service (think of like Travis CI or some other build system) wants to use the model from the
build.gradle to make decisions about how to do its execution.
// Ignore the snytax, and there could definitely be some issues with build.gradles that use apply from: path
ProjectConnection connection = GradleConnector.newConnector()
PullRequest pr = connection.model(PullRequest.class)
// do something with the PR data
The way I was thinking of it was the way Travis CI or Circle CI use YAML to represent a build matrix - I would like to be able to model that directly in the build script itself. I wouldn’t want all of the source code to be able to look into model (I think).
Does that make more sense in terms of what I might try to model and accomplish?