Skip to content

Gradle Plugin

The Obvyr Gradle plugin (com.obvyr.gradle) hooks directly into your test tasks and submits execution data to Obvyr automatically — no command wrapper needed.

Recommended for JVM/Gradle projects

The plugin is the preferred integration for any project already using Gradle. It requires no changes to how you run tests and never blocks your build.

Overview

  • Silent by default — no output unless something goes wrong
  • Non-blocking — submission failures are logged as warnings; your build is never affected
  • Graceful degradation — if the agent key is absent or the API is unreachable, the build continues normally
  • Zero wrapper — apply the plugin and run ./gradlew test as you always have

Source and issue tracker: github.com/obvyrcom/obvyr-gradle

Prerequisites

  • JVM 17 or later
  • The java or java-library plugin must be applied to the project

Installation

Add the plugin to your plugins block. No additional repositories are required — the plugin is published to the Gradle Plugin Portal.

Kotlin DSL (build.gradle.kts):

kotlin
plugins {
    id("com.obvyr.gradle") version "1.0.0"
}

Groovy DSL (build.gradle):

groovy
plugins {
    id 'com.obvyr.gradle' version '1.0.0'
}

The plugin activates automatically once the java (or java-library) plugin is also applied. It wraps every Test task in the project.

Quick Start

1. Get an Agent Token

Create a CLI agent in the Obvyr dashboard to obtain an authentication token. Tokens are scoped to a single agent.

2. Configure Your Token

Supply the token via an environment variable so it is never committed to source control:

bash
export OBVYR_API_KEY="agt_your_token_here"

3. Run Your Tests

bash
./gradlew test

Test results are submitted to Obvyr automatically at the end of every test task.

Configuration

All settings can be supplied via the DSL block, a corresponding environment variable, or a hardcoded default. Resolution order is DSL → environment variable → default.

For most projects, no DSL block is needed — configure the three environment-specific values via environment variables and let everything else use its default.

Recommended minimal setup (environment variables only):

bash
export OBVYR_API_KEY="agt_your_token_here"
export OBVYR_USER="local-dev"
export OBVYR_TAGS="local"

Full DSL example (build.gradle.kts):

kotlin
obvyr {
    agentKey        = "agt_your_token_here"   // required; no default
    user            = "local-dev"             // default: system user.name
    tags            = listOf("ci", "unit")    // default: empty
    timeout         = 10.0                    // seconds; default shown
    verifySsl       = true                    // default shown
    attachmentPaths = listOf("build/reports/coverage/coverage.xml")
    enabled         = true                    // default shown
}

Property Reference

PropertyTypeDefaultEnv varDescription
agentKeyStringOBVYR_API_KEYAuthentication token for the Obvyr API. Required — the plugin logs a warning and skips submission if absent.
userStringsystem user.nameOBVYR_USERExecution context identifier. Use a value that describes what is running the build, not who — e.g. local-dev, github-ci, jenkins-prod.
tagsList<String>[]OBVYR_TAGSLabels applied to every observation. Env var accepts a comma-separated list.
timeoutDouble10.0OBVYR_TIMEOUTHTTP call timeout in seconds.
verifySslBooleantrueOBVYR_VERIFY_SSLSet to false to disable TLS certificate verification (development only).
attachmentPathsList<String>[]OBVYR_ATTACHMENT_PATHSAdditional files to include in the archive. Supports glob patterns (*.xml, reports/**/*.json). Relative paths are resolved against the project directory. Only text-based file types are included. Env var accepts a comma-separated list.
enabledBooleantrueSet to false to disable the plugin without removing it.

user is context, not identity

Use OBVYR_USER to describe what is running the build — not who. Values like local-dev, github-ci, or jenkins-prod enable pattern analysis (local vs CI, developer vs automation) without collecting personal data.

CI Integration

GitHub Actions

yaml
- name: Run tests
  env:
    OBVYR_API_KEY: ${{ secrets.OBVYR_API_KEY }}
    OBVYR_USER: github-ci
    OBVYR_TAGS: ci,github-actions
  run: ./gradlew test

GitLab CI

yaml
test:
  script:
    - ./gradlew test
  variables:
    OBVYR_API_KEY: $OBVYR_API_KEY
    OBVYR_USER: gitlab-ci
    OBVYR_TAGS: ci

Jenkins Pipeline

groovy
environment {
    OBVYR_API_KEY = credentials('obvyr-agent-key')
    OBVYR_USER    = 'jenkins-ci'
    OBVYR_TAGS    = 'ci'
}

stages {
    stage('Test') {
        steps {
            sh './gradlew test'
        }
    }
}

Multi-Module Projects

The plugin applies to every Test task in every subproject. Configure it once at the root for a consistent baseline:

kotlin
// root build.gradle.kts
subprojects {
    apply(plugin = "com.obvyr.gradle")
    configure<com.obvyr.gradle.ObvyrExtension> {
        tags = listOf("ci")
    }
}

Or configure per subproject for different tag sets:

kotlin
// api/build.gradle.kts
obvyr {
    tags = listOf("api", "integration")
}

// core/build.gradle.kts
obvyr {
    tags = listOf("core", "unit")
}

Disabling for Local Builds

To enable the plugin only in CI environments:

kotlin
// build.gradle.kts
obvyr {
    enabled = System.getenv("CI") != null
}

Known Limitations

Gradle configuration cache: The plugin marks itself as incompatible with Gradle's configuration cache (notCompatibleWithConfigurationCache). This is expected behaviour in version 1.0 and does not affect correctness or build output.

Troubleshooting

No agent key configured

[Obvyr] No agent key configured. Set obvyr { agentKey = "..." } or OBVYR_API_KEY env var.

Set the agentKey property in the DSL block or export OBVYR_API_KEY as an environment variable before running Gradle.

Submission failed

[Obvyr] Submission failed. Check agent key and API URL.

Verify your agent key is valid and active in the Obvyr dashboard. Your build continues regardless.

Error submitting test data

[Obvyr] Error submitting test data: <message>

An unexpected exception occurred during submission. Check network connectivity. Your build is not affected — retry will happen on the next test run.