Is there a way to detect the platform (Window / Linux) in which the website is running by Groovy / Grails?
System.properties['os.name']
will return the name of the OS, e.g. "Windows XP". So if you want to figure out whether you're running on Windows or not, you could do something like:
if (System.properties['os.name'].toLowerCase().contains('windows')) {
println "it's Windows"
} else {
println "it's not Windows"
}
Alternatively, org.apache.commons.lang.SystemUtils (from the Apache commons-lang project) exposes some boolean constants that provide the same information as the code above, e.g.
SystemUtils.IS_OS_MAC
SystemUtils.IS_OS_WINDOWS
SystemUtils.IS_OS_UNIX
More specific constants such as these are also available
SystemUtils.IS_OS_WINDOWS_2000
SystemUtils.IS_OS_SOLARIS
SystemUtils.IS_OS_MAC_OSX
Or for short:
if (System.env['OS'].contains('Windows')){ println "it's Windows" }
Since Groovy provides a map access to getAt/putAt methods.
Related
I'm trying to conditionally set the jdk version to be used in a generic pipeline used over multiple applications.
This code works:
pipeline {
agent any
tools {
jdk 'AdoptOpenJDK 11'
}
However i would like something like this:
pipeline {
agent any
tools {
if (jdkVersion) {
jdk 'AdoptOpenJDK 11'
} else {
jdk 'AdoptOpenJDK 11'
}
}
The first jdk version should be variable, but to be sure that's not the problem I've kept those the same for both cases. However this code gives the following errors:
No tools specified # line 24, column 9.
tools {
That makes it seem like I can't use an if clause at this point, but what other options are there?
Not sure if this is the correct way to do this in jenkins, but at least it works. Define a variable beforehand, don't bother with a if/else in tools.
def jdkversion = configJdkVersion ? 'configJdkversion' : 'default jdk version'
pipeline {
tools {
jdk jdkversion
I am trying to disable S0ix sleep on Windows (As there's no way to force Windows to use S3 sleep, after the "CsEnabled" registry no longer works) and allow S0ix on Linux (S3 Sleep seems to be not working on Chromium OS). But I couldn't find a reliable way to tell what OS I am running in ACPI and patch in OpenCore. Something like doing the reverse of the following piece of code for disabling S3...
// AOAC
// Name (_S3, ......
// In config ACPI, _S3 to XS3
// Find: 5F53335F
// Replace: 5853335F
//
DefinitionBlock("", "SSDT", 2, "OCLT", "S3-Fix", 0)
{
External (XS3, IntObj)
If (_OSI ("Darwin"))
{
//
}
Else
{
Method (_S3, 0, NotSerialized)
{
Return(XS3)
}
}
}
//EOF
Of course there're _OS, _OSI and _REV methods in ACPI standard, but according to Linux kernel documentation, the Linux kernel is mocking itself up as Windows/Darwin. Though currently I could tell I am loading a Linux kernel, as Linux would return TRUE when querying if _OSI is Darwin. But what if I install Hackintosh in the future?
you might enter BIOS setup menu to take a look
I want to list all available plugins names and their short names using command line option, so that I could automate required plugin installation through jenkins command line.
Kindly advise. Thanks
So far I tried to find answer on same however I got answer only for how to list installed plugins, not for all available plugins.
I've found this link http://updates.jenkins-ci.org/download/plugins/ which lists all plugins but with their short names only
You were so close! The LAYOUT is detailed here. The information is nearby for you to parse, hopefully I got it right.
http://updates.jenkins-ci.org/download/plugins/ is indeed the location of the plugins, with the actual plugin versions sitting inside each folder.
https://updates.jenkins.io/ is the root level. You will find the list of all plugins and details at plugin-versions.json.
update-center.js, update-center.json, and update-center.json.html contain actual update center metadata in JSON, JSONP, and HTML format respectively. You can parse the json to pull everything you are looking for. There are also lists for the documentation url and the release history, as well as the updates.
This is where it's nuanced; there's stable (ie:LTS) or latest (ie:weekly) and major releases of each. Each one has its own sublist, depending on minimum version and compatibility.
Plugin Selection
Since none of this tells you what the plugins actually do, the best thing is to choose your plugins at https://plugins.jenkins.io/. Clicking on any plugin (eg: mailer) reveals a header block with details:
Mailer 1.23
Minimum Jenkins requirement: 1.642.3
ID: mailer
The ID is the short name you are looking for. Go through and find the plugins you want to use and that's your list. Don't worry about the dependencies.
About Plugin Management
Even on a standalone instance, I use a modified script of Docker install_plugins.sh to generate the full list of plugins to install .
Update 2021: As part of GSOC 2019 and refined in GSOC 2020, a new and quite functional Plugin Installation Manager CLI Tool has been introduced to replace all non-GUI plugin mgmt tools, including inatall_plugins.sh. Achieves similar results.
You can examine the outputs or use the groovy script that follows to simplify your "must have" list. Also, as dependency updates happen all the time, I also generate a list of actual installed updates if I need to reapply identically to a different instance rather than from my curated list. My curated list is ~45 plugins, with over 115 getting installed.
eg: workflow-api includes [workflow-scm-step] which includes [git, subversion], so no need to specify git. But you want to know which version you got. Occasionally you may need to explicitly add a dependency to get the latest to avoid a defect, per JENKINS-54018, plugins which were split from Jenkins.
println "Jenkins Instance : " + Jenkins.getInstance().getComputer('').getHostName() + " - " + Jenkins.getInstance().getRootUrl()
println "Installed Plugins: "
println "=================="
Jenkins.instance.pluginManager.plugins.sort(false) { a, b -> a.getShortName().toLowerCase() <=> b.getShortName().toLowerCase()}.each { plugin ->
println "${plugin.getShortName()}:${plugin.getVersion()} | ${plugin.getDisplayName()} "
}
println""
println "Plugins Dependency tree (...: dependencies; +++: dependants) :"
println "======================="
Jenkins.instance.pluginManager.plugins.sort(false) { a, b -> a.getShortName().toLowerCase() <=> b.getShortName().toLowerCase()}.each { plugin ->
println "${plugin.getShortName()}:${plugin.getVersion()} | ${plugin.getDisplayName()} "
println "+++ ${plugin.getDependants()}"
println "... ${plugin.getDependencies()}"
println ''
}
return
If I use cucumber.api.groovy.Hooks.World then tests are working fine. But I cannot open declaration in steps definition
World() {
def world = new LucieWorld()
world.metaClass.mixin Lucie
world
}
step definition:
Given(~/^User is (.+)$/) { def username ->
login(username) //I cannot open declaration here
}
When I am in a step definition file (groovy), Intellij can't seem to see variables and methods defined in the cucumber "World" object Lucie. So don't get IDE support (auto-complete, etc) for those which is a bit annoying. How can I fix that?
I try to use this.metaClass.mixin(Lucie) in step definition, but I think, that this is not a good solution.
How can I start a process in mono using the Process.Start API? My best guess would be the following (in F#):
let start (path : string) =
System.Diagnostics.Process.Start("/usr/bin/env", sprintf "mono \"%s\"" path)
This seems to work in linux, but it is obviously not correct in Mono/Windows. Is there any way I could obtain the location of the mono executable programmatically?
It turns out that you can basically just Process.Start with just the target executable path, no need to specify the mono executable.
You can find the location of Mono on windows using the following registry keys
$version = HKLM_LOCAL_MACHINE\Software\Novell\Mono\DefaultCLR
$monoprefix = HKLM_LOCAL_MACHINE\Software\Novell\Mono\$version\SdkInstallRoot
where you use the version you found to find the mono prefix.
Taken from this page
Rather than starting a new instance of the CLR, you can start assemblies from within your existing instance. Microsoft documents the relevant functionality here: http://msdn.microsoft.com/en-us/library/yk22e11a%28v=vs.110%29.aspx. Mono implements this as well.
What you have to do is create a new AppDomain to provide you with an execution environment isolated from your current one, load an assembly in there, and execute it.
Example:
var domain = AppDomain.CreateDomain("Foo");
domain.ExecuteAssembly("Bar.exe");