Upgraded 1.599->1.605
Matrix job is used
In order to chooseparticular configuration or run All of them the following groovy expression is used in Combination filter:
targetHost=="All" || targetHost.contains(hostUnderTest)
where
hostUnderTest is matrix axis that contains the list of available hosts
targetHost is build parameter and usually contains comma separated list of hosts against which tests are executed
It was working on 1.599 but fails with the following error after update to 1.605
FATAL: Scripts not permitted to use method java.lang.String contains java.lang.CharSequence
I suppose these are due to some security restriction - could someone please advise how to disable them or propose another workaround?
That is truly a pain. What version of the matrix-project do you have? You can see this through Manage Jenkins -> manage plugins
If its 1.4.1 then it is a bad release and you need to downgrade to 1.4 https://issues.jenkins-ci.org/browse/INFRA-250
I think you should be able to apply 1.4 over the top if you download it and used the advanced tab on the manage plugin page
According to this comment - appears to be expected behaviour.
Script works correctly after being approved by jenkins admin in
Manage Jenkins ยป In-Process Script Approval
menu
Related
I'm debugging a problem with atlassian-bitbucket-server-integration-plugin. The behavior occurs when generating a multi-branch pipeline job, which requires a Bitbucket webhook. The plugin works fine when creating the pipeline job from the Jenkins UI. However, when using DSL to create an equivalent job, the plugin errors out attempting to create the webhook.
I've tracked this down to a line in RetryingWebhookHandler:
String jenkinsUrl = jenkinsProvider.get().getRootUrl();
if (isBlank(jenkinsUrl)) {
throw new IllegalArgumentException("Invalid Jenkins base url. Actual - " + jenkinsUrl);
}
The jenkinsUrl is used as the target for the webhook. When the pipeline job is created from the UI, the jenkinsUrl is set as expected. When the pipeline job is created by my DSL in a freeform job, the jenkinsUrl is always null. As a result, the webhook can't be created and the job fails.
I've tried various alternative ways to get the Jenkins root URL, such as static references like Jenkins.get().getRootUrl() and JenkinsLocationConfiguration.get().getUrl(). However, all values come up empty. It seems like the Jenkins context is not available at this point.
I'd like to submit a PR to fix this behavior in the plugin, but I can't come up with anything workable. I am looking for suggestions about the root cause and potential workarounds. For instance:
Is there something specific about the way my freeform job is executed that could cause this?
Is there anything specific to the way jobs are generated from DSL that could cause this?
Is there another mechanism I should be looking at to get the root URL from configuration, which might work better?
Is it possible that this behavior points to a misconfiguration in my Jenkins instance?
If needed, I can share the DSL I'm using to generate the job, but I don't think it's relevant. By commenting out the webhook code that fails, I've confirmed that the DSL generates a job with the correct config.xml underneath. So, the only problem is how to get the right configuration to the plugin so it can set up the webhook.
It turns out that this behavior was caused by a partial misconfiguration of Jenkins.
While debugging problems with broken build links in Bitbucket (pointing me at unconfigured-jenkins-location instead of the real Jenkins URL), I discovered a yellow warning message on the front page of Jenkins which I had missed before, telling me that the root server URL was not set:
Jenkins root URL is empty but is required for the proper operation of many Jenkins features like email notifications, PR status update, and environment variables such as BUILD_URL.
Please provide an accurate value in Jenkins configuration.
This error message had a link to Manage Jenkins > Configure System > Jenkins Location. The correct Jenkins URL actually was set there (I had already double-checked this), but the system admin email address in the same section was not set. When I added a valid email address, the yellow warning went away.
This change fixed both the broken build URL in BitBucket, as well as the problems with my DSL. So, even though it doesn't make much sense, it seems like the missing system admin email address was the root cause of this behavior.
I've just upgraded SonarQube from 6.0 to 6.7 LTS running in a CentOS 6 box, and noticed that ElasticSearch (ES) failed to start because the kernel (2.6.32-696.3.1.el6.x86_64) doesn't have seccomp available.
This is officially documented at System call filter check and a correct workaround for systems without this feature is to configure bootstrap.system_call_filter to false in elasticsearch.yml.
The issue here is because Sonar creates the ES configuration at startup, writing in $SONAR_HOME/temp/conf/es/elasticsearch.yml and I haven't found a way to set bootstrap.system_call_filter property.
I tried a natural (undocumented) way introducing sonar.search.bootstrap.system_call_filter and bootstrap.system_call_filter properties in sonar.properties but it doesn't work.
We had the same problem. At first we used the above solution but after searching in the sonar code on github found the place where this setting should be placed:
Edit the sonar.properties file and change the line:
#sonar.search.javaAdditionalOpts=
to
sonar.search.javaAdditionalOpts=-Dbootstrap.system_call_filter=false
For sonarqube docker image, setup additional environment to disable this feature when "docker run":
-e SONAR_SEARCH_JAVAADDITIONALOPTS="-Dbootstrap.system_call_filter=false"
Hi I tried to echo bootstrap.system_call_filter: 'false' to temp/conf/es/elasticsearch.yml, I see the line in that file, but got same error during start of sonarqube 6.7 on centos6.
Has someone tested that with success?
First of all: don't even try to update elasticsearch.yml . SonarQube self-manages its ElasticSearch component config, so any attempt of manual intervention will be harmful. (reminder: the only config file that should ever be modified to operate SonarQube is sonar.properties)
More interestingly regarding that seccomp component:
the seccomp requirement does come from underlying ElasticSearch requirement, and transitively applies to operating SonarQube
if you run SonarQube locally with default config (specifically: default sonar.search.host), then the seccomp check may not be fatal (i.e. just a warning)
if you did override sonar.search.host , then the first thing you should wonder is: does the ElasticSearch JVM really needs to listen on other interfaces than loopback ? (knowing that SonarQube uses ES locally, except with the Data Center Edition). If no good answer to that, then keep sonar.search.host at its default value.
Last but not least, the golden path here is obviously to follow the requirement (i.e. have seccomp available on your OS), even if that involves upgrading to a more recent Linux kernel. And to wrap it all up: we've edited SonarQube Requirements to transparently share this situation.
You could really cheat and edit /${SONAR_HOME}/elasticsearch/bin/elasticsearch.
Add
echo "bootstrap.system_call_filter = 'false'" >>
/${SONAR_HOME}/temp/conf/es/elasticsearch.yml
before the "demonized" variable is set.
The whole morning I have been trying to setup e2e tests reporting via SonarQube's Generic Execution, by using the Generic Test Data -> Generic Execution feature.
I created a custom xml report that gets added to the scan properties like this:
sonar.testExecutionReportPaths=**/e2e-report.xml
So far, SonarQube seems to completely ignore this property and I no attempt to parse the file in the logs. Has anyone made it work?
These are links by Sonar about the Generic Execution feature:
https://docs.sonarqube.org/display/SONAR/Generic+Test+Data
https://github.com/SonarSource/sonarqube/blob/master/sonar-scanner-engine/src/main/java/org/sonar/scanner/genericcoverage/GenericTestExecutionSensor.java
This is a SonarQube 6.2+ feature. Make sure to use an appropriate SonarQube version.
In addition sonar.testExecutionReportPaths does not allow matchers (like *).
Please provide relative or absolute paths, comma separated.
See also:
The official documentation of the Generic Test Data feature
The source code, that looks up the generic execution files
I would like my build job to not build on specific teamcity agents and there is no common pattern for the build agent names. Is there a way I can isolate multiple agents from getting picked up by a single job.
For example I can make sure that the build job does not pick up 1 agent using the following parameter.
teamcity.agent.name
does not match
agent-001
How can I similarly tell the teamcity job to not run on the following agents as well.
"123-agent"
"my_agent"
"test_agent"
"agent_do_not_use"
I cannot use the same parameter, teamcity.agent.name with does not match for multiple agents.
Can you all teamcity experts help me out here please on what is the best way to achieve this.
You can add agent requirement with "does not match" condition which accepts regular expression and set it to:
123-agent|my_agent|test_agent|agent_do_not_use
Using an agent requirement based on presence (or absence) of a specific property coming from agent's buildAgent.properties file would probably be a better solution to using agent names in the requirement.
Alternative means to manage agent's compatibility are: use agent pools and use agent's Compatible Configurations set to a limited set.
You can add a specific parameter inside the agent configuration on the local machine inside: C:\BuildAgent\conf\buildAgent.properties
Then, you can add something specific like: system.Is<MyFeature>Available=True
Then, in teamcity configuration, you will add an Agent Requirement with this parameter.
I am using sonar false-positive feature in my project deployed on sonar server and i have marked some violation instances(lets 50 instances) as false positive.
Now i create a new project in sonar having the same code base and deploy it on sonar. As code base is same for both of my projects this is obvious that those "50" violation instances will occurs here also, which i have marked as false-positive in my previous project.
Now i dont want to spend time to mark these instances as false-positive again so i want to ask is there any way to mark these "5o" violation instances as false-positive by refering my first project without doing manually??
Can i make a template/profile type feature to copy false-positive marks from one project and apply it on other project having same code base so that i can save my time??
Kindly revert if anyone know any way to execute this.
Your response will be appreciable..
Thankks in advance!
It is not currently possible to achieve what you want, unless you write a small Java program that uses Sonar Web Service Java client and that does the job.
The only trick I found was to add a // NOSONAR comment on line containing the false positive.
This way, the information is shared among branches.
But, as the NOSONAR masks any sonar issue, you may miss another sonar issue as the one intended to mask.
Example:
var myVar; // NOSONAR