Using this extension, you can watch for Ant tasks, modify/patch them and log various messages to the build log. This extension works in the same JVM where Ant is running. The TeamCity Ant runner, while being a plugin itself, can also be extended with the help of .AntTaskExtension. If the command line build service is not suitable for your needs, you can still implement the AgentBuildRunner interface and define it in the Spring context. Since TeamCity 6.0, we introduced the .BuildServiceAdapter class that extends CommandLineBuildService and provides utility methods to access build and runner context parameters.ĪgentBuildRunnerInfo has two methods: getType which must return the same type as the one returned by the server-side part of the plugin, and canRun which is called to determine whether the custom runner can run on the agent (in the agent environment). The factory also provides some meta information about the runner via .ĬommandLineBuildService is an abstract class which simplifies external processes launching and allows listening for process events (output, finish and so on). You should implement the CommandLineBuildServiceFactory factory interface and make your class a Spring bean. However, if your custom runner runs an external process, it is simpler to use the following classes: The main interface for agent-side runners is. But if you need more control on how the page is processed on the server side, then you should register your own extension to the runner editing controller: .projects.EditRunTypeControllerExtension.Īnd finally if you need to prefill some settings with default values, you can do this with the help of the getDefaultRunnerProperties method. Usually a JSP page is simple and does not provide much controls except for fields, checkboxes and so on. This processor will be able to the verify user settings and indicate which of them are invalid. When a user fills in your runner settings and submits the form, returned by the getRunnerPropertiesProcessor method will be called. TeamCity 5.0.x and earlier uses the following rule to compute a full path to the runner's jsp:īefore writing your own JSP for a custom build runner, take a look at the JSP files of the existing runners bundled with TeamCity. ![]() jsp file from the buildServerResources folder of the plugin. The plugin class may use PluginDescriptor#getPluginResourcesPath() method to create a path to a. jsp file or a path that is handled by a controller. ![]() Since TeamCity 5.1, the path to the build runner resources files should be a full path without context. The paths should be relative to the buildServerResources folder. These JSP files must be bundled with plugin in buildServerResources subfolder, read more. The getEditRunnerParamsJspFilePath and getViewRunnerParamsJspFilePath methods return paths to JSP files for editing and viewing runner settings. RunType has a type which must be unique among all build runners and correspond to the type returned by the agent-side part of the runner (see ). A build runner plugin must provide its own RunType and register it in the. The main entry point for the runner on the server side is. ![]() Some build runners whose source code can be used as a reference: These settings are called runner parameters (or runner properties) and provided as a Map to the agent part of the runner. The agent-side part launches builds.Ī build runner can have various settings which must be edited by the user in the web UI and passed to the agent. The server side part of the plugin provides meta information about the build runner, the web UI for the build runner settings and the build runner properties validator. A build runner plugin consists of two parts: agent-side and server-side.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |