by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    jzr1991
    @jzr1991
    By that I mean, let's say I have a simple pipeline template that mandates a build, test, and deploy. But then a team comes along and wants to use it, but also go above and beyond by adding in a static_code_analysis after test, to improve upon the basic mandatory steps I've defined. Without having a variation of the pipeline in pipeline_templates, is there a way? We might have lots of teams wanting to add lots of extra steps and I'm wary of getting to a place where we have 50 pipeline variations to suit all these cases. Thanks!
    steven-terrana
    @steven-terrana

    hmmm.

    the closest thing to that right now would be the Default Step Implementation which lets users dynamically “create” a step from their pipeline configuration file.

    it’s pretty limited to what it can do though.. you just provide a container image and a script path / command and it uses the Docker Pipeline Plugin to execute the command in teh container image specified.

    but that’s how i try to get around creating libraries for random things.

    one thing you could maybe do is rely exclusively on the lifecycle hook stuff?

    basically let teams configure a library source (scoped probably to just them) and then they can build their own steps.

    so if they wanted to run some custom stuff before the template they could create an @Init step?
    or for after the pipeline they could create an @CleanUp or @Notify step?

    if they wanted to inject functionality before/after a step in the template they could use the @BeforeStep and @AfterStep functionality?

    this isn’t an ideal solution but i can’t think of a cleaner way right now

    do you have any suggestions for the syntax of how something like that might work?

    the risk with that second approach would be that users could then override the steps in the template they’re inheriting. but maybe that’s okay for your use case?
    Vincent Brouillet
    @Vince-Cercury
    Hi. I'm a little confuse on how to create a simple pipeline with JTE. Not a multi branch one. I'm running JTE 1.7.1
    It looks like I can specify in line config and template. But not from scm. And where do I supply lib?
    Jackie Weng
    @jemerald
    Thanks @steven-terrana I didn't know about the DSL api-viewer, that helped a lot.

    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

    Jackie Weng
    @jemerald
    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.