tcWebHooksPlugin 1.2.0-alpha.8

Eighth alpha release of 1.2.0 version

• Secure values support #53
  WebHook Project Parameters marked as "password" are now externalised into TeamCity's secure storage and are stored outside of VCS the project config is synchronised with VCS. See Hiding sensitive values

• New statistics chart showing webhook stastics over last 60 days
  See WebHooks tab on the Administration page
  Statistics are written to a statistic file, so that they are persisted across restarts.

• Added a new "Build Step" called "WebHook Service Message Sender" #179
  Add a build step to your build which triggers webhooks with the "Service Message Received" event enabled.
  Note: it's also possible to fire the "Service Message Received" event by printing ##teamcity[sendWebhook] to stdout during the build.

• Skip REST-API jar checking for recent TC versions
  Recent versions of TeamCity no longer include a jar that conflicts with the tcWebHooks REST API.
  This change no longer requires the check to run if the version of TeamCity 2021.0 or newer.

• Add ability to mark a property as "forced resolve" #26 #193
  Certain teamcity variables are not resolved until after the "changes loaded" event in the build lifecycle.
  Marking a WebHook Project Parameter as "forced resolve" asks TeamCity to resolve the variable earlier if it can.

• Improve WebHook variables
  Added $buildStatusSakuraUrl variable which points to the URL of the build in the new experimental UI.
  Updated $buildStatusUrl to use build External ID, rather than Internal ID. using the internal ID would sometimes redirect to main page in teamcity rather than the specific build (mainly when you had to login as part of the UI flow).

• Updated libraries

  • Guava, httpClient, Velocity Template Engine
  • Also the following only used for testing: junit, jetty

Full Changelog: v1.2.0-alpha.7...v1.2.0-alpha8

tcWebHooksPlugin 1.2.0-alpha.7

Seventh alpha release of 1.2.0 version

Add support for Project Parameters: #82

Project WebHooks Parameters provides a way to define parameters for a project and all subprojects.
Parameters can be used in templates or added to payloads on legacy payloads.

Don't hide build specific webhooks on project tab - UX improvement: #111

Previously webhooks assigned to just one build would not appear on the project webhook list.
This change shows all webhooks in a project, and indicates the number of builds configured.

Add support for variables in Authentication values: #106

Allows the values for Authenticator implementations to be resolved
from webhook variables. It uses the templating engine specified by the
template type.

Add support for NTLM Authentication: #33

Newer versions of Apache HTTP Client (the library used by tcWebHooks) support NTLM authentication.
Please test and give any feedback.

Copy the promotionId to the buildId for Queued Events #159

For queued builds, the buildId has not been set. However, a build's promotionId becomes the buildId once the build starts, so promotionId can be used as buildId instead of null.

WebHook History fixes: #161

• Add separate Atomic Integer counters for history event types. Previously they were calculated from the store items on page load.
• Prevent concurrency issues when updating the history store under heavy load.
• Update wording of history page to better indicate that the counters are separate from history store.
• On history page default to viewType "All" if no query string event type is present in URL.
• Support capital OK. The pagination of "OK" events was reverting to "All" events when using the paging links.

Add project audit events when WebHooks are edited: #164

Editing webhooks now shows with a comment in the project audit log. When using a project with VCS versioned settings the comments show up in the VCS commit log.

Updated Lombok and exclude it from build libraries: #165

Previously the Lombok library was bundled with the plugin. This is not required as Lombok is used only at compile time.
Reduced plugin size by about 1.5MB.

tcWebHooksPlugin 1.1.374.403

Bugfix release for the webhook history pages

The following items are addressed:

• Add separate Atomic Integer counters for history event types. Previously they were calculated from the store items on page load.
• Prevent concurrency issues when updating the history store under heavy load.
• Update wording of history page to better indicate that the counters are separate from history store.
• On history page default to viewType "All" if no query string event type is present in URL.
• Support capital OK. The pagination of "OK" events was reverting to "All" events when using the paging links.

Addresses issue #161

tcWebHooksPlugin 1.1.372.399

This release adds the ability to rollback from tcWebHooks version 1.2.0 to version 1.1.x.x.

The 1.2.0 alphas are quite stable, so anyone wanting to try the new features in 1.2.0, can be more confident that rolling back to this version will get back to a working 1.1.

tcWebHooksPlugin 1.2.0-alpha.6

Bugfix release - Sixth alpha release of 1.2.0 version

Testing a webhook from Edit dialog does not always use correct template. Issue #157

When testing an existing webhook by using the Preview and Test tab in the WebHook Edit dialog box, the template used for preview and test was the one configured for the webhook, regardless of which template was chosen in the edit dialog. This is now resolved and any template can be chosen for preview/test even without saving the webhook.

Viewing WebHooks in Project Configuration does not display webhooks if no template associated.

Since 1.2.0-alpha.5, support was added for templates associated with projects (rather than only being able to be editing by a system administrator).
However, if no templates were associated with a given project, the webhooks and templates tab would not load in that projects Configuration settings. It would fail trying to build a list of non-existent associated templates.

Add suppport for TeamCity 9.x #156

We still have some users on TeamCity 9, and this fixes a bug in the REST API which was preventing TC9 users from editing templates. This incompatibility was introduced in 1.2.0-alpha.3

tcWebHooksPlugin 1.2.0-alpha.5

The fifth alpha release of 1.2.0 version

