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
*_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
102
-
parser plugin.
99
+
The following sections provide information that may be useful for developers of this utility.
103
100
104
101
### IDE's
105
102
@@ -125,37 +122,16 @@ the main project directory.
125
122
* Build: (plugin binary will be stored in `build/libs`)
126
123
* `./gradlew clean build`: Clean and build the project
127
124
* `./gradlew build`: Build the project without cleaning
128
-
* `./gradlew dist`: Build distribution zip
129
-
* Version management:
130
-
* `./gradlew printProjectVersion`: Print the current version
131
-
* `./gradlew startSnapshotBranch -PnextVersion=2.0`: Start a new snapshot branch for an upcoming `2.0` version
132
-
* `./gradlew releaseSnapshot`: Merge the changes from the current branch to the master branch, and create release tag
125
+
* `./gradlew dist distThirdParty`: Build distribution zip and third-party information bundle
133
126
*`./fortify-scan.sh`: Run a Fortify scan; requires Fortify SCA to be installed
134
127
135
-
Note that the version management tasks operate only on the local repository; you will need to manually
136
-
push any changes (including tags and branches) to the remote repository.
128
+
### Automated Builds
137
129
138
-
### Versioning
130
+
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.
139
131
140
-
The various version-related Gradle tasks assume the following versioning methodology:
132
+
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.
141
133
142
-
* The `master` branch is only used for creating tagged release versions
143
-
* A branch named `<version>-SNAPSHOT` contains the current snapshot state for the upcoming release
144
-
* Optionally, other branches can be used to develop individual features, perform bug fixes, ...
145
-
* However, note that the Gradle build may be unable to identify a correct version number for the project
146
-
* As such, only builds from tagged versions or from a `<version>-SNAPSHOT` branch should be published to a Maven repository
147
-
148
-
### CI/CD
149
-
150
-
Travis-CI builds are automatically triggered when there is any change in the project repository,
151
-
for example due to pushing changes, or creating tags or branches. If applicable, binaries and related
152
-
artifacts are automatically published to Bintray using the `bintrayUpload` task:
153
-
154
-
* Building a tagged version will result in corresponding release version artifacts to be published
155
-
* Building a branch named `<version>-SNAPSHOT` will result in corresponding beta version artifacts to be published
156
-
* No artifacts will be deployed for any other build, for example when Travis-CI builds the `master` branch
157
-
158
-
See the [Related Links](#related-links) section for the relevant Travis-CI and Bintray links.
134
+
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.
159
135
160
136
161
137
## License
@@ -165,4 +141,5 @@ See [LICENSE.TXT](LICENSE.TXT)
0 commit comments