Project versioned settings log constant comment "no comments"

[ghost]

Expected Behavior

Git log of TeamCity project configuration versioned settings has clarifications of what was changed.

Current Behavior

Any changes of configuration of TeamCity webhooks are logged as "no comments" (compare to messages below on changes of other TeamCity areas):

Steps to Reproduce (for bugs)

1. Go to Administration -> Root Project -> Versioned Settings ( http://1.2.3.4:8111/admin/editProject.html?projectId=_Root&tab=versionedSettings )
2. Enable synchronization with remote git repo
   
3. make changes in WebHook configuration
4. open git log of the TeamCity changes and compare webhooks-related changes vs other changes

Your Environment

• tcWebHooks Version: 1.1.362.398
• TeamCity Version: 2020.1.3
• TeamCity server Operating System: ubuntu
• Are you using a WebHook Template?: not applicable

Example Configuration (xml)

[netwolfuk]

Hi @schernov-xo. I'll have a look too see if there is a way I can pass a comment when I persist the hook. That code predates any of the settings stuff. I'm using the method of storing settings which is compatible with TC9 and below.

I'll take a later in the week when I'm back from vacation. No internet here and not computer! 😁

[netwolfuk]

Hi @schernov-xo I had a look a the code, and I can't see how the comment could be set using the plugin-settings.xml storage method. I have asked a question here: https://youtrack.jetbrains.com/issue/TW-67532, however I don't know if it's going to be possible.

[netwolfuk]

Anton from Jetbrains has replied and shown me how to do this. I'm embarrassed to say I was looking at the wrong code, but he found it.

I'll refactor that code this week and get it out as part of 1.2.0 alpha7. I see you're using 1.1, so I'll back port it and do a 1.1 release as well. Hopefully this week or over the weekend.

Thanks for raising this issue. I'm happy to make tcWebHooks better!

[ghost]

Perfect, thanks!

[netwolfuk]

Hi @schernov-xo

I have the comments now working. I've not setup a synchronised project yet, but I can see comments appearing in the project audit log. Do you think the comments are right? Should I have more description?

This is on 1.2.0 alpha7 which will be released this weekend. I'll check the code on 1.1.x.x and see how different it is.

[netwolfuk]

Looking at the 1.1 code, the infrastructure to shift the logic to does not exist. I'll hack it in, considering 1.1 will be old in a few months when 1.2 is finished.

[ghost]

Thanks. Will check it this weekend

[ghost]

The issue is still here. I've built the plugin from the latest master (eb7bafd1) via mvn clean install -DskipTests.

Setting changed: add trigger event

The commit message is the same

[netwolfuk]

Eeek. I haven't pushed. Sorry. Had a sick kid all weekend.

[netwolfuk]

Now pushed to this branch: https://github.com/tcplugins/tcWebHooks/compare/issue_164-add_commit_comment_on_edit

[netwolfuk]

I have some further tidy up to do in the controller, but this works, and you can test that the messages you get are useful.

Btw. Master is the 1.2.0 branch, so you're now running 1.2.0 alpha 7.

[ghost]

Now comments are fine. Only one thing - the new version of the plugin does not support legacy configuration format (migration), the webhooks should be recreated:

Not a big deal for me, but in some cases it may be a problem.

P.S. thanks!!

[netwolfuk]

Oh! They definitely should be being migrated. I wonder why that happened. Could you share an old copy of your plugin-settings.xml file (with the URL or anything else sensitive removed)?

[ghost]

Sure. Note: it's not a Root project, it's a project with parent=root

<?xml version="1.0" encoding="UTF-8"?>
<settings>
  <webhooks enabled="true">
    <webhook url="https://rest-api-team-XYZ" enabled="true" format="json" template="none">
      <states>
        <state type="buildFixed" enabled="false" />
        <state type="changesLoaded" enabled="false" />
        <state type="responsibilityChanged" enabled="false" />
        <state type="buildFinished" enabled="true" />
        <state type="buildStarted" enabled="true" />
        <state type="buildFailed" enabled="true" />
        <state type="beforeBuildFinish" enabled="false" />
        <state type="buildSuccessful" enabled="true" />
        <state type="buildBroken" enabled="false" />
        <state type="buildInterrupted" enabled="true" />
      </states>
      <build-types enabled-for-all="false" enabled-for-subprojects="false">
        <build-type id="bt23" />
      </build-types>
    </webhook>
  </webhooks>
</settings>

[netwolfuk]

Since you're saving all your changes into git, do you have a version of the plugin settings with the webhooks removed after the upgrade?

I'm trying to figure out if they were migrated and then removed, or migrated and then disappeared on edit. Or maybe some other event occurred and code did not handle the event correctly.

You should be able to tell when the file was migrated. It will have added the queue event configuration, and removed the payload format XML attribute.

[netwolfuk]

Thanks for the XML file. It's a legacy JSON webhook. I'm sure all that code is unit tested. I wonder if it's a combination of the migration and the settings in git. Time for be to setup that git stuff. Sorry about all this.

[ghost]

Welcome. Glad to help.

[netwolfuk]

Interesting: Your screenshot of the XML changes show that the webhook was migrated. I can see events for queued, etc.
It looks like you were able edit the webhook then. Was it only after the tcWebhooks version from the issue-164 branch was installed that the webhook disappeared?

[netwolfuk]

Created bug #167

[ghost]

The problem here to clarify what happened is there was an intermediate version (latest master).
But when latest master was installed, the old hook was on it's place.
Then I installed from the bugfix branch and webhook disappeared.

[netwolfuk]

Thanks for the clarification. I'm also running the latest branch for this issue, and previously was running a build off the branch that is now master. Except I have been running 1.2 for about 6 months, so it could be an issue with the upgrade.

My hunch is that it's related to the settings in git. I'll need to set that up and test it, but that could be a day or two away.

[netwolfuk]

Because there is nothing I can do at this time to solve #167, I'll merge this branch in and get alpha 7 released this weekend.