在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):kercheval/GradleCMPlugin开源软件地址(OpenSource Url):https://github.com/kercheval/GradleCMPlugin开源编程语言(OpenSource Language):Java 99.9%开源软件介绍(OpenSource Introduction):#Gradle Configuration Management Build Support Project SummaryThis project is a set of plugins intended to support standard configuration management practices that are not necessarily well supported in gradle. FAQs, Examples (cookbook) and Overview discussions can be found on the wiki at https://github.com/kercheval/GradleCMPlugin/wiki. The GradleCM Plugin is a simple plugin that applies all the plugins that are a part of this plugin package. The Build VCS Plugin supports interaction with your local revision control system. This plugin exposes methods to determine status, branch names and tags in your project. This plugin is used by many of the other plugins in this set of plugins. The Build Info Plugin supports creation of a build time info properties file which is a part of the build artifacts. The Build Version Plugin supports the tracking, update and tagging for version numbers in your project and artifacts. The Build Release Plugin supports the maintenance of a release branch and hooks into the publication tasks for gradle to ensure correct source merge and version tagging when doing a release artifact publication.
To use these plugins, add a buildscript section for the plugin dependency in your build gradle file. Note that the example below will take the most recent released plugin jar file available.
Note: In this documentation, I have attempted to give many examples that are useful and usually reasonable. I use the long form of display such as
rather than the shorter (and equally acceptable) form such as
This is for consistency and simplicity. You may choose one form or another depending on your preferences and needs. ##GradleCM Plugin After ensuring the plugin is in your script dependencies, add an apply line to your gradle build file.
This will cause all plugins from this plugin set to be applied in the gradle file and will result in default behaviors (suggested). All plugin variables are accessed as described in the plugin specific sections below. Note: If you apply the gradlecm plugin, you need not apply any of the following plugin as described in their quick summary sections. ##Build VCS Plugin ###Summary The buildvcs plugin supports build script and plugin integration to your version control system. This plugin has a task which is present purely to allow a simple introduction into the gradle namespace and to set a variable to determine the type of VCS in use for your environment. The ###Build VCS Quick Start After ensuring the plugin is in your script dependencies, add an apply line to your gradle build file.
The methods of the buildvcs plugin are immediately available for use and do not require the execution of the buildvcs task. ###Build VCS Variables This plugin supports the following variables:
###Build VCS Methods The buildvcs plugin exposes several useful methods that are available to your script. String buildvcs.getType() - This method returns the current VCS type. This is an alternate form if the variable referenced at buildvcs.type. boolean buildvcs.isClean() - This method returns true if the current workspace is clean. This means that there are no modified, delete or added files in the system (staged or not). This method allows the validation of the workspace prior to starting a process that would not be appropriate with changes present in the system (like release build uploads). This method will return true if the buildvcs.type value is set to 'none'. String buildvcs.getBranchName() - This method returns the current workspace branch name. This method is useful for validation or for use on variable and comment creation. This method will return a VCSException if the buildvcs.type value is set to 'none'. List buildvcs.getAllTags() - This method will return all tags in the VCS system. The list elements are of type org.kercheval.gradle.vcs.VCSTag. This method will return an empty list if the buildvcs.type value is set to 'none'. List buildvcs.getTags(String regex) - This method will return all tags that match a particular regular expression. This method is used to obtain branch and string specific tags for particular uses. The buildversion plugin uses this method to obtain tags based on the version patterns. This method will return an empty list if the buildvcs.type value is set to 'none'. VCSStatus buildvcs.getStatus() - This method returns an extended status for the current workspace. This method returns an object of type org.kercheval.gradle.vcs.VCSStatus which can be used to determine specific files that are modified, delete, changed and staged. The isClean() method uses this methods return object to report a clean state for the workspace. This method will return an empty status if the buildvcs.type value is set to 'none'. Properties buildvcs.getInfo() - This method returns a Properties
object that contains the VCS properties used by the ###Build VCS Examples Example 1 To disable the use of vcs by the gradlecm plugin set (used for standalone project without VCS or using a VCS which is not supported by this plugin).
Example 2 To explicitly set the type of VCS in use by this plugin and workspace.
Example 3 To use the branch name as a basis for part of the version string.
Example 4 To prevent an action based on if the current workspace is clean.
###Security Considerations Somewhat independent of this plugin is the topic of remote repository security. This description largely surrounds the specifics of using github, but the areas around SSH key usage are applicable to other VCS systems you may use. In very broad terms, the ability to access a remote repository is independent of this plugin and any remote access should be secured and tested independently. ####HTTPS vs SSH In github, the difference between HTTPS and SSH resides largely in the authentication method. The HTTPS method requires the specification of your login credentials for github but with SSH, you use an SSH key which give access to your github repositories. Note that the SSH key approach does not allow admin changes or access to your account, just the repositories. In general, SSH is also more secure and you should clone your remotes using the SSH URI available from github. ####Using Environment Variables Normally, this plugin will ask interactively if a username, password or passphrase is required. Since the intended target for this plugin is to enable automation and continuous integration, there is support to supply these values in the environment. Users of GIT: If you are using HTTPS, you can use the variables GIT_ORIGIN_PASSWORD and GIT_ORIGIN_USERNAME:
Each build server has its own method for setting environment variables. This approach is not recommended since it places github administration account credentials in the system in clear text. A better approach is to use SSH and a repository specific deploy key. If you have a passphrase on your SSH key, you can set the passphrase in the environment using GIT_ORIGIN_PASSWORD.
Since you are exposing the passphrase in cleartext in this instance anyway, you should also consider using a key without a passphrase for your build system deploy keys to avoid the need for these variables at all. ####SSH Keys To ensure you are using the correct SSH key, a key must be generated and installed in github. This is done by the current github clients automatically, but you can do it in a number of other ways (see https://help.github.com/articles/generating-ssh-keys). The main thing you must ensure when setting up your system is to add the github host to your /.ssh/config file (see http://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files for exhaustive details). Inside of the config file, add a section that looks similar to this
You may have multiple IdentityFile blocks if you have deploy keys that are repository specific (like the following)
Key generation is straight forward, but environment specific. On windows, I would recommend puttygen (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) and copy/paste from the application for the public deploy key and use the conversion menu to export the private key in standard form. Connect to your origin directly using ssh to ensure the vcs host is added to your known hosts file (this stores the host and allowed fingerprint key of the host). In git, you can just show the remote to validate this all works
##Build Info Plugin ###Summary The buildinfo plugin supports the creation of a file (in standard Java properties format) that shows environment and build information present at the time a build takes place. The primary information gathered includes:
In addition to the information above, the ###Build Info Quick Start After ensuring the plugin is in your script dependencies, add an apply line to your gradle build file.
This will cause a file called buildinfo.properties to be placed within your ${buildDir} directory and will automatically insert the buildinfo.properties file into the META-INF directory of all generated jar, war and ear files. ###Build Info Variables Most behaviors of this plugin are modifiable by setting custom
variables in your gradle build file in the
###Build Info Examples Example 1 To automatically add build info into a zip file in the directory 'testingdir' you can add the specific task to the task map (overriding the defaults). In this example we preserve the copy of buildinfo.properties into newly created jar files.
Example 2 To add the build info file into other files (such as a zip, sync or other locations), you can add your task to the buildinfo taskmap variable or just do a standard copy as follows. This is the approach you would take for tasks that are not derived somehow from a copy/archive task.
Example 3 To add some custom data to your build info file, add the custom info
map variable to the
Example 4 To prevent automatic injection into any tasks, assign an empty map to the taskmap.
Example 5 To customize the location and name of the build info file use the filedir and filename variables
Example 6 To prevent the current machine information from being placed in the output file.
Example 7 To support multi-project environments it is often simpler to disable the auto write support using the task map and instead use a closure to get all tasks of a particular type. This approach also has the advantage of not adding the buildinfo file into the inputs collection and thus jar/war/ear files will be updated with a new build info file only when a contributing source file is modified and not on every build.
###Lifecycle Considerations This plugin hooks task graph completion (which occurs right after the configuration phase of a gradle run). If the variable 'autowrite' is true, then the build info file is created and task hooking is completed to copy the info file into specified (or default) tasks. This timing has several specific implications.
As an alternative, you could place the buildinfo.properties file in a
location that is not cleaned by the default ###Information sources Git - This plugin uses the library JGit (http://www.eclipse.org/jgit/) to obtain git information. Among other things, this plugin logs the most recent commit information and the current status (showing modified/delete/added files). Development builds can utilize this information to determine change information for specific artifacts. Machine - Machine characteristics including username, machine name, IP address, java vm info and OS info are gathered. Jenkins - Several key Jenkins variables are stored to shows build id, url, machine and other important information. Hudson - Several key Hudson variables are stored to shows build id, url, machine and other important information. TeamCity - Several key TeamCity variables are stored to shows build id, data and other important information. Gradle - Source build file, location and description information is stored in the information file. Custom - Any information at all can be specified as a name/value property set in the gradle build file for important information in your environment. New information sources are simple to add in this plugin if you have an interest in contributing. ##Build Version Plugin ###Summary The buildversion plugin supports the automatic setting of build numbers based on VCS tag labeling. The plugin supports multiple branch versioning and can be used without tagging at all. Using the default behavior of the plugin, the gradle version object will be updated to reflect a single increment version update from the last tag recognized as a tag label. For example, if a tag was found with version 2.6, the gradle version would be updated to 2.7 (your builds are actually targeted at the next version release, not the last one). The increment behavior, build numbers and version format default behaviors can all be overriden using the task variables. There are two tasks defined in this plugin: ####buildversion This task will find the most recent (not the highest build number, but the most recently placed) version tag and will use that as the template for the build version. The tags used for comparison are filtered based on the validatePattern set in the configuration block (see the variable section). The gradle version update occurs at the point at which the task graph is completed. This is just after the evaluation phase of the build and just prior to actual task execution. Nearly any version scheme you may want to utilize is supported by this plugin. Some common version schemes shown in the examples are:
Extended patterns are supported to allow very flexible variations. ####buildversiontag This task will take the current version and write a tag using the current version format. If this task is used directly, then this tag is written to only the local repository for the vcs in use. In this case, if you wish these tags published in a central repository, you will need to push the tags to the origin repository explicitly (this would be 'git push origin --tags' for git users). The The tag and comment inserted into VCS will be output when the --info command line option is used on the gradle command line. ###Build Version Quick Start After ensuring the plugin is in your script dependencies, add an apply line to your gradle build file.
This will automatically cause the tag list to be parsed and the version object to be placed in project.version. The
or by setting the dependsOn property of another task to be run.
###Build Version Variables ####The The primary output of the The
####The By default the The
###Build Version Examples Example 1 To prevent the version from auto incrementing so that the version reflects the last tag value (rather than the 'next' version).
Example 2 To set a specific major version after the initial revision has been obtained from tags. Note the use of the doLast closure (should be used anytime you are explicitly setting a value when usetag is true). Note that this example could use the updateMajor() method to accomplish this as well. This example sets the major version but does not affect the minor version at all.
Example 3 To use a specific version number that is controlled only by gradle variables (this example will result in version 3.3). (Use autoincrement set to false to have the version match exactly).
Example 4 To use a 'classic' major.minor.build version scheme that is set via gradle variable usage.
Example 5 To create a version string that has only a major and minor version
Example 6 To create a branch specific version pattern
Example 7 To create a validation pattern and version pattern to create a branch specific version (useful for hotfix branches, parallel development, etc.) but will grab the most recent tag from any branch (named without numbers). Note that the regex can be arbitrarily complex so you can do any sort of tag filtering you want as long as it is consistent with the version pattern.
Example 8 To explicitly increment the version in a task through the project variable (note the << is the same as using a doFirst closure)
Example 9 To set a comment for the tag created by the
Example 10 To allow tags to be generated even when the workspace has uncommitted changes.
Example 11 To set a comment and increment the version prior to writing a version tag.
Example 12 To create a version based on the year, a minor version and the current build number (ie r2012.1.345)
Example 13 To create a version that generates SNAPSHOT unless the release branch is in use. This is an extremely convenient approach and highly recommended.
Example 14 To create a version based on build type (release does a full version, but dev mainline creates snapshot builds). In this example the major version is part of the configuration file as well. This has some similarities to the last example. In gradle.properties set the build type
You can set the buildtype on the command line to override the default for CI release builds (or manual release builds)
Within the gradle.build file set the pattern based on the build type so that you will get versions like 4.3-SNAPSHOT (assuming the last release version was 4.2), but when doing release builds you get the full blown 4.3-20111028.123456 revision numbers (including the maven style date default pattern). Notice the use of the doLast closure to init from the last release tag but to use the standard snapshot version string during the build. This makes for a very flexible environment with very simple configuration.
Example 15 To ensure that on every update to a repository (via the maven plugin) you get a valid tag in the current branch. This is done by adding a doFirst closure to the maven upload task. The tag is created whenever you are not doing a snapshot upload in this example.
###Lifecycle Considerations This plugin hooks task graph completion (which occurs right after the configuration phase of a gradle run). Note that the version variable will not be referencable as described in the variable section via the project until after this task has run. ##Build Release Plugin ###Summary The buildrelease plugin supports the consistent promotion and publication of release artifacts. This plugin maintains a knowledge of your mainline branch, release branch, remote origin repository and upload task and ensures that when artifacts are published a consisten merge occurs to the release branch, a version specific tag is created and that those changes are pushed to your remote repository prior to artifact upload. This plugin also supports these functions for those using repositories without remote origins (local only development). This plugin will interact with the local and remote repositories, but will not change the branch is use for the current workspace. Repository changes are limited to tag creation and repository synchronization only. This plugin is designed to optimize repository use for both
development and build/deploy. The default development mainline is
assumed to be the 'master' branch and the release branch is assumed to
be the branch named 'release'. These can be changed in the variables
defined for the There are three tasks defined in this plugin: ####buildreleaseinit This task initializes the build environment necessary to use the release plugin. This task is typically used explicitly only once for a project, but the variables defined by this task are used by the other release plugin components. At the completion of this task, the release and development branches will exist in the local and remote repositories. ####buildreleasemerge This task is responsible for ensuring that all changes from the remote origin are merged to the local repository and merging the changes from the development mainline into the release branch. This task will push the local repository updates and any tags generated to the remote origin repository. ####buildrelease This is simple build and release task that has no variables or custom behavior except that defined by the other release tasks. ###Build Release Quick Start After ensuring the plugin is in your script dependencies, add an apply line to your gradle build file.
This will ensure the upload task specified in the configuration
block for ###Build Release Variables ####The The primary purpose and result of the Running this task will synchronize the local and remote repository branch structure for the two branches in question. This allows for clones taking over the role of release delivery and simpler trasfer of the role of different repositories. At task startup, there are several possible initial conditions for each branch:
In all cases, the result is that both the release and mainline branches will exist on both the local and remote repositories and will relate to each other as local and origin. Note: If the local and remote branches are found to exist it is assumed that they are on related code lines. No validation is made by this task to ensure that the same named branches on the remote and origin are connected. If this system is being setup without a remote repository this plugin will operate in a local repository only mode (see the ignoreorigin variable description) The buildrelease plugin task behaviors can be modified by the following variables: Note: These variables are used by all of the buildrelease plugin tasks (except where noted).
全部评论
专题导读
上一篇:snowdream/spring-boot-gradle-template: a template for spring boot with gradle发布时间:2022-06-18下一篇:aalmiray/awesome-gradle-plugins: A curated list of Gradle plugins发布时间:2022-06-18热门推荐
热门话题
阅读排行榜
|
请发表评论