OpenAPI interface to analyze errors from updating sources

Answered

Hello,

We are occasionally faced with this error during Perforce sync:

[Updating sources] Failed to perform checkout on agent: Perforce client error:
    Connect to server failed; check $P4PORT.
    TCP connect to our.perfore.alias:1666 failed.
    No such host is known. - while running 'p4 -c TC_p4_HVBUILD53_pr2_9b562815a43ad61f -u builduser -p our.perfore.alias:1666 -H HVBUILD53 info'
[15:12:28][Updating sources] Error message is logged

I would like to write a plugin that captures the error message, parses for certain errors, does something in response to fix the problem and retries updating sources. Is there an existing interface for this in Java OpenAPI? We are on TC 2017.1.1.

Thanks,

Oleg.

7 comments
Comment actions Permalink

Hello Oleg,

   Unfortunately, we don't have OpenAPI for such a case. In fact, we don't have OpenAPI for plugins at all, because OpenAPI is provided only on the core level in TeamCity.

   Could you probably describe your request in some generic way, so the solution would be useful for other Perforce customers as well?

   Kind regards,

0
Comment actions Permalink

Hi Kirill,

The title of my request is generic. Perforce is just an example, but you can imagine any VCS here. This is the closest that I found to what I need:

http://javadoc.jetbrains.net/teamcity/openapi/current/jetbrains/buildServer/agent/AgentLifeCycleAdapter.html#sourcesUpdated(jetbrains.buildServer.agent.AgentRunningBuild)

Something like "updateSources" with a string result could be useful.

I imagine there are multiple p4 commands that TC runs during "updating sources" section. I would like to analyze the text from an error from any of those and potentially call "update sources" again within the same build. For my example, I might call "ipconfig /flushdns" to rediscover the alias. Sources can then be updated as usual.

0
Comment actions Permalink

Hi Oleg,

Unfortunately, the listener is very passive at the moment, and it is not quite simple to change its behaviour so it would 

On the other hand, have you considered to run ipconfig /flushdns explicitly on all build agents after alias change, as a separate build configuration?

Alternatively, you can prepare a plugin which would always run ipconfig /flushdns before source checkout stage (http://javadoc.jetbrains.net/teamcity/openapi/current/jetbrains/buildServer/agent/AgentLifeCycleListener.html#buildStarted(jetbrains.buildServer.agent.AgentRunningBuild)

  Would it help?

0
Comment actions Permalink

The alias does not change. For whatever reason, the machine temporarily fails to resolve it. "ipconfig /flushdns" MAY help or MAY NOT. So we consider it as a troubleshooting action that we do not want to run under normal circumstances to avoid risking breaking something else.

Yes, we considered "always run ipconfig /flushdns before source checkout stage", but our network admin is unsure whether this would negatively impact some other working function of a working machine. Hence, we want to try to use this to mitigate the problem when we see "No such host is known." At this point, the machine is already "broken" and we accept the risk of running "ipconfig /flushdns".

It sounds to me like there is no extension to plug into for our purposes. Should I create a YouTrack issue?

0
Comment actions Permalink

Hello Oleg,

   Thanks for the explanation. You're right, at the moment there is no a way to force repeating the checkout process from an external plugin via OpenAPI. 

   Please create an issue, thanks!

   KIR

0

Please sign in to leave a comment.