[JIRA] (JENKINS-38609) Shared libraries root to be specified in the PATH field

3 views
Skip to first unread message

martin.fousek@gmail.com (JIRA)

unread,
Sep 29, 2016, 11:17:01 AM9/29/16
to jenkinsc...@googlegroups.com
Martin Fousek updated an issue
 
Jenkins / Improvement JENKINS-38609
Shared libraries root to be specified in the PATH field
Change By: Martin Fousek
Summary: Shared libraries root to be specified as folder in the PATH field
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

jglick@cloudbees.com (JIRA)

unread,
Oct 4, 2016, 3:27:01 PM10/4/16
to jenkinsc...@googlegroups.com
Jesse Glick resolved as Won't Do
 

Do not plan to implement such a feature. Either create multiple repositories, one per library; or merge the contents of two libraries into one (it is fine for one library to have multiple global variables and many source packages).
Change By: Jesse Glick
Status: Open Resolved
Resolution: Won't Do

martin.fousek@gmail.com (JIRA)

unread,
Oct 6, 2016, 3:39:04 PM10/6/16
to jenkinsc...@googlegroups.com
Martin Fousek commented on Improvement JENKINS-38609
 
Re: Shared libraries root to be specified in the PATH field

Sorry, my initial explanation wasn't likely good enough. I'm not looking for placement more Global Libraries into one repository/branch. I would like to place my Global Library files next to the common Sources of the project and in this case you don't want to mix the structure. Let's imagine following example of project repo structure:
/src/org/sample/project/globals/BuildingUtils.groovy
/src/org/sample/project/services/NewsService.java
/src/org/sample/project/controllers/NewsController.java
/src/org/sample/project/pom.xml
....

I wanted to outline that mixing of Global Library source with the Project source is not desirable but moving the Globaly Library outside of the project's repository means that you need to handle all branches twice and do changes into two various repositories instead of straightforward change within single one (in that case you can just update pom.xml and BuildingUtils.groovy at one place, everytime together).

Of couse there could be subfolder for the project MVN project but still the top-level 'src' folder will be always confusing to everybody who takes a look on the project repository.

jglick@cloudbees.com (JIRA)

unread,
Oct 7, 2016, 4:41:01 PM10/7/16
to jenkinsc...@googlegroups.com

If you are not sharing the library code then you might as well use the load step (or readTrusted if it must happen prior to checkout).

martin.fousek@gmail.com (JIRA)

unread,
Oct 8, 2016, 1:25:01 AM10/8/16
to jenkinsc...@googlegroups.com

Sure, that's right and we are actually using the the <code>load</code> step in ongoing scripting but we incline to keep the inline script (in the definition of the job's Pipeline) as simple as possible. Usually it's only one line like this:
runJob(label: 'llg && slave', branch: constants.promotedBranch)

<code>runJob</code> is global method which wraps the run into try/catch/finally blocks, handles emails, ..., gets the script name equal to job name and starts processing. Of course we could enhance it here but we wanted to keep the unversioned part of the job definition as short as possible. Except this one helper method, we are using also <code>constants</code> there so that are already two loads here and we can't forget that this all requires SCM checkout so the structure wouldn't be really simple one line any more.

martin.fousek@gmail.com (JIRA)

unread,
Oct 8, 2016, 1:26:01 AM10/8/16
to jenkinsc...@googlegroups.com
Martin Fousek edited a comment on Improvement JENKINS-38609

martin.fousek@gmail.com (JIRA)

