How to use Jenkins Build Keeper Plugin - plugins

I would like to use the Jenkins 'Build Keeper Plugin' but I don't know how. The plugin site doesn't describe how to use it. Plugin Site
On this page I found the extension points which I would like to use, e.g. the org.jenkins_ci.plugins.build_keeper.KeepFirstFailedPolicy
But in the configuration part of my project, I can't find any place to configure it to use that policy. So where do I have to add it?
Jenkins version is 1.544

Have you tried to open Job configuration page and look for settings ?
For example it is another plugin but it is very similar : Build Discard plugin, may be you will use it for your purposes:
Build discard old build settings

You can configure it in the job under the section Build Environment.
For screenshots see also https://issues.jenkins-ci.org/browse/JENKINS-25293

If used from within a pipeline, it is enough to write
'currentBuild.rawBuild.keepLog(true)'
That is unfortunately not an interface to the plugin, just a jobs setting, but can solve it when You want to keep all builds, or decide within the build if to keep it.

Related

How do i create a custom devcontainer?

i have been using devcontainers for a while, and i want to extend some of them.
For instance, i want to install all the linting tools etc for various languages, and use a more personalised container as a starting point (compared to the Microsoft hosted ones).
I also like to host the containers on my own dockerhub, so i do not need to build all this stuff every time. There could also be the use case of using devcontainers for something other than the standard libraries.
I know i can just manually change the docker image reference, but i also like to integrate my changes into the plugin, so i can have my own repository show up as well, to get a native feeling.
I could not find any information on creating my own dev containers, only on extending existing ones. Is any of this i mention officially supported?
Edit: To sum all this up in one question; Can i add devcontainers from my own repo, without merging them into https://github.com/microsoft/vscode-dev-containers ?
If you are using VSCode as the text editor you can install the remote extension pack which allows you to add a template for a devcontainer to your project.
If you aren't using VSCode you can use the templated version as the basis for your own. I created a template repository with the files needed for Python project which you can refer to as well

cloud9-ide collaboration in self hosted possible?

Is it possible to have the collaboration and workspace sharing features in a self-hosted environment built from https://github.com/ajaxorg/cloud9?
it is possible with the newer version from https://github.com/c9/core, just pass --collab flag to the server.js script
The --collab flag activated the "Share" and "Collaborate" buttons for me, but the actual feature doesn't work. When adding a user, I get
Error adding workspace member: Cannot POST /api/collab/0/members/add?silent=false&access_token=token
Any solution to this? I feel like passing the --collab flag is more of a hack than anything and not intended to be run on self-hosted users, only for Cloud9 servers.

How to parameterize Bamboo builds?

Please note, although my specific example here involves Java/Grails, it really applies to any type of task available in Bamboo.
I have a task that is a part of a Bamboo build where I run a Java/Grails app like so:
grails run-app -Dgrails.env=<ENV>
Where "<ENV>" can be one of several values (dev, prod, staging, etc.). It would be nice to "parameterize" the plan so that, sometimes, it runs like so:
grails run-app -Dgrails.env=dev
And other times, it runs like so:
grails run-app -Dgrails.env=staging
etc. Is this possible, if so, how? And does the REST API allow me to specify parameter info so I can kick off different-parameterized builds using cURL or wget?
This seems to be a work around but I believe it can help resolve your issue. Atlassian has a free plugin call Bamboo Inject Variables Plugin. Basically, with this plugin, you can create an "Inject Bamboo Variables from file" task to read a variable from a file.
So the idea here is to have your script set the variable to a specific file then kick off the build; the build itself will read that variable from the file and use it in the grails task.
UPDATE
After a search, I found that you can use REST API to change plan variables (NOT global). This would make your task simpler: just define a plan variable (in Plan Configuration -> tab Variables) then change it every time you need to. The information on how to change is available at Bamboo Knowledge Base

P2 headless update not working

