request: would it be feasible to run regoTest opa in docker ?

[tgeens]

Prerequisites: OPA installed on same machine as the tasks are run, either on $PATH or pointed out by the location configuration attribute (see Configuration below).

Would it make sense to run opa in a docker container instead ? Especially for build servers that would be very useful.
Yes, that would swap the requirement for opa with a requirement for docker, but that is pretty prevalent nowadays.

[lukasz-kaminski]

Hi! Thanks for the idea. Initially, we were planning to create a task that would download OPA into hidden dir (think .opa), like gradlew does. What do you think @tgeens?
Also, summoning @anderseknert @irodzik @lkadalski @radrys.

[anderseknert]

Like both the ideas, and I don't see them as mutually exclusive either. A configuration property to declare the runtime (native vs. docker) defaulting to native, and and option to automatically download the opa binary should it not be found on $PATH (or wherever the conf is pointing). This is especially nice in environments like github actions where you'd otherwise need a task just to download OPA before running your Gradle tasks.

[vierbergenlars]

Just poking my head in because @tgeens raised this to me:
The gradle-node-plugin has an automated download strategy that I think integrates quite nicely. You might be able to reuse some of the code from there.

[lkadalski]

Nice idea @vierbergenlars.
I think about configuration based on two fields:
executable: BIN or DOCKER.
version: "0.27.X" or " "openpolicyagent/opa:0.27.1"
If there is no bin/docker locally then you fetch it. Either by docker pull or binary to "path_to_opa"(or any other property).
Is that make sense to you @tgeens? Would you like to implement such functionality?
What others think ? @irodzik @radrys @SuchSkill ?

[tgeens]

Right now I'm downloading OPA from github releases using a custom ivy repository (a bit of a hack)
This has the advantage of using the gradle dependency & build caches!

plugins {
    id 'com.bisnode.opa' version '0.3.0'
    id 'com.google.osdetector' version '1.7.0'
}

ext {
    opaVersion = '0.27.1'
}

repositories {
    ivy {
        name = "github.com"
        url = uri("https://github.com")
        content { includeGroup("open-policy-agent") }
        patternLayout { artifact("/[organisation]/[module]/releases/download/v[revision]/[module]_[classifier]_[type]") }
        metadataSources { artifact() }
    }
}

configurations {
    opaBinary
}

dependencies {
    opaBinary "open-policy-agent:opa:${opaVersion}:${osdetector.os}@amd64"
}

task downloadOpa(type: Sync) {
    from configurations.opaBinary
    into 'build/.opa/'
    fileMode 0744
}

opa {
    location    = "${projectDir}/build/.opa/opa-${opaVersion}-${osdetector.os}.amd64"
    srcDir      = "${projectDir}/src/main/rego"  
    testDir     = "${projectDir}/src/test/rego"
}

testRego.dependsOn downloadOpa

What do you think about that approach ?

(Tangentially, I think there is something wrong with relative paths inside the opa { } closure when using opa-gradle-plugin in a sub-project ?)

[irodzik]

IMO, as @anderseknert said we should have possibilities to run both native and docker. Configuration proposed by @lkadalski looks pretty straightforward.
@tgeens Really cool workaround which works and has many nice out of the box perks! However I don't think we should base on workarounds/hacks in this plugin :)

[lkadalski]

This request is ok. Will you prepare PR @tgeens ?
From my perspective it should work as it is now. So defaults should point current properties(like binary on $PATH, repositories etc.).
Rest is up to you and we are looking to see some proposed implementation.

[tgeens]

Don't have time right now, might come back later. I will ping on this ticket when/if I start working on this.

[nvervelle]

I opened a PR #94 with a first version that gives the plugin the ability to download OPA executable, it's almost complete I think...