deploying new plugin is not possible
Vampire opened this issue · 18 comments
If you have a running TeamCity server where the plugin is not installed currently and then execute the deploy task, you get two times <response>Plugin not found</response> as output. I assume this is from disabling and enabling the plugin. While the message could maybe also be a bit more clear, the problem is, that the plugin is not active after this. I guess in case of this reponse you should have some retry logic that tries to activate the plugin once a second for a minute as long as this response comes or something like that so that the TC server has a chance to recognize the new plugin that should be enabled.
I've seen the issue you raised about reloading plugins not working with EAP2, until it works I don't really know the behaviour of disabling and enabling a plugin. However I would not expect to see two 'Plugin not found' responses, that I think is a problem with TeamCity, the deploy task copies the plugin to the plugin directory, and the following enable request should cause TeamCity to look in its plugin directory for the new plugin so it should not return a 'Plugin not found' response.
Also the code the Gradle plugin uses to disable and enable a plugin is borrowed from the TeamCity SDK Maven Plugin, currently it doesn't attempt any retires. So I'm reluctant to implement reties until after EAP3 is released.
Well, reloading works.
In the beginning I wasn't aware that your plugin needs to behave differently depending on target version.
But this is setup now correctly.
There is a log message wrong, but that can be ignored and there is one issue if you have a JSP page with an EL cache that will be solved in EAP3 coming this week.
But without a JSP or if it wasn't opened, reloading works fine.
Regarding the second not found response, I think the enable request does only work on plugins that are already recognized and the load request is probably too soon and the plugin was not found yet. That's why I suggested the retry logic. We can of course also suggest to Jetbrains that a load request for a non-existing plugin checks for newly available plugins before failing.
But still the message could be presented a bit nicer, e. g. with information for what action the answer came and presenting it as text, not as XML snippet.
I'm still unable to get reloading to work, I've got a simple example in the samples directory, reloadable-plugin, that registers as a listener writes a log message and has a shutdown hook to unregister and again write a log message, no JSP files. I've experimented changing the plugin archive name, removing the version, and changing the version in the descriptor. In the UI I either get the message 'Plugin was overwritten' or 'Plugin was deleted'. In both cases the log messages are written but it is always by the older code, so I'm wondering how you got it to work.
If JetBrains don't change how enabling works to check for new plugins, then yes a retry will be needed.
I'll improve the logging and remove the XML response, that was some of the code re-used from the Maven plugin :)
Maybe they have still issues you should report so they can fix them.
Try changing the agent side part of a plugin.
I'm not sure the reloading actually worked properly.
I judged from the log message "not fully unloaded" vs "successfully unloaded", I'm not fully sure whether the effect was correct though.
I also had cases where I reloaded the plugin, got a new version (I think), then reloaded again with more changes and got back the first version, but that could also have been improper observation by me.
Agent side reloading and modifying JSPs has always worked even with older versions of TeamCity it's only server side code that could be reloaded in older versions.
Ah, ok, then I'm not sure whether it worked.
Regarding the new plugin loading I opened https://youtrack.jetbrains.com/issue/TW-57931.
Btw. you know where you will copy the plugin to, so before issuing the disable request, you could also check whether the target file is available and if not then don't issue the disable request. This spares the sensless disable request and the error message will not be shown, or if you want to play super-safe in case the file is not there but it is loaded (dunno whether this would be possible) you could anyway do the disable request, but suppress the message if the file is not there as this was expected then and only display other errors.
The issue with new plugin should be fixed in EAP3 according to TW-57931, so this should work.
But maybe it would still make sense to not reload or to suppress the "not found" message when the plugin thinks that it is a new plugin.
I've updated the plugin to only send disable and enable requests when needed. I've tested it with EAP3, thanks for the hint on it being available, it mostly works but there is some odd behaviour with multiple re-deploys, mostly with TeamCity's UI.
You should report it then, so they can fix it before the final release :-)
The problems are reported, https://youtrack.jetbrains.com/issue/TW-57996
Good, I voted for it too. :-)
I've tried the plugin with 2018.2 RC and it appears to work well, do you agree, can this issue be closed?
If it works, I agree. I didn't test with the RC yet though.
I just tested and it seems to not work properly: :deployToTeamcity: Enabling plugin 'teamcity-ssh-tunnel.zip' failed: Plugin not found
The plugin was already present, just updated.
It is now marked as Not loaded (plugin overwrites existing plugin)
Also if the version changes the deploy does not work properly, it tries to disable my-plugin-0.1.zip and fails, then copies my-plugin-0.2.zip besides the other.
The UI then says that there is an updated version and suggests to reload.
And in the data dir both versions are present, I don't know whether this may be a problem when TC is restarted.
Actually now I increased the version and it didn't give an error on unload, but it is not loaded, but the UI says there is a new version.
I had only tested this using the reloadable-plugin example that has a version of 1.0-SNAPSHOT, changing the version to 1.0 and deploying works, changing the version to 1.0.1 is reported by TeamCity as successfull but the UI shows the plugin needing to be Reloaded. Changing the plugin archive name to not include the version works without the UI showing the reload option. This appears to be due to TeamCity's API using the filename when possibly the name in the descriptor should be used for unload and load requests.
Give me the issue URL if you reported, then I'll vote again. :-)
Just raised this issue https://youtrack.jetbrains.com/issue/TW-58204