I have taken the org.eclipse.equinox.p2.examples.rcp.prestartupdate project and adapted it for use in my RCP application. I then setup an update repository that gets updated as part of my nightly build.
When I open my application it goes through the motions like it is updating - it finds the update site, generates an uninstall and install operand for each bundle correctly and says that it finished with no errors. The problem is that the plugins never actually get installed in the plugins folder even though the profile gets updated (a subsequent run states there are no updates). Next time my build runs it correctly identifies there are updates, but the same thing happens again.
I have spent days debugging and the only thing that looks out of the ordinary (not that I fully understand what is going on) is that during the final configure phase none of the TouchpointData objects have any instructions so it doesn't look like configure is doing what it should.
I really have no clue where to look next and would like to see if anyone else has any ideas.
Update:
I finally figured out what was going on.
The problem started when I built my product without the generating the metadata repository. When building through Eclipse I didn't check the "Generate metadata repository" in the export product wizards because I didn't need a p2 repository, just the product. The problem is that without checking that button the product does not install as P2 enabled causing side effects such as not generating a profile among other things.
I tried to compensate for this by manually creating a profile in code which I have since found out is a really bad idea. My original problems were created because my profile wasn't set up correctly.
Once I started exporting the product with "Generate metadata repository" checked the update started correctly installing the new plugins.
The problem I have now is that although the plugins are being installed correctly, the executable is getting trashed and I cannot launch my application any more. I am building my update site through Hudson and the binary folder which is present when I use the Eclipse Export Product wizard is missing. I am assuming that is what is going wrong now.
Any ideas why the binaries would not be building in my headless PDE build?
Figured this out also. I had assumed that all I needed was the individual launcher plugins for the platforms I wanted to build on. Since I was trying to understand the process I was copying over plugins one by one to the build server. It turns out to include the platform specific binaries in the build you need to have the org.eclipse.equinox.executable feature from the delta pack. Once I added that to the build the binaries started showing up in the output. With the binaries the update mechanism works exactly as intended.
I had assumed that all I needed was the individual launcher plugins for the platforms I wanted to build on. Since I was trying to understand the process I was copying over plugins one by one to the build server. It turns out to include the platform specific binaries in the build you need to have the org.eclipse.equinox.executable feature from the delta pack. Once I added that to the build the binaries started showing up in the output. With the binaries the update mechanism works exactly as intended.

What is the best way to integrate an external build tool into Eclipse?

I've just started using Eclipse for Python development since we can make use of a lovely plugin I've found to enable distributed pair-programming. Anyway, the next step to getting Eclipse to integrate properly with our existing environment, would be finding a way to drive our current build tool (Waf) from within the IDE.
So the question is, is there a way I can set up Eclipse to drive Waf in a Make-like fashion? I see for Make it has some quite advanced functionality, such as being able to work out what targets are available etc. Bonus points for telling me if there is a way I could go as far as this! (I suspect the answer is that this is all built in to the Make plugin for Ecplipse).
In eclipse CDT I run waf by simply changing the build program in
ProjectPreferences->C/C++ Build->BuilderSettings
Choose External builder and then put in the path to waf
for example I use
/Users/mark/bin/waf -v -k -j2
Note that waf and make do not agree on the -j setting and you have to give i explicitly and not use the eclipse dialog.
You can use the Make targets view add the targets to call waf e.g. configure, build etc.
One issue I had is that Eclipse is hard coded to see the output from Make say Make when i changes directory so I had to patch waf
see waf issue
You could try and define a Custom builder, calling Waf with the appropriate options for the python compilation step.
(From eclipsejdt alcatel-lucent manual)
That picture (not related to Waf at all) illustrates the fact a builder can be defined as an external tool (meaning any .bat or shell you may want to call)
In that "eclipsejdt" example, the custom builder was configured like so:
To set up the builder, bring up the property dialog for project "jex1p" by selecting the project in the Package Explorer and selecting Project > Properties > Builders. Then click New..., select Program, and click OK.
Configure the builder Main tab using values:
Name : nmbldr_pre
Location : ${system_path:ksh}
Working Directory: ${build_project}
Arguments : nmbldr -p 2 -t ${build_type} -s jpre
As VonC says, the elegant way is to use a Custom builder.
Alternatively it is less work (in the short term) to hack together an ant script to do the heavy lifting and define an external builder to configure it onto the project. You may find the drawbacks of an external builder (e.g. no incremental support) mean it is worth investing the effort to do it "properly".