I'm trying to update Jenkins' root URL via the Groovy API, so I can script the deployment of a Jenkins master without manual input (aside: why is a tool as popular with the build/devops/automation community as Jenkins so resistant to automation?)
Based on this documentation, I believe I should be able to update the URL using the following script in the Script Console.
import jenkins.model.JenkinsLocationConfiguration
jlc = new jenkins.model.JenkinsLocationConfiguration()
jlc.setUrl("http://jenkins.my-org.com:8080/")
println(jlc.getUrl())
Briefly, this instantiates a JenkinsLocationConfiguration object; calls the setter setUrl with the desired value, http://jenkins.my-org.com:8080/; and prints out the new URL to confirm that it has changed.
The println statement prints what I expect it to, but following this, the value visible through the web interface at "Manage Jenkins" -> "Configure System" -> "Jenkins URL" has not updated as I expected.
I'm concerned that the value hasn't been update properly by Jenkins, which might lead to problems when communicating with external APIs.
Is this a valid way to fix the Jenkins root URL? If not, what is? Otherwise, why isn't the change being reflected in the config page?
You are creating a new JenkinsLocationConfiguration object, and updating the new one, not the existing one being used
use
jlc = JenkinsLocationConfiguration.get()
// ...
jlc.save()
to get the one from the global jenkins configuration, update it and save the config descriptor back.
see : https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/model/JenkinsLocationConfiguration.java
Related
We are trying to setup a workflow for delivering content model changes to our other environments (stage & prod).
Right now, our approach is this:
Create a new contentful field as a migration script using Contentful CLI.
Run script in local dev to make sure the result is as desired using contentful space migration migrations/2023-01-12-add-field.ts
Add script to GIT in folder migrations/[date]-[description].js
When release to prod, run all scripts in the migrations folder, in order, as part of the build process.
When folder contains "too many" scripts, and we are certain all changes are applied to all envs, manually remove the scripts from GIT and start over in an empty folder.
Where it fails
But, between point 4 & 5 there will be cases where a script has already been run in an earlier release, and that throws an error:
I would like the scripts to continue more gracefully without throwing an error, but I cant find support for it in the space migration docs. I have tried wrapping the code in try/catch without any luck.
Contentful recommends using the Content Migration API in favour for Content Management API since it is faster. I guess we could use the Content Management API, but at the same time we want to use "best practise".
Are we missing something here?
I would like to do something like:
module.exports = function (migration) {
// Create a new category field in the blog post content type.
const blogPost = migration.editContentType('blogPost')
if (blogPost.fieldExists('testField')) {
console.log('Field already exists')
} else {
blogPost.createField('testField').name('Test field').type('Symbol')
}
}
for my current site I have a content type that stores a user in an entity reference field. I want to allow the user referenced in this field to edit the data of that node. In drupal7 I would do that with a node_access hook - which I am not getting to work in drupal8.
Here is a demo code of my hook - for testing purposes I want to forbid everything. However it is never called, and no - I am not logged in as user1. Also reseted cache, uninstalled and installed the module again and rebuilt the permissions - nothing seems to make this hook work.
function mymodule_node_access(\Drupal\node\NodeInterface $node, $op, \Drupal\Core\Session\AccountInterface $account) {
$access = new AccessResultForbidden();
return $access;
}
My question is why is this hook never called - and if there is now with drupal 8 a better way to do so?
Any help will be appreciated.
Best regards,
Rambazamba
This hook is never called for user 1, since he bypasses every access control.
Try testing anonymously or as another role.
Try the following command. The tool 'drupal console' is required.
drupal node:access:rebuild
I'm trying to run a SoapUI test-suite against two different endpoints and I do this by triggering two testrunner command and supply two different "-e" argument values.
The problem is that each of my test cases uses one API that I am testing, for which I do need to use the endpoint that is being passed under -e argument, and another API that should remain static. (The 2nd API is a helper API which sets up the environment for the first API to be able to work). So if I use the -e argument it breaks my tests because it forces the 2nd API to the same endpoint as the first API.
What I've tried so far is using the following groovy script to force endpoint value for specific Test Steps, however it's being ignored or maybe the script runs before the endpoints gets set, I'm not sure.
TestSuite setup script:
def testCases = testSuite.getTestCaseList()
for(testCase in testCases)
{
def testSteps = testCase.getTestStepList()
for(testStep in testSteps)
{
if(testStep.name == "my name")
{
testStep.setPropertyValue('endpoint','http://force.it');
}
}
}
What else can I do to overcome this issue to avoid duplicating my tests?
If you're right seems that e argument overrides all endpoints inclusive the ones you set in the setup script.
Then I purpose the follow approach for your case. SOAPUI as probably you already know has properties at different levels (testSuite, testCase, project, global) and you can use this properties to share information between your tests.
The thing is that you can use this properties to set your endpoints and pass the properties values in the testrunner command.
Set the endpoint for all your test request which test your 1st API using a global property:
${#Project#endpointAPI1}
And for the 2nd API set the endpoint url as:
${#Project#endpointAPI2}
Note: If you don't want to set the endpoints one by one you can use a groovy script testStep similar to the one you show in your question.
Once this is set, then you can invoke the testrunner for your both cases using the properties:
Then to test your cases you can add the follow properties, with -P properties are added at project level.
First endpoint for api1
-PendpointAPI1=http://one_endpointAPI1.com -PendpointAPI2=http://endpointAPI2.com
Second endpoint for api1
-PendpointAPI1=http://second_endpointAPI1.com -PendpointAPI2=http://endpointAPI2.com
Note that I use also a variable for endpoint API2 however if this is static and not change between both tests instead of using ${#Project#endpointAPI2} you can set directly the url for this service and pass only the property -PendpointAPI1.
Hope it helps,
Is there a way to find out who started a build in jenkins using java. I understand that below is the approach for figuring out as to who started a build
import hudson.model.*
import jenkins.security.*
def userBuild
for(hudson.model.Cause cause : build.causes) {
userBuild = cause.getUserName()
}
println "Build Started by: "+userBuild
Likewise, can someone please let me know if there is a similar working way to figure out as to who initiated a jenkins build?
Ther is a Plugin that injects the informations in Build Variables.
https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin
BUILD_USER – full name of user started build,
BUILD_USER_FIRST_NAME – first name of user started build,
BUILD_USER_LAST_NAME – last name of user started build,
BUILD_USER_ID – id of user started build.
Maybe this is an option for you.
Was able to figure it out on my own. Added the below changes in buildCaption.jelly so that only the user who started the build will be able to abort the build. Mind that this change only gets reflected in the console-output of a build, but there are other places(such as jenkins landing page and job home page) where the abort button gets displayed and will have to make the changes accordingly
<j:forEach var="cause" items="${it.causes}">
<j:if test="${cause.userName == it.currentlyLoggedInUser}">
<l:stopButton href="stop" alt="[${%cancel}]"/>
</j:if>
</j:forEach>
What is the script to update deployment ( from GUI, we can do this update by unlock & save changes ) in linux. Is it possible to do this ? If not what is script to redeploy ?
As Kevin pointed out, WLST is the way to go. You should probably craft a script (named wlDeploy.py, for instance), with content like follows (import clauses were omitted for the sake of simplicity):
current_app_name = '[your current deployed app name]'
new_app_name = '[your new app name]'
target_name = '[WL managed server name (or AdminServer)]'
connect([username],[pwd],'t3://[admin server hostname/IP address]:[PORT]')
stopApplication(current_app_name)
undeploy(current_app_name, timeout=60000);
war_path = '[path to war file]'
deploy(appName=new_app_name, path=war_path, targets=target_name);
And call it via something like:
./wlst.sh wlDeploy.py
Of course you can add parameters to your script, and a lot of logic which is relevant to your deployment. This is entirely up to you. The example above, though, should help you getting started.
In WebLogic you can use wlst to perform administrative tasks like managing deployments. If you google weblogic wlst, you will receive tons of information. wlst runs on the python language.
Assuming you are using weblogic 10 you can also "Record" your actions. This will save the actions into a python script which you can "replay" (execute) later.