unread,
Oct 8, 2016, 1:26:06 AM10/8/16
to jenkinsc...@googlegroups.com
Martin Fousek edited a comment on Improvement JENKINS-38609
Sure, that's right and we are actually using the the <code> {{ load </code> }}
step in ongoing scripting but we incline to keep the inline script (in the definition of the job's Pipeline) as simple as possible. Usually it's only one line like this:

runJob(label: 'llg && slave', branch: constants.promotedBranch)

{{runJob}} is global method which wraps the run into try/catch/finally blocks, handles emails, ..., gets the script name equal to job name and starts processing. Of course we could enhance it here but we wanted to keep the unversioned part of the job definition as short as possible. Except this one helper method, we are using also {{constants}} there so that are already two loads here and we can't forget that this all requires SCM checkout so the structure wouldn't be really simple one line any more.

kutzi@gmx.de (JIRA)

unread,
Mar 5, 2018, 8:41:03 AM3/5/18
to jenkinsc...@googlegroups.com
kutzi commented on Improvement JENKINS-38609

I know that this has been closed as Won't Do, but I want to share an additional use case where this might be useful to have.
We like to have testing code and the code for the shared library related to the tests close together - i.e. in one repo.
The directory structure looks like this e.g.

src/main/java/<package_name>
src/main/resources/<package_name>
src/test/java/<package_name>

and so on.

If I add now the shared library to this it's like this

src/<package_name>
vars/

I.e. it 'taints' the global directory structure of the project

I'd rather more like it to be something like this:

src/pipeline/groovy
src/pipeline/vars
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

neelkush@gmail.com (JIRA)

unread,
Oct 4, 2018, 6:03:02 PM10/4/18
to jenkinsc...@googlegroups.com

I am facing similar issue as described above. We have src/main/groovy/<package_name> and src/test/groovy/<package_name>. But, I would like to point to src/main/groovy or update my classpath to use the correct directory. Have you found any solution or a workaround?

Thanks in advance.
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

DanaGoyette@gmail.com (JIRA)

unread,
Oct 8, 2018, 1:37:03 PM10/8/18
to jenkinsc...@googlegroups.com

Another reason the /vars location is bad: it breaks IDE classpaths.  I can't just set / as the source root if I also want stuff under /src to be counted as the classpath, so it's forced me to add a symlink: src/vars -> ../vars.  I'd much rather have the pipeline stuff follow standard maven project conventions (such as src/main/).

With the bug marked "won't do", I can't even select "vote for this issue".

n3v3rf411@gmail.com (JIRA)

unread,
Oct 11, 2018, 10:57:03 PM10/11/18
to jenkinsc...@googlegroups.com

I use the global-shared-library archetype at https://github.com/jenkinsci/archetypes and am wondering how to use this in Jenkins out-of-the-box without creating two repositories.

valters.meirens@gmail.com (JIRA)

unread,
Oct 15, 2018, 2:23:03 AM10/15/18
to jenkinsc...@googlegroups.com
Walter Meier updated an issue
 
Change By: Walter Meier
Attachment: 2018-10-15_09-22-12.png

valters.meirens@gmail.com (JIRA)

unread,
Oct 15, 2018, 2:26:03 AM10/15/18
to jenkinsc...@googlegroups.com
Walter Meier commented on Improvement JENKINS-38609
 
Re: Shared libraries root to be specified in the PATH field

For anyone interested in a workaround. I got a repo to work as a Jenkinsfile repo and as Shared Library, complete with jenkins-pipeline-unit and JUnit5 tests, by using Gradle.

Here's my build.gradle:

apply plugin: 'groovy'

group 'com.tieto'
version '1.0-SNAPSHOT'

sourceCompatibility = 1.8

sourceSets {
    main.groovy.srcDirs = ['src']
    test.groovy.srcDirs = ['test']
    vars.groovy.srcDirs = ['vars']
}

repositories { mavenCentral() }

String junitVersion = '5.3.1'
dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.4.12'
    testCompile (
            "org.junit.jupiter:junit-jupiter-api:$junitVersion",
            'com.lesfurets:jenkins-pipeline-unit:1.1',
    )
    testRuntimeOnly ("org.junit.jupiter:junit-jupiter-engine:$junitVersion")
}

test {
    useJUnitPlatform()
    testLogging.showStandardStreams = true
}

And here's how my repo is structured:

MironVeryanskiy@gmail.com (JIRA)

unread,
Feb 11, 2019, 7:11:01 PM2/11/19
to jenkinsc...@googlegroups.com
Miron Veryanskiy reopened an issue
 

This issue was marked closed in 2016.

Since the closure of this issue in 2016, it has been heavily requested in the comments.
Re-opening for reconsideration of the requested feature.
Change By: Miron Veryanskiy
Resolution: Won't Do
Status: Resolved Reopened

MironVeryanskiy@gmail.com (JIRA)

unread,
Feb 11, 2019, 7:11:02 PM2/11/19
to jenkinsc...@googlegroups.com

yizhuan.yu@gmail.com (JIRA)

unread,
Sep 17, 2019, 7:07:04 AM9/17/19
to jenkinsc...@googlegroups.com
Yizhuan Yu commented on Improvement JENKINS-38609
 
Re: Shared libraries root to be specified in the PATH field

I submitted a fix to this, and have made a pull request (checks passed, pending merge), 

https://github.com/jenkinsci/workflow-cps-global-lib-plugin/pull/84

In this attempted fix, I added a "Library base path" (libBasePath) to "Global Pipeline Libraries" configuration, which is a relative path, e.g. common/subprojects/sharedlibs/, that will be added to the library path so that the library will be loaded from "${libBasePath}/src/*/.groovy", "${libBasePath}/vars/.groovy", "${libBasePath}/vars/.txt", "${libBasePath}/resources/". If blank, the library will be loaded from default location under project root of code repository "src/*/.groovy", "vars/.groovy", "vars/.txt", "resources/". 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages