You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 24, 2025. It is now read-only.
*_Development releases may be unstable or non-functional. The `*-thirdparty.zip` file is for informational purposes only and does not need to be downloaded._
The following sections provide information that may be useful for developers of this
104
-
parser plugin.
101
+
The following sections provide information that may be useful for developers of this utility.
105
102
106
103
### IDE's
107
104
@@ -127,37 +124,16 @@ the main project directory.
127
124
* Build: (plugin binary will be stored in `build/libs`)
128
125
* `./gradlew clean build`: Clean and build the project
129
126
* `./gradlew build`: Build the project without cleaning
130
-
* `./gradlew dist`: Build distribution zip
131
-
* Version management:
132
-
* `./gradlew printProjectVersion`: Print the current version
133
-
* `./gradlew startSnapshotBranch -PnextVersion=2.0`: Start a new snapshot branch for an upcoming `2.0` version
134
-
* `./gradlew releaseSnapshot`: Merge the changes from the current branch to the master branch, and create release tag
127
+
* `./gradlew dist distThirdParty`: Build distribution zip and third-party information bundle
135
128
*`./fortify-scan.sh`: Run a Fortify scan; requires Fortify SCA to be installed
136
129
137
-
Note that the version management tasks operate only on the local repository; you will need to manually
138
-
push any changes (including tags and branches) to the remote repository.
130
+
### Automated Builds
139
131
140
-
### Versioning
132
+
This project uses GitHub Actions workflows to perform automated builds for both development and production releases. All pushes to the main branch qualify for building a production release. Commits on the main branch should use [Conventional Commit Messages](https://www.conventionalcommits.org/en/v1.0.0/); it is recommended to also use conventional commit messages on any other branches.
141
133
142
-
The various version-related Gradle tasks assume the following versioning methodology:
134
+
User-facing commits (features or fixes) on the main branch will trigger the [release-please-action](https://github.com/google-github-actions/release-please-action) to automatically create a pull request for publishing a release version. This pull request contains an automatically generated CHANGELOG.md together with a version.txt based on the conventional commit messages on the main branch. Merging such a pull request will automatically publish the production binaries and Docker images to the locations described in the [Related Links](#related-links) section.
143
135
144
-
* The `master` branch is only used for creating tagged release versions
145
-
* A branch named `<version>-SNAPSHOT` contains the current snapshot state for the upcoming release
146
-
* Optionally, other branches can be used to develop individual features, perform bug fixes, ...
147
-
* However, note that the Gradle build may be unable to identify a correct version number for the project
148
-
* As such, only builds from tagged versions or from a `<version>-SNAPSHOT` branch should be published to a Maven repository
149
-
150
-
### CI/CD
151
-
152
-
Travis-CI builds are automatically triggered when there is any change in the project repository,
153
-
for example due to pushing changes, or creating tags or branches. If applicable, binaries and related
154
-
artifacts are automatically published to Bintray using the `bintrayUpload` task:
155
-
156
-
* Building a tagged version will result in corresponding release version artifacts to be published
157
-
* Building a branch named `<version>-SNAPSHOT` will result in corresponding beta version artifacts to be published
158
-
* No artifacts will be deployed for any other build, for example when Travis-CI builds the `master` branch
159
-
160
-
See the [Related Links](#related-links) section for the relevant Travis-CI and Bintray links.
136
+
Every push to a branch in the GitHub repository will also automatically trigger a development release to be built. By default, development releases are only published as build job artifacts. However, if a tag named `dev_<branch-name>` exists, then development releases are also published to the locations described in the [Related Links](#related-links) section. The `dev_<branch-name>` tag will be automatically updated to the commit that triggered the build.
161
137
162
138
163
139
## License
@@ -167,4 +143,5 @@ See [LICENSE.TXT](LICENSE.TXT)
0 commit comments