Discussion - Rules Model DSL: GradleConnector without access to entire project

Help/Discuss
1

I have been looking into the rule based DSL. I saw that the GradleConnector also exists as sort of a programmatic entrypoint for the tooling API. It looks like, from the API, that it requires a project directory and some local files.

At a high level, I was wondering if it is possible to get information from the model without having to need access to an entire “project”? Can I get information from the model without needing the rest of the project files? How does buildscript dependencies factor into this?

2

Could you elaborate on what you are trying to do? I don’t know what you mean by this:

3

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)

model {
    pullRequest {
        tasks = [$.tasks.checkstyle, $.tasks,unitTest, $.tasks.buildDockerImage]
    }
    tasks {
        ...
    }
}

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()
                   .forProject((InputStream) buildData))
                   .connect();

PullRequest pr = connection.model(PullRequest.class)
      .get();
// 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?

4

Just to make sure I understand you correctly:

  • The user puts these rules into his build.gradle to model his pull request workflow
  • Your service wants to get the model and execute tasks or do other things based on it

One question: Why would you not have access to the rest of the project? If you isolate the build.gradle file, this puts some restrictions on what the user can do. E.g. the build script could try to read other files in the repo during configuration time.

As long as it is self-contained, you can of course just put it in an empty directory and point the Tooling API there.

5

It’s not that I wouldn’t have access to the whole project. I was more trying to question the “do I need to have the whole project locally on disk in order to examine the build model?” I was trying to question the assumption that I need to do a git clone mybranch, or something along those lines, to bring the entire repository in to be able to ask questions of the model.

My initial thinking for the data flow would be:

  1. Commit event published by SCM
  2. Build system receives the event
  3. build system only needs to look at build.gradle in the refs/remotes/origin/HEAD (or some default branch)
  4. build system can either use git or some API to get contents of build.gradle (if the build.gradle pulled in other data during its configuration part, this would definitely be more complicated like you were saying)
  5. Throw the in-memory data to the GradleConnector
  6. Get a ProjectConnection
  7. Query the ProjectConnection for that PullRequest.class model (or whatever we are looking for)
  8. Execute logic now that you have model

After your response, it is starting to make me think that:

  1. There is no reason to not pull the entire repository. Getting the whole repository will probably not be that “expensive”
  2. If we isolate to only the build.gradle file, that restricts users for a non-useful and mostly arbitrary reason

It also looks the Tooling API is wrapper aware, so I think that gets me most of what I am looking for.

Thanks for your response.

6

Yes, it would definitely be the most natural thing for your users, because their build might only work with a certain Gradle version.

You’re welcome :slight_smile: