I am trying to import multiple jenkins libraries in a Jenkinsfile, but I've come across the issue of "what if both libraries share a function?" For example, if I have library A and library B, and both of those libraries have function helloWorld, how would I properly differentiate those two functions in the Jenkinsfile?
Let's assume I am importing the libraries like this:
#!groovy
import ...
import ...
import ...
library identifier: 'A#master', retriever: modernSCM(
[$class: 'GitSCMSource',
remote: '<the github link for A>'])
library identifier: 'B#master', retriever: modernSCM(
[$class: 'GitSCMSource',
remote: '<the github link for B>'])
// rest of the jenkinsfile
How would I be able to use the helloWorld function from both libraries? Is there a way to call A.helloWorld and B.helloWorld in this Jenkinsfile?
edit: helloWorld in this example would be from the vars folder. I'd like to call the same function even when it exists in both libraries' vars folder.
According to Jenkins Shared Libraries documentation, in the §Loading Libraries Dynamically section you can find you can assign a loaded library into a variable, then you can use the variable as a qualifier:
def A = library identifier: 'A#master', retriever: modernSCM(
[$class: 'GitSCMSource', remote: '<the github link for A>']
)
def B = library identifier: 'B#master', retriever: modernSCM(
[$class: 'GitSCMSource', remote: '<the github link for B>']
)
A.helloWorld()
B.helloWorld()
Related
I have constructed a Shared Library in which I want to have class definitions, below is the example shared lib code.
package api
class api implements Serializable {
private final Map data
private final DSL steps
api(Map data, DSL steps) {
this.data = data
this.steps = steps
}
}
I have placed this class definition in a shared library git repo, with the path api/src/api/api.groovy. I am importing the shared library using the following step at the top of my jenkinsfile, outside any node or pipeline directive:
library identifier: 'api#master', retriever: modernSCM(
scm: [
$class: 'GitSCMSource',
credentialsId: '<my-credentials-id>',
remote: '<my-git-remote>',
traits: [gitBranchDiscovery()]
],
libraryPath: 'api/'
)
import api.*
When I use the above class from the shared library it's throwing an exception saying that the class is not found.
WorkflowScript: 75: unable to resolve class api
# line 75, column 29.
api foo = new api(env.data, steps)
^
at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:309)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:981)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:626)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:575)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:323)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:293)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox$Scope.parse(GroovySandbox.java:163)
at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:142)
at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:127)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:562)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:514)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:336)
at hudson.model.ResourceController.execute(ResourceController.java:107)
at hudson.model.Executor.run(Executor.java:449)
Finished: FAILURE
As i read in the doccument that loading library dynamically does not import classes directly to the pipeline's classpath.
So need a little help to get this class into my job execution.
Note: I have tested it and it's working when adding the global libraries under jenkins global settings, however i want this library setting to be dynamic from jenkins file.
below error pops when I try to target a CDK pipeline using events targets.
jsii.errors.JavaScriptError:
Error: Resolution error: Supplied properties not correct for "CfnRuleProps"
targets: element 0: supplied properties not correct for "TargetProperty"
arn: required but missing.
code is below
from aws_cdk import (
core,
aws_codecommit as codecommit,
aws_codepipeline as codepipeline,
aws_events as events,
aws_events_targets as targets
)
from aws_cdk import pipelines
from aws_cdk.pipelines import CodePipeline, CodePipelineSource, ShellStep
class BootStrappingStack(core.Stack):
def __init__(self, scope: core.Construct, construct_id: str, **kwargs) -> None:
super().__init__(scope, construct_id, **kwargs
repo = codecommit.Repository(
self, 'Repository',
repository_name='Repository'
)
source_artifact = codepipeline.Artifact()
cloud_assembly_artifact = codepipeline.Artifact()
pipeline = CodePipeline(self, 'Pipeline',
synth=ShellStep("Synth",
input=CodePipelineSource.code_commit(
repository=repo,
branch='master'),
commands=[
'pip install -r requirements',
'npm install -g aws-cdk',
'cdk synth']
)
)
rule = events.Rule(self, 'TriggerPipeline',
schedule=events.Schedule.expression('rate(1 hour)')
)
rule.add_target(targets.CodePipeline(pipeline))
The documentation for aws_cdk.events_targets works with codepipeline construct, however doesn't work as documented for cdk pipelines.
This needs to be addressed in the documentation, once I get to know what's the fix. Please help.
As mentioned by #Otavio, you need to use the codepipeline.IPipeline.
You can use the pipeline property from CDK CodePipeline construct but in order to use that first you need to construct the pipeline using build_pipeline() method:
pipeline = CodePipeline(self, 'Pipeline',
synth=ShellStep("Synth",
input=CodePipelineSource.code_commit(
repository=repo,
branch='master'),
commands=[
'pip install -r requirements',
'npm install -g aws-cdk',
'cdk synth']
)
)
# You need to construct the pipeline before passing it as a target in rule
pipeline.build_pipeline()
rule = events.Rule(self, 'TriggerPipeline',
schedule=events.Schedule.expression('rate(1 hour)')
)
# Using the pipeline property from CDK Codepipeline
rule.add_target(targets.CodePipeline(pipeline.pipeline))
The problem is that targets.CodePipeline receives a codepipeline.IPipeline as a parameter. But what you are using instead is a pipelines.CodePipeline, which is a different thing. CodePipeline is more abstract construct, built on top of the codepipeline module.
You can try this:
const pipeline = new CodePipeline(self, 'Pipeline' ....
Then:
rule.addTarget(new targets.CodePipeline(pipeline))
I want to make my already existing Cocoapods available also as Swift Package.
Here's the thing. One of my pods depending on another, so I added this to my Swift package :
// swift-tools-version:5.0
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "Luminous",
products: [
// Products define the executables and libraries a package produces, and make them visible to other packages.
.library(
name: "Luminous",
targets: ["Luminous"]),
],
dependencies: [
// Dependencies declare other packages that this package depends on.
// .package(url: /* package url */, from: "1.0.0"),
.package(
url: "https://github.com/andrealufino/Deviice.git",
from: "1.30.2"
)
],
targets: [
// Targets are the basic building blocks of a package. A target can define a module or a test suite.
// Targets can depend on other targets in this package, and on products in packages this package depends on.
.target(
name: "Luminous",
dependencies: [],
path: "Sources"),
.testTarget(
name: "LuminousTests",
dependencies: ["Luminous"]),
]
)
My other question is : why the Example folder is included when the package is installed? Here's the pic.
Moreover, last thing, when I build my project in which I added the package, it fails because it cannot find the module for the dependency. The error is No such module Deviice.
I think I added enough details, if you need more, just ask.
I'll answer about the Deviice not found. The other issues are about local paths.
You can see your package as such (In the next comment, "Package" can be understood as library, but also as an executable, for tests purpose often in the case of "sub packages", or "real executables".
let package = Package(
name: "Luminous", // Name of your package
products: [], // What packages people will see relying on internal sub-packages
dependencies: [], // External packages you relies on
targets: [] // Internal "sub-packages", etc.
)
Each target has a dependencies: [], that's where you put the name of either other targets (which are "internal", or public one, that you stated before in dependencies[].
.target(
name: "Luminous",
dependencies: [], //Put here names of either sub packages OR public package you "called before"
path: "Sources")
In your case:
.target(
name: "Luminous",
dependencies: ["Deviice"],
path: "Sources")
Indeed you wrote yourself:
.testTarget(
name: "LuminousTests",
dependencies: ["Luminous"])
So you stated that it depends on the sub package "Luminous", same logic here with Deviice.
You can use as an example the Package of Alamofire+Image. It uses as an external dependency Alamofire, and put it as such.
I'm trying to specify the GithubProjectProperty in a Jenkins Multibranch pipeline. I've been unsuccessful attempting to set an entry in the option block to control this value.
The pipeline syntax snippet generator suggests:
properties([
$class: 'GithubProjectProperty',
displayName: '',
projectUrlStr: 'https://myServer/myOrg/myRepo'
])
None of the following appear to work:
1) Try to put the properties directly in the options block
options {
// Set the URL for the GitHub project option
properties([
$class: 'GithubProjectProperty',
displayName: '',
projectUrlStr: 'https://myServer/myOrg/myRepo'
])
}
ERROR: The ‘properties’ section has been renamed as of version 0.8. Use ‘options’ instead
2) Remove the properties keyword but leave the option in the options block
options {
// Set the URL for the GitHub project option
[
$class: 'GithubProjectProperty',
displayName: '',
projectUrlStr: 'https://myServer/myOrg/myRepo'
]
}
ERROR: Options cannot be defined as maps
3) Treat the GitHubProjectProperty as if it can be instantiated (like office365ConnectorWebhooks)
options {
// Set the URL for the GitHub project option
GithubProjectProperty('https://myServer/myOrg/myRepo')
}
ERROR: Invalid option type "GithubProjectProperty". Valid option types: [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, office365ConnectorWebhooks, overrideIndexTriggers, parallelsAlwaysFailFast, preserveStashes, quietPeriod, rateLimitBuilds, retry, script, skipDefaultCheckout, skipStagesAfterUnstable, timeout, waitUntil, warnError, withContext, withCredentials, withEnv, ws]
4) Treat the GitHubProjectProperty as if it can be instantiated but inside a script block (because script is supposed to be valid according to attempt #3)
options {
script {
// Set the URL for the GitHub project option
GithubProjectProperty('https://myServer/myOrg/myRepo')
}
}
ERROR: Options definitions cannot have blocks
The office-365-connector-plugin is a working plugin that is supported in the options block of a Jenkinsfile. I compared its code with the github-plugin source on GitHub and noticed the following line:
#Extension
public static final class DescriptorImpl extends JobPropertyDescriptor {
The code is lacking a #Symbol directive that the office365ConnectorWebhooks appears to provide in its code:
#Extension
#Symbol("office365ConnectorWebhooks")
public final class WebhookJobPropertyDescriptor extends JobPropertyDescriptor {
Is there some special syntax to use to add the GitHub URL to a multibranch pipeline or does that plugin just not support managing it through a Jenkinsfile?
The ability to specify options in a pipeline using a Jenkinsfile requires a Symbol. There is a proposed fix in the Jenkins github-plugin that adds the necessary Symbol directive but it is not currently part of the plugin as of version 1.30.0.
See: https://issues.jenkins-ci.org/browse/JENKINS-62339
It's possible for a developer to build their own updated plugin in the meantime by updating the following file:
src/main/java/com/coravy/hudson/plugins/github/GithubProjectProperty.java in the source found at: https://github.com/jenkinsci/github-plugin
Add the Symbol:
import org.jenkinsci.Symbol;
...
#Extension
#Symbol("githubProjectProperty")
public static final class DescriptorImpl extends JobPropertyDescriptor {
...
And for good measure, make sure the code specifies the correct function signature for newInstance:
#Override
public JobProperty<?> newInstance(#Nonnull StaplerRequest req, JSONObject formData)
throws Descriptor.FormException {
The updated plugin may be installed by a Jenkins admin using the Advanced option in the Plugin Manager to upload an .hpi file from outside the central plugin repository
I had the same problem and was able to solve it with:
options{
githubProjectProperty(displayName: '', projectUrlStr: 'your_project_url')
}
How can I update a jira issue from within a Jenkinsfile (jenkins-worflow/pipeline)?
Is there a way I could use the Jira Issue Updater plugin as a step in the Jenkinsfile?
I know I could use the Jira RestAPI, but I'm trying to figure out if I can re-use the functionality provided by the jira-updater-issue.
What I'm looking for is a something similar to the example below calling Junit archiver, and atifact archiver, but calling jira updater.
node {
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
def mvnHome = tool 'M3'
sh "${mvnHome}/bin/mvn -B -Dmaven.test.failure.ignore verify"
step([$class: 'ArtifactArchiver', artifacts: '**/target/*.jar', fingerprint: true])
step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
}
The Jira Plugin is compatible with Pipeline.
This should work:
step([$class: 'hudson.plugins.jira.JiraIssueUpdater',
issueSelector: [$class: 'hudson.plugins.jira.selector.DefaultIssueSelector'],
scm: [$class: 'GitSCM', branches: [[name: '*/master']],
userRemoteConfigs: [[url: 'https://github.com/jglick/simple-maven-project-with-tests.git']]]])
You can get a full reference in the built-in Pipeline Snippet Generator.
The JIRA Steps Plugin provides a more declarative way to update an existing Jira Ticket:
node {
stage('JIRA') {
# Look at IssueInput class for more information.
def testIssue = [fields: [ // id or key must present for project.
project: [id: '10000'],
summary: 'New JIRA Created from Jenkins.',
description: 'New JIRA Created from Jenkins.',
customfield_1000: 'customValue',
// id or name must present for issuetype.
issuetype: [id: '3']]]
response = jiraEditIssue idOrKey: 'TEST-01', issue: testIssue
echo response.successful.toString()
echo response.data.toString()
}
}
Since you would like to use the Jenkinsfile to define your pipeline, that should be the preferred way for you to go...
As this was way harder for me than it should be, here is a working example. This will update a custom field of a ticket with a specific value:
step([$class: 'IssueFieldUpdateStep',
issueSelector: [$class: 'hudson.plugins.jira.selector.ExplicitIssueSelector', issueKeys: ticket],
fieldId: field,
fieldValue: value
])
The snippet generator did not work for me. The variables ticket, field and value are all strings. Starting from this you can look for options here: https://www.jenkins.io/doc/pipeline/steps/jira/
Yes, seems like this page answers your question:
https://wiki.jenkins-ci.org/display/JENKINS/Jira+Issue+Updater+Plugin
After you install the plugin, add a build step, or pre/post build step to call this plugin
There you can give it the REST URL to your Jira server, the creds and the JQL to find the issues