I'd like to develop a Gradle plugin that performs some operations on the Jenkins model object.
(such as automatically fingerprinting the compile dependencies and the published ivy artifact)
Do you know if it is currently possible to retrieve the instances of Jenkins' AbstractBuild and other classes from a gradle plugin ?
I'm not sure how you'd achieve this with a Gradle plugin, as you need to be running inside the Jenkins JVM to access the model object. You might find it easier to use the REST API if it exposes the data you need. Otherwise you'd need to attach to the Jenkins JVM process remotely.
Related
I am writing a scala client that should perform several reads from maven remote repository (dependency tree evaluation).
To perform e2e tests to my code I need a running maven repository (artifactory, nexus, archiva etc...) with several artifacts deployed.
I am looking for a way I can use test utility that will allow me to start embedded server with code configured artifacts and dependency relationship. That way I can set it up just before my test, use it and stop it.
If possible - I want to avoid using filesystem
Of course - that library can be either scala or java
There is a MockRepositoryServer in the Mojohaus project run by the Maven committers and others that does what you need. It is specifically designed for that exact testing purpose.
You can also use a full blown Nexus Repository Manager in a local install. Either will work.
I want to include the workflow of the Ember CLI into a Play! application. I decided to write an sbt plugin that, when enabled in the play applications build, will do a few things:
Add a task to run "ember new" to create the UI project in a sub directory.
Add a PlayRunHook so that when run is executed from the activator shell, it also starts the node server serving the EmberJS application by setting the proper proxy such that the api calls are proxied to the Play! application.
When the package is called, it also packages the EmberJS application.
Properly sets up the UI Assets to include the EmberJS application.
The problem is I am not able to find out how to add a dependency so that I can use the PlayRunHook trait and PlayKeys in my sbt plugin.
I want to use the plugin route because in the future I may have more services that will have the same kind of workflow.
Update:
I could not find out a way to create this plugin as I was not able to access PlayRunHook from that plugin. But, I have implemented what I wanted as a seed project. Link: https://github.com/dipayanb/play-ember-seed
While writing the sbt plugin I was not able to write a class similar to https://github.com/dipayanb/play-ember-seed/blob/master/project/EmberRunner.scala as I was not able to compile the code from inside the plugin.
Without seeing the code you're using to try and implement the plugin, this will be hard to answer, but in short you need to add the Play! plugin to your plugin's build definition. That is added in the same way as usual, inside your plugin's project/plugins.sbt:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % playVersion)
Because SBT is recursive, it is not sufficient that your project has the plugin you're trying to access: your plugin needs to load the plugin itself.
What I have is this.
I have defined in sbt my publish task which publishes to artifactory. Im running it in a Jenkins job as a shell build step.
What I would like to do is to include all the environment information that the Jenkins Artifactory plugin includes when it deploys. I dont know if I should it add it to sbt or if there is some way of configuring the Plugin to use sbt but do the publishing himself.
Currently there is no integration for sbt and Artifactory Jenkins plugin, what you can do is to use the Generic deployment feature of the plugin. The plugin will upload as part of the deployment a build info json object with some of the system and environment variables.
Because the plugin doesn't record the actual build process
then all the run time goodies will be missed but you could inject them by using buildInfo.property.* - All properties starting with this prefix will be added to the root properties of the build-info.
I'm developing my own hudson plugin and can not find a really comprehensive documentation.
How can I connect to the artifactory plugin to get a list of artifacts? The artifactory plugin is installed in hudson but I don't know how to instance it/connect to it from my own plugin.
My plugin deploys a specific version to our webstart server. This includes downloading the artifact from artifactory over HTTP, creating version.xml and *.jnlp file and uploading these three files to the webserver using SCP. For the configuration of this plugin, I need a list of all versions of a specific project from artifactory.
Thanks in advance.
If you'd like to use model and utility classes of another plugin, then it's simply a process of depending on that plugin (compile-wise) and making sure that the dependent plugin is installed so you can reference these classes at runtime.
If you'd like to use entities like builders, actions or wrappers, you'll probably need to use Hudson's facilities; I'm not so sure as to which facilities it has, but Jenkins' hudson.model.AbstractBuild and hudson.model.AbstractProject (and other) objects have methods like:
hudson.model.Actionable#getActions
AbstractProject#getPublishersList
That'll return those entities (assuming they're configured on the project in question).
Apart from that approach, there are a number of ways to solve your issue using Artifactory's REST API:
If the artifacts are contained in Artifactory within one location that's known to you, you can execute a file list query to reveal the contents of that directory.
If you'd like to fetch the produced artifacts of a specific Hudson build, and assuming that you use the Hudson plugin to deploy Build Info, you can request the Build Info object using the Build Info resource; utilizing the checksums of the produced artifacts listed in this object, you can perform artifact checksum queries to find out if and where these artifacts exist in Artifactory.
If you don't know the specific build name and number or the location, you can use any of the search facilities to locate artifacts based on different details; The GAVC or XPath searchers are most likely to help in your situation.
Here is the situation. A development team has a large number (hundreds) of Eclipse projects. The code is very much in churn - new projects are being created; projects are being renamed and project dependencies are constantly changing. The external build system is ant. It is proving extremely challenging to keep the dependencies defined in the ant build files in sync with the state of the world in Eclipse. The external ant build needs constant changes to keep up. For various reasons, using ant as the default builder in Eclipse is not an option. The developers want to continue using Eclipse as the build and edit environment for local use.
Question: Is there a tool which will allow a single set of dependencies to be maintained which can be used by Eclipse as well as an external build system like ant?
I have heard of Gradle but never used it before. Would it make sense in this context? I am pretty sure Maven wouldnt work for what is needed
The typical workflow should be:
1. Developers continue working as they currently do - creating and changing Eclipse project dependencies at will and using the default Eclipse builder to compile and test locally.
2. Some mechanism exists by which these dependencies can be carried into an external build system like ant and an external continuous build triggered on every checkin.
Appreciate your feedback - thanks!
We have been quite successful at using Gradle to tackle a similar problem. Here's the outline of the setup
Each project contains a build.gradle that defines project specific dependencies and tasks (may even be empty).
A special master project contains build.gradle that sets up common dependencies and tasks for child projects, and/or injects settings pertinent to a group of child projects.
Logically master project is the parent project, but it exists as a sibling folder so that Eclipse can be more comfortable with it.
Gradle contains a built-in Eclipse plugin which allows generation of Eclipse settings files for each of the projects from the dependencies information (including inter-project dependencies). It works nicely for simple projects, and as for more complicated ones Gradle allows you to tinker with the settings files, so you can do pretty much everything. From here you have two options:
Not to store Eclipse settings file in the repository and call the generation task every time you do a fresh check-out (I prefer this option).
Tell Gradle to use custom variables to make it generate generic settings files which can be checked-in to the repository. You'll then only need to run the generation task when dependencies or other configuration changes.
(Optional) It's a little tricky, but you can make Gradle parse existing project ivy.xml files and set up dependencies from there. I had some success with this, although I would recommend converting dependencies into Gradle format for more flexibility.
Continuous build system integrate with Gradle very well (same as ant). If you are using Jenkins (Hudson) there is a Gradle plugin.
The advantage of using Gradle is that it scales pretty well, and you can support other IDEs like IntelliJ or Netbeans at the same time without much effort (unless you have lots of crazy custom settings). An advantage and a disadvantage is that Gradle is a powerful build system which requires learning Groovy and Gradle DSL which may take some time to acquire. Also the documentation is awesome.
Gradle has a very active community with the sole purpose of tackling exactly this kind of problem.
Hope this helps, and best of luck!
How about parsing the .classpath files, generate a dependency tree and start building from the root. What you need is a convention on the layout of your projects or an generic (ant-) buildfile that could be changed in each project, if needed (e.g. different project layouts). I´m not sure if Eclipse Tycho could be used for that, since it´s a maven plugin(s) to build eclipse plugins or projects. But it´s able to resolve the bundle and project dependencies against maven repositories and eclipse update sites.