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.
Related
Our Jenkinsfile keeps growing and reached a point where it’s hard to keep track of everything. We would like to “split” some of the parts into their own subfiles (see “include for make” https://www.gnu.org/software/make/manual/html_node/Include.html for instance).
While looking for a solution, “shared libraries” https://jenkins.io/doc/book/pipeline/shared-libraries/ keep coming up. That’s basically what I want, but it seems to address a different problem (providing common/shared functionality across different Jenkinsfiles) and also adds a lot of complexity (additional git repository). We’re simply looking for a way to decrease the complexity of one big Jenkinsfile by splitting it into multiple smaller ones.
Did I oversee the solution in my research? Or is there currently no solution to manage tasks/stages/function from the Jenkinsfile into separate modules in the same repo?
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
We have the full Atlassian product range and I am looking at how to make best use of it
We are using Stash to manage our Git 1000+ repositories all of which contain tags pointing to their versions.
I need to be able to define how our software versions depend on each other
For example:
System_x.y.z in production consists of
group_of_components_a_x.y.x consists of
component_a_x.y.z
component_b_x.y.z
...
System_x.y.z is release candidate_a consists of
....
System_x.y.z is in regression test
...
System_x.y.z is in performance test
...
System_x.y.z development is being tracked by Issue#
...
etc etc
I have been using ClearQuest to achieve this but would like to move to a pure Atlassian solution if it exists
I would also like to define a name for group_of_components so that I can attach owners to it as well as to components so we can use them elsewhere in the workflow.
can notify them when versions change.
In Issues so I can see when different teams are working in the same areas
I would also like to be able to use the System_x.y.z, group_of_components_x.y.z and component_a_x.y.z
In Defects so I can see where the error was found (System_x.y.z, group_of_components_x.y.z)
In Defects so I can see where the error was fixed (component_a_x.y.z)
Is any of this possible?
Is any of this possible?
The short answer is yes. It's all possible.
Jira has the following hierarchy:
Project
../ Epic
../../ Task
../../../ Sub-task
If you need to track version numbers as part of a product roadmap you need to use Projects for that feature. There are probably other hacky ways to use labels or components to do something like this but you will spend endless hours extending these hacks throughout Jira. Not a fun exercise IMO.
I need to be able to define how our software versions depend on each other
Dependencies can easily be added at the Epic/Task/Sub-task levels but I'm not aware of an easy way to do this at the version level. I'm only really aware of the Agile Cloud solutions. If you install this locally I'm fairly sure you could find a way to do this if it is truly needed.
I would also like to define a name for group_of_components so that I can attach owners to it as well as to components so we can use them elsewhere in the workflow.
It's very easy to name all issue types and projects. Projects have an owner. All issue types can be assigned to any user (with access rights). Additionally you can add users to the "watch-list" of every issue.
can notify them when versions change.
The watch-list will notify all watchers by email. Additionally you can set up workflows to reassign or marshal each record through a custom workflow.
In Issues so I can see when different teams are working in the same areas
You can add users to teams in any combination (users can be on multiple teams) but I'm not sure I fully understand what "areas" means. You can search, filter and report on all issues by team(s) if that's what you mean.
I would also like to be able to use the System_x.y.z, group_of_components_x.y.z and component_a_x.y.z
In Defects so I can see where the error was found (System_x.y.z, group_of_components_x.y.z)
In Defects so I can see where the error was fixed (component_a_x.y.z)
Each bug you define:
can be organized into an Epic
can be associated to any number of tasks (Blocks task 1 or is blocked by task 2, etc.)
has one or many "affects versions" to track where the bug occurred
has one or many "fix versions" to track when the bug was fixed
I have a problem, I have several versions of the same application but the process of duplicating and managing several duplicate applications is becoming very complex, each copy gets unique features by client demand.
What methods are used to simplify this process?
Do I need to have detailed documentation about every App?
I'm trying to separate the code by modules and had them according to the clients demand, am I on the correct path?
Sorry for the bad English, any question just ask, I'm always online.
This can be managed in your code revision system. Git and Mercurial allow you to manage code as "change sets". You could have a branch for each client, and have a main branch (trunk) where you add features for everybody. In the client branches, you add feature sets for individual clients. If you want to merge them back to the trunk, you can. You can also merge from the trunk to branches.
Of course, it's important to develop in a modular way in order to facilitate this approach. Also, unit tests speed things along when you have to merge.
The Grails framework has a lot of constructs/features that allows for adhering to the DRY principle ("don't repeat yourself") within a project. That is: within a specific project you're seldom required to repeat identical blocks of settings or code. So far so good.
However, the more I've worked with Grails the more of I've observed that I repeat code not within the same project but between projects. That is project A has controllers, GSP:s and images that overlaps with project B. This is a maintenance nightmare since bug fixes in project A must also be fixed in project B, etc.
I'd like to take DRY to the next level by not duplicating code between my projects.
My question: How do you tackle this problem (violated "inter-projects DRY") in your own internal Grails projects?
Please be very specific/concrete. If possible try to include specific code examples on how you solve it in practice.
Writing a custom plugin is the best way. You don't need to release it to the public repository, as you can use a private repository somewhere within your own network.
I haven't had enough duplicated code yet to pull out a plugin (most of the code repeated in my projects seem to be covered by the various public plugins), but a plugin can be as simple as a few common domain classes or services.
I agree with Lee, Using common/shared plugins is probably the best way to go. At one place that I worked we had quite a few internal plugins for this very reason.
The most common pattern is to put your common domain objects into their own plugin. This works really well for domain classes or services. We didn't end up refactoring the controllers, views, and static resources into a plugin, but the same principle should apply.
Long story short: Reuse of Grails artifacts = use a plugin.
To add to Lee and Colin's points, which are both valid, I think thinking in terms of multiple plugins can yield other benefits.
For example, you can split up your application functinality into multiple pieces, and have different people work on them. Or it can yield results during deployment, if, say, you need to have two layers of access to an app - user-level and admin - if your domain model is in a separate plugin, as Colin suggested, you can easily build two applications and deploy them separately.
For my app, I have several plugins specific to my project - domain classes plugin, one that is a bunch of code for importing data (which I can run easily against my site), some other plugins for graphing and customization of scaffolding. It takes a bit more thinking, but I expect this factoring will yield dividends in the future as we bring on more people to the team.