Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jackie Weng
    @jemerald

    I'm currently trying to configure the multibranch pipeline to auto build branches, PRs, and tags.
    While branches and PRs builds fine, the tags doesn't seems to trigger auto-build. Here' the multibranch pipeline log:

    Checking tag test-tag2 from <my-repo>
    ‘pipeline_config.groovy’ found
    Met criteria
    Changes detected: test-tag2 (null → 98aa7a282ac0b30a4a3015be52de0867edc47aa5)
    No automatic build triggered for test-tag2

    ah, nevermind, it's not JTE related
    steven-terrana
    @steven-terrana
    @Vince-Cercury - currently you can’t specify libraries at the indiviudal Pipeline Job level. you would need to either add the libs globally in Manage Jenkins > Configure System > Jenkins Templating Engine or create a Folder for the pipeline job to be in and then add the libs to this new Folder.
    Vincent Brouillet
    @Vince-Cercury
    Ok thanks
    Vincent Brouillet
    @Vince-Cercury
    Is there a doc or example jobdsl for pipelineJob
    I'm getting an error providePipelineTemplate and providePipelineConfig must be specified
    If I look at api doc, the example shows how to load a normal Jenkins file
    Vincent Brouillet
    @Vince-Cercury

    I'm trying to do it inline, without scm

    But reading above, has a ticket been created for "regular pipeline jobs + JTE from SCM?"

    I'm trying to use readFileFromWorkspace

    definition{
    templateFlowDefinition{
    template(readFromWorkspace('Jenkinsfile')
    pipelineConfig(readFromWorkspace('path-to-pipeline_config.groovy')
    }
    }
    But getting various error. Looking at the XML generated if configuring from Jenkins UI to try to convert to JobDsl

    Vincent Brouillet
    @Vince-Cercury
    ok I got it now.
    So should I create a ticket to make it read from scm?
    steven-terrana
    @steven-terrana

    @Vince-Cercury i’ve created jenkinsci/templating-engine-plugin#100 that i believe captures this use case.

    feel free to comment on the issue if i didn’t appropriately capture the feature request!

    Mahendranath Rekapally
    @getmahen

    Hi @steven-terrana.

    We are using Bitbucket server. Running into an issue with JTE plugin NOT obtaining the pipeline_config.groovy file in the App's repo for Pull Requests but it is obtaining pipeline_config.groovy file from the Governance repo. Here is the issue description:

    Issue description:
    Let say I have a Pull Request (PR) from branch A to master branch. Both branches have pipeline_config.groovy in root directory. But when the PR triggers Jenkins build, templating engine doesn't obtain pipeline_config.groovy of any branch, it only obtains pipeline_config.groovy in Governance repo

    If the build is triggered by branch commit, then templating engine works fine (obtain pipeline_config.groovy in both source repo and Governance repo and merges it) - This works fine!
    I see there are issues reported already on this. Would like to know if you are actively working on a fix for this OR if there is a workaround I can use to make this work.

    steven-terrana
    @steven-terrana

    @getmahen - i am looking into a fix for this but i can’t make any promises on timeline.

    In the meantime, a work around would be to create a governance tier that points to the repository’s pipeline_config.groovy file.

    Not super convenient, but would work around the issue.

    JoshD
    @jd0x
    Hello, is there a migration guide for > 1.6 ?
    When I did a migration on my test instance, it caused the configurations to disappear in the console.
    cc: @steven-terrana
    JoshD
    @jd0x
    re: ⚠️ this upgrade introduces a new feature that changes the JTE configuration in the Jenkins Console. This means that existing Job DSL scripts or the like will need to be updated accordingly.” from release notes.
    steven-terrana
    @steven-terrana

    hey @jd0x - are you using job DSL to create your jobs?

    the primary difference from 1.6+ is that Governance Tiers now have a dropdown to specify if you want to define the configuration information from SCM or in the Jenkins Console.

    If you select “From SCM” the configuration to fill out is the same as pre 1.6

    JoshD
    @jd0x
    GM @steven-terrana - negative, we are using Jenkinsfiles and pipeline_config's running code in lib sources. It is failing to run the pipeline, were there syntax changes elsewhere? Might be that I need to update the SCM configuration in the Console
    steven-terrana
    @steven-terrana

    if there are specific error messages you can share i oughta be able to help.

    if you’re getting a message about a method not being defined or whatever it’s probably an SCM configuration needed to fetch the libs & set the configuration file

    JoshD
    @jd0x
    ah - that sounds about right. I have my jobs defined as Multi-branch Jobs with the JTE configuration option. When I performed the upgrade it looks like it caused the configurations in the console to change resulting in the error:
    [Pipeline] End of Pipeline
    org.boozallen.plugins.jte.config.TemplateConfigException: Could not determine pipeline template.
    Is it a matter of updating the SCM configurations in the console to fix this?
    steven-terrana
    @steven-terrana
    yeah
    would need to reconfigure that Governance Tier to pull from the same place it used to.
    JoshD
    @jd0x
    Great! Thank you so much, I’ll be performing our teams uprade later this evening.
    In the console, we only configure a pipeline configuration and library source.
    I don’t think we are using the governance tier? unless that is the library source
    alethcoe
    @alethcoe

    I'm having issues in my organization trying to get deploy_to to work.
    I have tried some items mentioned in other threads but no luck so far.

    my pipeline configuration in the jenkins template has
    template_methods{
    deploy_to
    }

    pipeline_config.groovy looks like
    application_environments{dev{stuff}}
    stages{
    functional_testing{
    deploy_to dev
    }
    }

    My library i stole basically from your github already so it is pretty much empty
    deploy_to.groovy
    void call(app_env){
    stage "Deploy to ${app_env.lng_name}", {}
    }

    But it blows up with No ginature of method: org.boozallen.plugins.jte.binding.injectors.ApplicationEnvironment.call() is applicable for argument types, Possible solutions: wait(), any()...

    I have coded about 12 other steps, i have github, build, test and other custom steps but this one is not working probably because it is the first to take in arguments this way? Is there something that is configured wrong?

    alethcoe
    @alethcoe
    would there possible be a missing import?
    steven-terrana
    @steven-terrana

    hey @alethcoe - the issue is that you can’t pass an argument to the step via the pipeline_config.groovy

    if you’re insistent on passing an argument to a step that’s captured in a JTE stage you’ll need to use the autowired stageContext variable. within the library step you can access stageContext.args which will return an array of the arguments passed to the stage.

    so your pipeline config would be:

    application_environments{ dev { stuff } }
    stages{
      functional_testing{
        deploy_to 
      }
    }

    and then your pipeline template can be:

    functional_testing dev

    and then in your deploy_to step you’d access the arguments passed to functional_testing via stage_context.args

    alethcoe
    @alethcoe
    so i'm a little confused. So I can only define steps that pass parameters in the jenkinsfile? Anything that would use an application_environment would need to be defined in jenkins? When i moved over to the jenkins file to call the step i got Cannot get property 'long_name' on null object. Do the application_environments also need to be defined in the jenkins file? if so i might need to do something completely different
    alethcoe
    @alethcoe
    I figured it out thank you for your help. I just needed to allow merge in my Library_Config so my groovy_config could define them. I should be able to continue now that I got it executing thank you for the explanation.
    steven-terrana
    @steven-terrana
    thanks for reaching out! always happy to help :)
    Chris Bolton
    @Gl4di4torRr

    @steven-terrana with the latest JTE, can we pass in resources?
    For example,

    gradle/
       build.groovy
       resources/
             scripts/
                 myscript.sh
             files/
                 myfile.json

    When the build.groovy is executed, the resources will be available at runtime.

    steven-terrana
    @steven-terrana
    not yet - i’m actually about to start work on that feature and it’ll be available when 2.0 is released
    Chris Bolton
    @Gl4di4torRr
    Okay, cool! Do you have a github issue?
    steven-terrana
    @steven-terrana
    Chris Bolton
    @Gl4di4torRr
    Thank you!
    Daniel Fullarton
    @linead
    Is the library order loading from the reverse hierarchy order by design? for example if I have a library defined in the main config of jenkins and then the same library available within the folder source it loads the library in the folder instead.
    steven-terrana
    @steven-terrana

    that is by design but it’s easy enough to change that we could probably make it configurable on the global plugin settings page.

    the idea was that the more granularly defined version of the library should take precedence in case a team wished to use a different implementation of the library.

    or in larger organizations, if they wanted to test a different branch while updating hte library before merging that into a version used by the entire organization.

    make a checkbox under an Advanced Settings tab that says “allow library overriding by folder library sources”
    Syed Schoaib
    @Schoaib
    Hi @steven-terrana , wanted to check with you on the possibility of having yaml file as a pipeline config in the user repository instead of having pipeline_config.groovy? what are your thoughts on this?
    steven-terrana
    @steven-terrana

    that’s definitely possible. The reason we went with a custom DSL for the configuration file was purely to avoid some of the pitfalls of YAML.

    I was getting a bit too many questions about folks running into syntax issues in YAML around whitespace and arrays and so on and so forth.

    but that was prior to open sourcing JTE.

    at this point - i don’t see why not. after the v2.0 scope gets wrapped up, it would be possible to customize the file that’s going to be read for the pipeline configuration and then have a YAML parser vs our existing DSL parser for the pipeline configuration

    Chris Bolton
    @Gl4di4torRr
    @steven-terrana
    If I have two libs A and B where A has a call()function with some reusable code, can a function in B call A?
    A/
         a.groovy // reusable code across libs
    B/
        b.groovy // wants to use the code in A.
    steven-terrana
    @steven-terrana
    yes
    Chris Bolton
    @Gl4di4torRr
    Cool. Just making sure.
    steven-terrana
    @steven-terrana

    haha sorry for the short answer but there wasn’t much else to say :)

    that’s a common pattern i use as well, having a centralized helper library that does some common tasking across the libs

    Chris Bolton
    @Gl4di4torRr
    Yeah, I did some searching and I saw your helper function example. We have been trying to call a call() function in another lib and keep getting compilation errors. So just wanted to make sure when these libs get compiled down, B can call A.
    steven-terrana
    @steven-terrana
    if you’re ever looking for some library examples, the libraries i primarily work on are at https://github.com/boozallen/sdp-libraries
    Chris Bolton
    @Gl4di4torRr
    Sounds good!
    I see it now... I'm just too use to Java. Groovy throws me off sometimes.
    steven-terrana
    @steven-terrana

    Hey all! I’m looking for some feedback on the JTE documentation.

    I’ve created a github issue that outlines some specifics and to provide a public form to start the conversation :)

    jenkinsci/templating-engine-plugin#103