I think I remember reading that Jenkins doesn't advise you to poll SVN very often because it generates overhead. Instead, one should place a hook in the SVN commands.
How often can I safely set Jenkins to poll SVN? every minute? every 15s? To me it sounds it would just poll for a checksum and if it differs, then it does an SVN update. I don't think polling a checksum on SVN can have a negative impact on performance?
Each poll will check for any update in the SVN URL of that particular job. You can set the polling frequency based on the normal checkin frequency. It will not have much impact over your system performance as it just checks for update. If you are concerned about the system performance, I would suggest you to go for svn post commit hook that can trigger the build. You can read more about this Here
Related
I have installed SonarQube 7.6 Developer Edition, and starting using it on my development environment pipeline.
My coding approch is Trunk Based Development. We have only one mainline (master or trunk or develop as you prefer to define, but only one mainline)
Actually all changes on code pass through a Pull Request, that as I have understood, into SonarQube is recognized as a Short Lived Branch and only this hard coded rules are applied
Error conditions:
new open bugs > 0
new open vulnerabilities > 0
new open code smells >
0
That is a subset of my Quality Gates conditions.
It means that PullRequest could pass quality gate (becouse is recognised like Short-Lived Branch) and when it is merged into mainline (master/trunk) is applied my Quality Gates rules and could fail on merge.
How could I know if it break quality gate before PR approvement, or more easy, how to identify a Pull Request as a Long Lived Branch?
I have tried to define * as long lived branches pattern, but it does not work. attached a screenshot.
Actually, for SonarQube 7.6, this is the status:
All PR follow same rules of Short-Lived Branch and there is currently no
possibility to set up an ad-hoc Quality Gate (or at least the same as
the project), but this is planned for Q12019. More detailed, PRs and SLBs are recognized as 2 different things, but their presentation within SonarQube is the same.
There is no way to
identify PRs as Long-Lived branches (even with * in the long lived
branches pattern regex).
The only way to go for the quality gate
would be to avoid the PR and launch the merge on the mainline so as
to check if the quality gate passes.
Here there is a reply from SonarQube community manager
https://community.sonarsource.com/t/pull-request-analysis-and-quality-gate/6306/2
is it possible to configure a hard limit on the number of open changes for a given project in Gerrit?
When too many changes accumulate, rebasing them becomes an issue, especially when every rebase triggers a Jenkins job which takes some time to complete.
Hence I am looking for a way to force a limit on the open changes, so that Gerrit rejects new changes when too many are still open.
Thanks for help in advance.
You can start with git hooks. You can then use gerrit's ssh api or directly talk to gerrit's database to query outstanding gerrits.
Alternatively, consider using polling in jenkins instead of triggering a build on every change.
We're seeing a problem with Jenkins and the scheduling of builds. Specifically, we trigger Jenkins to build a pipeline of work with every push to every branch of our git repo. On its own, the whole pipeline can take from 10 to 20 minutes to build. This can cause a problem if multiple pushes to a branch happened faster than the builds are completing. Multiplied by the twenty or thirty branches that are in development.
So, I'd like to be able to automatically deprioritise any scheduled builds on Jenkins if they are triggered on a Git commit sha that is no longer the tip of its branch. This is just one example of a factor that might indicate a desired priority. Others would be that branches with open pull requests should have higher priority than those without; or manual input in order to prioritise a PR or branch that needs feedback immediately.
Is there anyway to programmatically interact with the Queue of jobs on Jenkins and reorder it?
There is the Priority Sorter Plugin, but as far as I know this assigns each build a static priority. I would like to dynamically reprioritise items in the queue based on external info (e.g. from git).
I've found reference to two other plugins whose names indicate that they might do what I want, but I can't find any meaningful documentation on them. The former doesn't provide the options it claims to, and the latter doesn't even exist in the plugins repository. Neither seems to be maintained.
My alternatives seem to be
write my own implementation of hudson.model.Queue, which seems like overkill
maintain a separate queueing service that triggers individual jobs on Jenkins, in which case what is Jenkins even for?
Am I missing something obvious? I can't be the only person who wants more fine-grained control of Jenkins build ordering.
In a scenario where continuous integration is important, for triggering builds which is a better option Webhooks or PollSCM.
These are my current understanding on both methods:
PollSCM is a heavy operation and depending on it to trigger build means we need to fire it frequently. But the configuration is easier and it is safer than web hooks as Jenkins will be communicating to code repo.
Web hooks can give you exact build trigger time without checking for it constantly. But on the other hand, there are security concerns when you are opening up a connection from outside and configuration is not easy compared to PollSCM.
Looking forward to know the exact pros and cons of both ways.
If your build cycle is very short (a few minutes) and if you want to trigger a build for each commit, the Webhooks solution is better.
But if your build cycle is longer (15/20 minutes) and if you don't need to build for each commit, the PollSCM is a good candidate :)
In my company, we are using Git/Stash and Jenkins + a Webhook to trigger a build every time something is committed. For the pull requests, we are using the Stash pullrequest builder plugin for Jenkins.
I set my Jenkins job to build automaticlally many times a day by the scheduler.
If the build is failed, it will send mail to my team.
However I don't want to spamming the mail box. How can I set a condition to stop the build scheduler if it was failed more than 10 times ?
Rather than scheduling the job continuously, try the continuous integration paradigm, like this:
Unconditionally schedule the job only rarely. Perhaps once per day, just to ensure than any external factors (missing resources, changed interfaces, etc.) haven't come into play.
Trigger the job when any known source or dependency changes (e.g. source code, jar in your artifact repository, DB schema change, etc.)
Use a suitable plugin to retry failures.
I recommend the Naginator plugin for this. It can nag a limited number of times, and it auto-throttles: it nags frequently to begin with, then less frequently after a protacted period of failure.
Even if you don't change how the job is trigger, Naginator is probably a good solution for you. Use it to send your emails, instead of using an unconditional on-failure step.