Skip to content

Latest commit

 

History

History
73 lines (55 loc) · 1.94 KB

usage.mdx

File metadata and controls

73 lines (55 loc) · 1.94 KB
title
Usage and tasks

Usage and tasks

Usage

Plugin configuration happens through the deployer extension. You act on it by adding one or more DeploySpecs and configuring them. Every spec can be configured independently and offers many options:

interface DeploySpec {
    val content: Content
    val auth: Auth
    val projectInfo: ProjectInfo
    val release: Release
    val signing: Signing
}

For example, to create a spec that deploys to GitHub and configure the version number, you may do:

deployer {
    githubSpec {
        release.version = "1.0.0"
        ...
    }
}

Please check out the artifacts and configuration docs to learn how to configure specs properly.

Default spec

In most cases, instead of configuring each spec separately, you will configure what we call the default spec. The default spec is the deployer extension itself, and acts as a root configuration provider.

Its values will be propagated to all child specs and used as fallbacks in case the child is not configured. For example:

deployer {
    release.version = "1.0.0" // our default
    ...

    nexusSpec {
        // release.version is 1.0.0
        ...
    }

    nexusSpec("snapshot") {
        // snapshot publishing. Override the default version
        release.version = "1.0.0-SNAPSHOT"
        ...
    }
}

Tasks

For each spec, the plugin will register a gradle task named deploy<SpecType><SpecName>. The spec type is either local, github, nexus or centralPortal. The name defaults to "" but can be configured. In addition, an extra task called deployAll will be generated, running all deployments at once. In the example above, the following tasks are generated:

  • deployNexus
  • deployNexusSnapshot
  • deployAll

Note: Use ./gradlew tasks --group='Deployment' to list all deploy tasks.

The plugin will also register the printProjectComponents task for debugging.