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

tcWebHooksPlugin 1.2.0-alpha.3

The third 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.

This version contains an implementation of a Centralised Webhook Management service and is a housekeeping change which is mostly not visible to users. It allows future simplification of webhook management.
It provides:

• A preliminary search tool. See /webhooks/search.html. I would have liked to hook into the TeamCity search page, but it's not extensible.
• More efficient access to webhooks rather then iterating over each project in case it has webhooks configured.
• Searching across all webhooks rather than dealing with webhooks in a project context.
• A single (java) interface for CRUDing and managing webhooks.
• WebHooks Admin tab now has a link to view all webhooks across all projects because it's now efficient to find them.
• Ability to prevent a template from being deleted if it is in use #113
• Hides teamcity's ProjectSettingsManager and will ease transition to SProjectFeatureDescriptor
• Auto tagging of webhooks based on meta data. Click on the tag in a webhook search result to see other webhooks tagged the same.
• Find all webhooks which might trigger on this build (experimental, try /webhooks/search.html?buildTypeId=<buildTypeId>), even in parent projects.
• Allows for future capability like:
  * Copy webhook from project A to project B
  * Import/Export WebHooks
  * Add/Move webhooks when build moves/copied to new project
  * Edit any webhook from search results, rather than from within a project context.

Other Issues resolved

Add SBuild, SBuildType and SProject to Velocity template payload.
Addresses issue #31, #145 and #118

Update old dependencies

• Now builds against TeamCity 10.0 and springframework 4.3.17.RELEASE.
• Updated httpclient, guava, commons-lang3,

Remove reference to payload format from plugin-settings.xml
Fixes issue #134 The reason for this change is because we now have a number of template
formats (jsonTemplate, jsonVelocityTemplate, xmlTemplate, xmlVelocityTemplate, etc), and templates should be able to change format - and templating engine - without having to update all the webhooks which reference that template.

Set buildResult to "interrupted" for build state "INTERRUPTED".
Addresses issue #56, where result was still "running" after build was interrupted.

Add mocked data for responsibility events
Fixes issue #48. This presented when using the webhook test and template test features to send test webhooks for responsibility events. Now the data is mocked so that the events have something to send in the webhook payload.