Closed matt-richardson closed 5 months ago
I suspect the same will happen when editing a webhook via the REST api (which is how it works on a project edit page)
I have a fix that looks like it works. I need to get the coverage up on this code, but will try to push later today or tomorrow.
BTW, I found another bug. Copying a project that contains webhooks with specific builds configured does not update those WebHooks with the new buildType ids in the new project.
So it looks like copying a project fires off the projectCreated
event. There is no "projectCopied" event that I can find.
If a project is new, then it won't have webhooks configured. However, if it has some configured AND any webhook specifically references a buildId
AND that buildId
does not correspond to a build in the newly created project, I can assume it was a copy, not a create.
Since I have the old buildId
, I can then find that old build, get the name, find one in the new project with the same name, and swap the buildId
in my webhook configs.
edit: Name might not be unique in a project, so using BuildTypeExternalId
and parsing it to match the new project (eg, .endsWith()
might be safer.
BTW, I found another bug. Copying a project that contains webhooks with specific builds configured does not update those WebHooks with the new buildType ids in the new project.
it's the gift that keeps on giving :wry-smile:
New commit pushed. It will build soon. No coverage improvements yet, but now has support for deleted builds.
Finally got a chance to do some testing on this...
On first try I got a 404 trying to edit the webhook, which I couldn't repro, which was annoying. I couldn't find anything in the logs though, double annoying.
I cleared out the logs (to get rid of the noise), then restarted the server, then tried again, noting down what I did as I went:
I think 14 is related to the 10 second delay (if that's still in there), but not sure what's the go with 16.
I reckon we're at "usable", but there's still some gremlins in there.
I found another event that might help.
projects.ProjectEventsNotifier - Attempting to publish event about projectExtId TcPlugins3. Cause projectPersisted
This might be useful to speed up the 10 second window (14). At this point, I don't know why (moved, created, etc).
With regards to 16, I have not written that part yet. The last couple of weeks have been crazy busy.
With regards to 16, I have not written that part yet. The last couple of weeks have been crazy busy.
I know that feeling all too well :) No rush, no stress - appreciate all the work you're putting in here.
I've pushed an update with the following changes:
projectPersisted
. From what I can tell, this fires after persist and reload.projectPersisted
triggers a refresh after just 1 second, instead of 10 seconds like before.The algorithm for remapping is fairly brittle. It assumes the following:
ProjectExternalId_BuildTypeId
ProjectExternalId
part, but not the BuildTypeId
In code, the unit test looks like this...
assertTrue(WebHookSettingsManagerImpl.fuzzyNameMatcher("Project1", "Project1_Build01", "Project02", "Project02_Build01"));
assertTrue(WebHookSettingsManagerImpl.fuzzyNameMatcher("project1", "Project1_Build01", "Project02", "Project02_Build01"));
assertTrue(WebHookSettingsManagerImpl.fuzzyNameMatcher("Project1", "Project1Build01", "Project02", "Project02Build01"));
I have done zero testing on the legacy Rest API. My main TeamCity VM is off at the moment. I have only tested on my developer workstation, which has a newer TeamCity installed.
The build has run.
oooh, it's build 500. Exciting.
I forgot to say that the logs look like this...
INFO - jetbrains.buildServer.SERVER - WebHookSettingsManagerImpl :: WebHook uniqueId selected as candidate for updating to avoid conflict with existing webhooks. projectId: 'project161', oldUniqueId: 'id_465810593', newUniqueId: 'id_987758698'
INFO - jetbrains.buildServer.SERVER - WebHookSettingsManagerImpl :: Remapping buildTypdIds for WebHook. projectId: 'project161', newUniqueId: 'id_987758698', oldIds: [bt164], newIds: [bt172]
Checking... This branch includes the fixes for #238 as well, yeah?
Checking... This branch includes the fixes for https://github.com/tcplugins/tcWebHooks/issues/238 as well, yeah?
Yes, it's supposed to, unless I have introduced a regression
Hi @matt-richardson
Just checking in to see if you have any questions on this. Or need any help testing it.
Sorry for the delay - finally found some time to test it out - cant fault it. Tried a bunch of combinations around copying projects and filtering / deleting specific build configs Nice one!
(The only thing I did notice was that if you set up 2 build configs, filter to 1 of them, then delete the one you have, it stays in the config. UI still all works though - just ignores it.)
Thank you so much for your time. I really appreciate it.
If you edit the webhook after the build is deleted, does it exclude that BT id when writing the webhook config? I suspect it does. As long as editing works, I'm not too concerned about the delete use case, just in case it is undeleted again.
If you edit the webhook after the build is deleted, does it exclude that BT id when writing the webhook config? I suspect it does.
Yep, it removes it from the config when you hit sav.
Also realised that before you hit edit, the UI shows the correct 0 builds
for "Enabled Builds":
Thank you so much for your time. I really appreciate it.
Hah! I'm doing the easy part. You're doing the hard work here.
Sounds good to me! I'll plan to release before the weekend. If it doesn't happen by then it will be June because.... life
Thank you so much for your time. I really appreciate it.
Hah! I'm doing the easy part. You're doing the hard work here.
It's just really motivating to have someone engaged and interested in the outcome of a piece of work. I appreciate that.
Expected Behavior
A webhook configured to point to deleted build config should be able to be loaded.
Current Behavior
We get an error
Steps to Reproduce (for bugs)
Project1
BuildConfigA
andBuildConfigB
Project1
, that only triggers onBuildConfigB
project-config.xml
shows that the id is stored in thebuild-types
BuildConfigB
/admin/admin.html?item=tcWebHooks
)n
WebHooks configured in this TeamCity Server" linkEdit project Webhooks
forProject1
edit
for the webhook created in step 3 -> get failure popupAn unexpected error occured. Please see your browser's javascript console.
Console log has:
with an stack trace of:
Your Environment