This release reinstates support for TeamCity <= 2018.1.5.
Due to a configuration change, the REST plugin wouldn't load successfully. If you're running TeamCity 2018.2 or later, you can ignore this release :-)

Remove plugin hot-reloading as it not compatible with TC2018.1.5 and below

Fixes issue #154

Versions of TeamCity up to and including 2018.1.5 failed to load the plugin correctly if the allow-runtime-reload="true" option was enabled in the teamcity-plugin.xml file.

The teamcity-plugin.xml is validated against an XML schema, so older versions of TeamCity fail to validate and load the configuration.

tcWebHooksPlugin 1.2.0-alpha.4

The fourth alpha release of 1.2.0 version

This release fixes a few bugs, and adds some new features toward the tcWebHooks 1.2.x release milestone.
Note: No longer tested against TeamCity 9. Now compiled against TeamCity 10.0 libraries.

Adds support for associating WebHook templates with Projects

This allows a WebHook Template to be created and associated with a project rather then just _Root.
Now group admins can create templates for use with their own webhooks. Previously only System Admins could create/edit templates.
This addresses issue #131

Adds VelocityJsonTool which provides reading a JSON map into a Velocity Hash
Used like $jsonTool.jsonToMap($jsonString)) where $jsonString is a map formatted as JSON
For example...

## Define macro called "resolveSlackUid"
## If username not found in parameter slackMapping, then just return the username from the commit
#macro( resolveSlackUid $myUserName)
#set ($uidMap = $jsonTool.jsonToMap($slackMapping))
#if( $uidMap.get($myUserName) )<@$uidMap.get($myUserName)>#else<@$myUserName>#end
#end

Add links from webhooks search to webhooks history and vice versa

Allows linking from a webhook search result to the invocations of that
hook in the history page.

Also, allows finding the webhook config item from a history item.

Add change count variables to template UI.

Added the following new variables so that they can be selected when editing a template.

• "changeFileListCount"
• "maxChangeFileListSize"
• "maxChangeFileListCountExceeded"

The following patches from the 1.1.x.x branch were also applied.

Reduce logging noise from WebHook components #153

Some TeamCity pages had protected constructors - they have now been made public. This reduces complaints (WARN) in the teamcity-server.log from Spring when TeamCity starts up.

Lots of other noisy logging messages reduced from INFO to DEBUG.

Fixes issue #152 where template editing would fail if TeamCity was installed in a non-standard web-application context.

For example: If the Teamcity application is at http://teamcity-server:8111/teamcity/ rather than http://teamcity-server:8111/ (which is the default), then the REST API call to update the template was calculated incorrectly, and requests would fail with a 404 error.

Limit the number of files listed in a changeset files value to 100 or less (by default). #150 #149
When tcWebHooks processes the build object to create the payload for a webhook, it generates a changes object which contains an array of the changed files relevant to the build. This set of files can be expensive to generate and has a performance impact for large changesets. It also bloats the webhook payload.

For changesets containing more then 100 changed files across all changes contributing to a build, the files array is now null and is typically excluded from the payload. This value can be changed if that doesn't suit. Typical values would be:

• 100. The default count for files in a change.
• 1000. Larger file sets, but not unlimited.
• 0. Never show the files list.
• -1. Unlimited. This restores the old behaviour, and can be a performance issue.

For more information, or to control the values, see: https://github.com/tcplugins/tcWebHooks/wiki/Specifying-the-maximum-files-listed-in-a-change-set

tcWebHooksPlugin 1.1.362.398

Reduce logging noise from WebHook components Fixes #153

Some TeamCity pages had protected constructors - they have now been made public. This reduces complaints (WARN) in the teamcity-server.log from Spring when TeamCity starts up.

Lots of other noisy logging messages reduced from INFO to DEBUG.

tcWebHooksPlugin 1.1.357.397

Fixes issue #152 where template editing would fail if TeamCity was installed in a non-standard web-application context.

For example: If the Teamcity application is at http://teamcity-server:8111/teamcity/ rather than http://teamcity-server:8111/ (which is the default), then the REST API call to update the template was calculated incorrectly, and requests would fail with a 404 error.

tcWebHooksPlugin 1.1.355.396

This release fixes the following issues:

Incorrect status ("running") reported by webhook on a finished/finishing build. #138

• If the build status would have been "Running", the status will now be one of: "Started", "Changes Loaded", "Interrupted", "Almost Completed", "Finished", "Finished (Success)", "Finished (Failed)", "Finished (Fixed)", "Finished (Broken)", "Responsibility Changed"
• Build Statuses that say something like "Tests passed: 315", will not be changed to one of the above messages.
• Adds buildStatusDescription to payload

Limit the number of files listed in a changeset files value to 100 or less (by default). #150 #149
When tcWebHooks processes the build object to create the payload for a webhook, it generates a changes object which contains an array of the changed files relevant to the build. This set of files can be expensive to generate and has a performance impact for large changesets. It also bloats the webhook payload.

For changesets containing more then 100 changed files across all changes contributing to a build, the files array is now null and is typically excluded from the payload. This value can be changed if that doesn't suit. Typical values would be:

• 100. The default count for files in a change.
• 1000. Larger file sets, but not unlimited.
• 0. Never show the files list.
• -1. Unlimited. This restores the old behaviour, and can be a performance issue.

For more information, or to control the values, see: https://github.com/tcplugins/tcWebHooks/wiki/Specifying-the-maximum-files-listed-in-a-change-set