Tested with Yammer Plugin and buddycloud Plugin in Jenkins 2.x.
Since Yammer and buddycloud plugins depend on jruby based Ruby Runtime Plugin, installing those installs Ruby Runtime first.
As long as I don't restart Jenkins, the plugins work, and their settings persist. But after Jenkins is restarted the Post-Build Action settings on all job's configuration pages are lost and have to be re-entered. The jobs' respective config.xml files retain correct settings, but they seem to have no effect. Is there a fix or a workaround? thanks
Seems to be a widespread bug with Jenkins plugins Built on JRuby (and employing post-build actions). I had this same issue with a different plugin that fit this same mold (https://help.rallydev.com/jenkins). Looks like the issue is logged with Jenkins as Issue #114 (https://github.com/jenkinsci/jenkins.rb/issues/114). Still unfixed, but at least there is hope.
Related
I've asked this question on Gitter, but answer directed me to the documentation I followed.
I'm administrator of TeamCity 2017.2.2 with agents running on Windows 10 (except one on 7). I installed allure-teamcity plugin version 2.6 and added allure tools in version 2.6 as described in the documentation.
The problem is the tool is propagated to the agent on upgrade, but not the plugin itself. Main server shows me the runner I can use as a build step, but once configured none of agents accept this configuration. I've checked agent directory and logs - the plugin is not there and logs doesn't indicate that there was even attempt to pull.
As a holder of commercial license I asked JetBrains technical support, but they told me I need to ask Allure authors. GitHub sends people to Gitter and here, hence the question after unlucky attempt on Gitter.
What do I need to do to get the plugin correctly pulled and working on agents?
Is allure plugin even compatible with TeamCity 2017.2.2?
The problem is that Allure TeamCity plugin looks for a tool called allure-commandline. So you need to make sure that allure-commandline.zip is present in your <TeamCity Data Directory>/plugins/.tools directory.
I want to setup jenkins using the command-line only. I am successfully able to install plugins and configure jobs. So i've installed the maven-plugin using jenkins-cli but want to be able to configure it to say "Automatically install maven latest version" so that when the user triggers a build it will automatically go download maven and then use it just like it does using the GUI.
Any advice on how i can do this piece of configuration on the command-line (or scripted ideally) please?
This option is not and should never be available for the reason that it destroys the concept of reproducible builds.
Changing the maven version deliberately may break the build at some future time for no apparent reason and will definitely startle your users then.
Please avoid this situation.
Why not use maven wrapper instead, this way each project configures specifically which version of maven it needs and automatically downloads it.
https://github.com/takari/maven-wrapper
https://github.com/takari/maven-wrapper/blob/master/README.md
I'm using TeamCity Professional 9.0.2 (build 32195).
I installed the tcWebHooks plugin:
But I do not see any changes to the admin, and I cannot determine where to add web hooks to my build. I see no additional options in either the Project configuration or the Build configuration. Did I miss a step? From what I'm reading in the documentation, it should be a Project level setting with additions to the Project Home view.
This appears to have been an issue with the 0.9.27.61 version of tcWebHooks. I installed 0.9.18.165 and everything works as expected.
It's in a weird spot in TeamCity for some reason. You go under a Build Project, without going into Edit Project Settings.
EDIT: I'd also check the tcWebHooks blog for more info: https://netwolfuk.wordpress.com/category/teamcity/tcplugins/tcwebhooks/
We are having a strange issue with our Jenkins plugin. In the development environment (running using mvn), the plugin works perfectly fine. But when we install the plugin (using marketplace or hpi file) to seemingly any version of Jenkins, it is totally broken. Our post-build action (publisher) registers but our configuration form is completely blank. It only shows the delete button to remove the action. What could be different about running from maven (hpi:run) vs installing from the marketplace or hpi file?
I finally figured it out. The capitalization of the resources folder that corresponds to the publisher must match the capitalization of the publisher class name. I think this would probably only be an issue on windows. Also its strange that it works totally fine in the dev environment.
I would like to integrate Jenkins with Redmine. If some build breaks, Jenkins would open an issue in Redmine to notify it with the console output.
How can I do it? Are there any plugins? Are there any implementation guides? I couldn't find a solution yet.
There are two ways to achieve this
install hudson plugin inside redmine, see http://www.redmine.org/plugins/t-ando_redmine_hudson , it will let you know the build inside redmine. (**2014.5.7 [Updated] change to redmine plugin list **)
install redmine plugin inside jenkins (hudson), unfortunately the plugin is not maintained any more, https://wiki.jenkins-ci.org/display/JENKINS/Redmine+Plugin . And JIRA jenkins plugin is a way how redmine plugin should be supported.
([Updated] the plugin is back since 2013)
[updated] I tried to add this functions for solution 2 in 2011.2, see my blog: http://larrycaiyu.com/blog/2011/02/24/associate-ci-build-information-in-redmine-issue-by-using-redmine-rest-api/, but I stopped after that, because
In the community, it seems solution 1 is preferred.
lots of functions are already inside JIRA, it is better to persuade them to make it as a common issue plugin inside jenkins.
You can try the e-mail-to-issue option in Redmine.
Configure Jenkins to send an e-mail to Redmine with detailed report.
Configure Redmine to accept the e-mail and transfer it to the issue.
You can configure whatever template you wish so the reports will be user-friendly. Further more Redmine has a simple incoming mail parser so that you can omit info you don't need.
No plugins needed, only settings in both tools.