I am using jenkins with the pipeline plugin to build my microservices based application. This works basically, but there is no way to get a good overview which services have been build last for which branch and what the result was. Even the new Blue UI falls short :-(
I just want to have the name + last builds results for the pipelines to be able to see if something is going wrong somewhere.
I have searched for plugins which might help here but I had no luck.
Has someone solved this in some way already?
I don't want to spend my time writing my own visualization, but I am beginning to realize that this will be the way to go. :-/
If nothing like this exists does someone know a good source to start to use the jenkins api for this kind of visualization?
You can do that using https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View
It allows you to add a job list and specify the jobs to be included using a regular expression. Hence, new jobs for feature branches should appear automatically.
I guess, this will be a one end to end product for you. I have been using it from the last 6 Months.
This is much better than the other Dashboards.
Hygieia Dashboard
Related
So I have been tasked with creating some clean up jobs in Jenkins and one of the stages is gathering a list of all the RPM's then filtering them based on the set up and deleting the appropriate RPMS's.
I of course have to script this job and have no clue where to even start or how to even attempt to get a list of the RPM's if someone could point me in the right direction of provide me with some scripts that would be great :) Struggling to find resources that could help me, so any support would be appreciated.
Kind regards,
IA
Is there a proper way to create a build matrix specific for Pull Requests?
The idea is:
In normal builds, I want to test a few things only (code style/standards, some unit tests, some general validation). Mostly one item only in the build matrix.
In pull requests, I want to run the tests with several different environments, including different databases and versions. This is what I currently have but it demands a lot from travis (and it is slow).
I know I can achieve that in the script by checking TRAVIS_PULL_REQUEST and skipping the tests, but that will misleadingly show some environments as "passed" when they were actually not tested.
Thank you for any help / guidance,
Daniel
Interesting wish!
This is not possible at the moment. You might want to chime in on https://github.com/travis-ci/beta-features/issues/11 to bring it to the attention of the relevant people.
Is it possible to trigger Jenkins builds on nodes with an unknown label value based on a build's parameter?
I've got a job for building that allows our devs to do just about any kind of build they want, including specified hardware to build against. The problem is that this list of HW is always changing, and I'm trying to stamp out tech debt. I would like it to be where the only necessity is a hardware-specific node having a label the devs know about, and them using a string parameter to match that node label to build against that hardware. They may have labels like, Gen1, Gen2, ProtoXYZ, who knows, you know? It evolves, constantly.
I've seen a few similar questions, but for this one, there isn't a solution, and for this one, I'm not actually sure what's going on here. I've yet to touch Groovy, and I'm trying to do as much as I can with plugins and existing Jenkins functionality.
That doesn't mean I won't do Groovy scripts -- it's just more that I'd like to not obfuscate the process with custom scripts.
Edit:
I'm still testing it, but it looks like this one-liner Groovy script with the plugin, "Groovy Label Assignment" seems to work, but I will check back within the hour:
binding.getVariables().get("HARDWARE");
Where HARDWARE is a parameter that is set by a job parameter. The one thing I'm left to check is whether I can mix and match known and unknown labels with this functionality, e.g., a small drop-down box with known choices, but one choice essentially being "Other, please enter".
Edit: I've been so frazzled that I googled my own previously answered question, answered by myself no less xD I've changed the title to match something more search-engine friendly. Original title was,
Is it possible to trigger Jenkins builds on nodes with an unknown
label value based on a build parameter?
Okay, so this is cool. Yes, this is possible. I did use a Groovy script, but it was a one-liner working in conjunction with a plugin, so not much overheard to keep track of, which I considered acceptable.
First thing's first, using the plugin's site's instructions, I tried this out:
binding.getVariables().get("HARDWARE");
HARDWARE is a job parameter. It's actually a drop-down box, e.g., a Choice Parameter, from that plugin. To invoke this plugin, there's a box to check after installing it called,
Groovy script to restrict where this project can be run
It works like in conjunction with one of my parameters:
Choice1
Choice2
Choice3
${CUSTOM_CHOICE}
In the job, I set ${CUSTOM_CHOICE}'s parameter before I set HARDWARE. This allows HARDWARE to inherit the value of ${CUSTOM_CHOICE} if it exists. It's not idiot-proof, but it gives my devs the flexability to use some well-known choices, or go crazy and experiment. I've verified that this functionality works.
I have got a few Jenkins jobs. They look very similar to each other and differ only in details. Originally they were created by copying the first job.
If something changes in one of the jobs configuration, then it has to be applied to all the other jobs configurations. This makes Jenkins maintenance more complex, longer and error-prone.
What I'd like to do is to pull up at least some common parts of jobs' configuration and keep it in one place so I don't have to apply each configuration change to all the jobs separately. Is is possible, and if so, how can this be achieved?
I would like not to create new project or change the way jobs are structured (upstream-downstream dependencies) as all these jobs are legacy.
Thank you in advance!
There are several plugins that help with that. Inheritance plugin comes to mind
You can also have a look to the Template Project plugin.
With this plugin, you can use the builders, publishers and SCM settings from a template job.
We are using this plugin in my company and it works well :)
I think Jenkins DSL Plugin can be used to solve this problem too.
Accordding to its summuary:
Jenkins is a wonderful system for managing builds, and people love
using its UI to configure jobs. Unfortunately, as the number of jobs
grows, maintaining them becomes tedious, and the paradigm of using a
UI falls apart. Additionally, the common pattern in this situation is
to copy jobs to create new ones, these "children" have a habit of
diverging from their original "template" and consequently it becomes
difficult to maintain consistency between these jobs.
It enables a programmatic creation o jobs using a Groovy Domain Specific Language.
In JIRA a resolved issue can have different resolutions: e.g. Won't Fix, Cannot Reproduce, Fixed etc. I had been using JIRA without Greenhopper and using these resolutions was part of the workflow.
Now I'm using JIRA+Greenhopper with Kanban boards and I'm trying to extend the workflow to have few steps associated with the Resolved step:
In QA which is Status:Resolved,Resolution:Done;
Won't Fix which is Status:Resolved,Resolution:Done;
Backlog which is Status:Resolved,Resolution:Backlog;
etc;
When trying to edit the workflow I learned that it is not possible to have two steps that correspond to one status (Resolved). Is this the case?
At the moment it actually is not possible to set the issue to any resolution different than Done as
the 'Resolve' button is not available on the issue screens (I already asked here about the missing button).
I have tried to set up a new transition which would move the issue into Status:Resolved, Resolution:Won't Fix but I'm hitting the problem that for active workflows if there are no outgoing transitions already defined you cannot create new ones.
Questions:
Is it possible possible to map two workflow steps to one status? Am I missing something and the Won't Fix, Cannot reproduce resolutions don't fit into the Greenhopper way of thinking?
I recommend creating a JIRA workflow from scratch and provide detailed steps in Practical JIRA Administration (O'Reilly). I also recommend having a 1:1 mapping of JIRA step name to status name, and JIRA doesn't do 2:1 mapping. I think you probably want to create new statuses for your workflow, e.g. In QA.
The system resolution field is designed as a kind of sub-status for one, maybe two, statuses. People usually use it just with Closed.