Giter Club home page Giter Club logo

puppet-jenkins's Introduction

puppet-jenkins

Build Status

This is intended to be a re-usable Puppet module that you can include in your own tree.

Experimental Types and Providers

The experimental types/providers are not for the faint of heart. If you are starting out with this module you probably want to skip directly to Getting Started.

A family of experimental native types and providers has been added to this module, in parallel to the existing classes and defined types, with the goal of soliciting feedback. One of the primary benefits of these new types is not requiring manifest changes to manage jenkins with or without "security" enabled. The goal is to eventually replace the functionality of the existing classes/defines with the new types. Usage feedback (positive and negative), bug reports and/or PRs would be greatly welcomed.

The semantics and API of these types should be considered unstable and almost certainly will change based on feedback. It is currently unclear if these types will be considered part of the public API or treated as private to the module.

See NATIVE_TYPES_AND_PROVIDERS.md

Jenkins 2.54 and 2.46.2 remoting free CLI and username / password CLI auth

Jenkins refactored the CLI in 2.54 and 2.46.2 in response to several security incidents (See JENKINS-41745. This module has been adjusted to support the new CLI.

The CLI supports proper authentication with username and password. It's a requirement for supporting AD and OpenID authentications (there is no ssh key there). You can supply $jenkins::cli_username and $jenkins::cli_password to use username / password based authentication. Then the puppet automation user can also reside in A.D

Note: Jenkins requires a ssh username, so you must also provide $jenkins::cli_username for ssh. If you specify both username/password and ssh key file, SSH authentication is preferred.

Using puppet-jenkins

Getting Started

puppet module install puppet/jenkins
    node 'hostname.example.com' {
        include jenkins
    }

Then the service should be running at http://hostname.example.com:8080/.

Jenkins' options

Master Executor Threads

class { 'jenkins':
  executors => 0,
}

Managing Jenkins jobs

Build jobs can be managed using the jenkins::job define

Creating or updating a build job

  jenkins::job { 'test-build-job':
    config => template("${templates}/test-build-job.xml.erb"),
  }

Removing an existing build job

  jenkins::job { 'test-build-job':
    ensure => 'absent',
  }

Installing Jenkins plugins

The Jenkins puppet module defines the jenkins::plugin resource which will download and install the plugin "by hand"

The names of the plugins can be found on the update site

Latest

By default, the resource will install the latest plugin, i.e.:

  jenkins::plugin { 'git': }

If you specify version => 'latest' in current releases of the module, the plugin will be downloaded and installed with every run of Puppet. This is a known issue and will be addressed in future releases.

By version

If you need to peg a specific version, simply specify that as a string, i.e.:

  jenkins::plugin { 'git':
    version => '1.1.11',
  }

Note that plugin will timeout if it takes longer than 120 seconds to download. You can increase this by specifying a timeout value, i.e: timeout => 240.

Verifying

This module will download the jenkins modules over HTTP, without SSL. In order to add some verification regarding the downloaded file, you can specify a checksum. You can also define a checksum type with 'digest_type' (default to sha1 if unspecified) ie.:

  jenkins::plugin { 'git':
    version       => '2.2.12',
    digest_string => '48141822e0eea1faa1a1a99b35372494e7352c2746ca3aa3a19a07f34b021848d2cd0bffc8959c1b809c5be231c1b49e9ffec0430dd68938197ac0f34588ee25',
    digest_type   => 'sha512',
  }

Direct URL

Direct URL from which to download plugin without modification. This is particularly useful for development and testing of plugins which may not be hosted in the typical Jenkins' plugin directory structure.

  jenkins::plugin { 'myplugin':
    source => 'https://example.org/myplugin.hpi',
  }

Note that that when source is specified, the version and plugin_url parameters will have no effect on the plugin retrieval URL.

Plugin dependencies

Dependencies are not automatically installed. You need to manually determine the plugin dependencies and include those as well. The Jenkins wiki is a good place to do this. For example: The Git plugin page is at https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin.

Slaves

You can automatically add slaves to jenkins, and have them auto register themselves. Most options are actually optional, as nodes will auto-discover the master, and connect.

Full documentation for the slave code is in jenkins::slave.

It requires the swarm plugin on the master & the class jenkins::slave on the slaves, as below:

    node /jenkins-slave.*/ {
      class { 'jenkins::slave':
        masterurl => 'http://jenkins-master1.domain.com:8080',
        ui_user => 'adminuser',
        ui_pass => 'adminpass',
      }
    }

    node /jenkins-master.*/ {
        include jenkins
        include jenkins::master
    }

Depending on Jenkins

If you have any resource in Puppet that depends on Jenkins being present, add the following require statement:

  exec { 'some-exec':
    require => Class['jenkins::package'],
    # ... etc
  }

Advanced features

  1. Plugin Hash - jenkins::plugins
  2. Config Hash - jenkins::config
  3. Configure Firewall - jenkins (init.pp)
  4. Outbound Jenkins Proxy Config - jenkins (init.pp)
  5. CLI Helper
  6. Jenkins Users
  7. Credentials
  8. Simple security model configuration

API-based Resources and Settings (Users, Credentials, security)

This module includes a groovy-based helper script that uses the Jenkins CLI to interact with the Jenkins API. Users, Credentials, and security model configuration are all driven through this script.

When an API-based resource is defined, the Jenkins' CLI is installed and run against the local system (127.0.0.1). Jenkins is assumed to be listening on port 8080, but the module is smart enough to notice if you've configured an alternate port using jenkins::config_hash['JENKINS_PORT'].

Users and credentials are Puppet-managed, meaning that changes made to them from outside Puppet will be reset at the next puppet run. In this way, you can ensure that certain accounts are present and have the appropriate login credentials.

CLI Helper

The CLI helper assumes unauthenticated access unless configured otherwise. You can configure jenkins::cli_helper to use an SSH key on the managed system by passing the keyfile path as a class parameter:

  class {'jenkins':
    cli_ssh_keyfile => '/path/to/id_rsa',
  }

... or via hiera:

jenkins::cli_ssh_keyfile: "/path/to/id_rsa"

Direct including of the jenkins::cli_helper class into the manifest is deprecated.

There's an open bug in Jenkins (JENKINS-22346) that causes authentication to fail when a key is used but authentication is disabled. Until the bug is fixed, you may need to bootstrap jenkins out-of-band to ensure that resources and security policy are configured in the correct order. For example:

# In puppet:
  anchor {'jenkins-bootstrap-start': } ->
    Class['jenkins::cli_helper'] ->
      Exec[$bootstrap_script] ->
        anchor {'jenkins-bootstrap-complete': }

# Code for $bootstrap_script
#!/bin/bash -e
# Generate an SSH key for the admin user
ADMIN_USER='<%= admin_user_name %>'
ADMIN_EMAIL='<%= admin_user_email %>'
ADMIN_PASSWORD='<%= admin_user_password %>'
ADMIN_FULLNAME='<%= admin_user_full_name %>'
ADMIN_SSH_KEY='<%= admin_ssh_keyfile %>'
JENKINS_CLI='<%= jenkins_libdir %>/jenkins-cli.jar'
PUPPET_HELPER='<%= jenkins_libdir %>/puppet_helper.groovy'
HELPER="java -jar $JENKINS_CLI -s http://127.0.0.1:8080 groovy $PUPPET_HELPER"
DONEFILE='<%= jenkins_libdir %>/jenkins-bootstrap.done'

ADMIN_PUBKEY="$(cat ${ADMIN_SSH_KEY}.pub)"

# Create the admin user, passing no credentials
$HELPER create_or_update_user "$ADMIN_USER" "$ADMIN_EMAIL" "$ADMIN_PASSWORD" "$ADMIN_FULLNAME" "$ADMIN_PUBKEY"
# Enable security. After this, credentials will be required.
$HELPER set_security full_control

touch $DONEFILE

jenkins::cli::exec

The defined type jenkins::cli::exec may be used to execute arbitrary CLI helper commands.

Arguments to the CLI helper script may be specified as the resource's title.

  jenkins::cli::exec { 'set_num_executors 0': }

Or passed as an array to the command parameter. This example is semantically equivalent to the first.

  jenkins::cli::exec { 'set_num_executors 0':
    command => ['set_num_executors', '0'],
  }

which is also equivalent to:

  jenkins::cli::exec { 'set_num_executors 0':
    command => 'set_num_executors 0',
  }

If the unless parameter is specified, an environment variable named $HELPER_CMD is declared which contains the complete string needed to execute the CLI helper script (minus arguments). This may be useful in constructing idempotent exec statements.

  $num_executors = 0
  jenkins::cli::exec { "set_num_executors ${num_executors}":
    unless => "[ \$(\$HELPER_CMD get_num_executors) -eq ${num_executors} ]"
  }

Users

Email and password are required.

Create a johndoe user account whose full name is "Managed by Puppet":

  jenkins::user { 'johndoe':
    email    => '[email protected]',
    password => 'changeme',
  }

Credentials

Password is required. For ssh credentials, password is the key passphrase (or '' if there is none). private_key_or_path is the text of key itself or an absolute path to a key file on the managed system.

Create ssh credentials named 'github-deploy-key', providing an unencrypted private key:

    jenkins::credentials { 'github-deploy-key':
      password            => '',
      private_key_or_path => hiera('::github_deploy_key'),
    }

Setting a UUID:

You can also specify a UUID to use with the credentials, which will be used to identify the credentials from within the job config. This is necessary when setting credentials for use with the git plugin, for example.

You can either manually generate a UUID from a site like UUIDTools.com, or use the UUID from an existing user, which is accessible within the URL of the Jenkins console when managing an existing user's credentials.

    jenkins::credentials { 'deploy-user':
      password            => '',
      private_key_or_path => hiera('::deploy_key'),
      uuid                => hiera('::deploy_credentials_uuid'),
    }

Configuring Security

The Jenkins security model can be set to one of two modes:

  • full_control - Users have full control after login. Authentication uses Jenkins' built-in user database.
  • unsecured - Authentication is not required.

Jenkins security is not managed by puppet unless jenkins::security is defined.

Using from Github / source

With librarian

If you use librarian-puppet, add the following to your Puppetfile:

mod "puppet/jenkins"

With the "puppet module" tool

This module is compatible with the puppet module tool. Appropriately this module has been released to the Puppet Forge, allowing you to easily install the released version of the module

To quickly try this module with the puppet module tool:

% sudo puppet module install puppet/jenkins
% sudo puppet apply -v -e 'include jenkins'
info: Loading facts in facter_dot_d
info: Loading facts in facter_dot_d
info: Applying configuration version '1323459431'
notice: /Stage[main]/Jenkins::Repo::El/Yumrepo[jenkins]/descr: descr changed '' to 'Jenkins'
notice: /Stage[main]/Jenkins::Repo::El/Yumrepo[jenkins]/baseurl: baseurl changed '' to 'http://pkg.jenkins-ci.org/redhat/'
notice: /Stage[main]/Jenkins::Repo::El/Yumrepo[jenkins]/gpgcheck: gpgcheck changed '' to '1'
notice: /Stage[main]/Jenkins::Repo::El/File[/etc/yum/jenkins-ci.org.key]/ensure: defined content as '{md5}9fa06089848262c5a6383ec27fdd2575'
notice: /Stage[main]/Jenkins::Repo::El/Exec[rpm --import /etc/yum/jenkins-ci.org.key]/returns: executed successfully
notice: /Stage[main]/Jenkins::Package/Package[jenkins]/ensure: created
notice: /Stage[main]/Jenkins::Service/Service[jenkins]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 27.46 seconds

Overriding the jenkins package name

It's possible to specify a different package name to the default jenkins if you wish:

class { 'jenkins':
  package_name => 'jenkins_custom',
}

Installing from a hosted RPM

Sometimes you don't have an RPM repository available and are not allowed to directly install from repositories on the Internet. In this case, you can still install Jenkins with this module by hosting the jenkins RPM file somewhere accessible (http server, S3 bucket, etc.) and tell

class { 'jenkins':
  direct_download => 'http://myserver/rpms/jenkins-x.xxx-1-1.rpm',
}

puppet-jenkins's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

puppet-jenkins's Issues

Unsupported OSFamily RedHat on node

Puppet Version: 3.6.1+
Facter Version: 2.1.0
OS: Centos 5.7

When I add Jenkins to a node, I get the following error:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Unsupported OSFamily RedHat on node

I was able to correct this by changing sysconfig.pp to use quotes for the operating systems.

$path = $::osfamily ? {
'RedHat' => '/etc/sysconfig',
'Suse' => '/etc/sysconfig',
'Debian' => '/etc/default',
default => fail( "Unsupported OSFamily ${::osfamily}" )
}

str2bool issue?

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: str2bool(): Requires either string to work with at /etc/puppetlabs/puppet/modules/jenkins/manifests/init.pp:83 on node beaker.novalocal

3.3.3 (Puppet Enterprise 3.1.1)

Plugin installation don't work

I'm trying to install Jenkins plugins with the following code:

class { 'jenkins':
  version => 'latest',  }
jenkins::plugin { 'git': }
jenkins::plugin { 'git-client': }
jenkins::plugin { 'gitlab-hook': }
class { 'git': }

The plugins are downloaded in /var/lib/jenkins/plugins but they never appear as installed in jenkins, even with a manual restart of jenkins.

I'm testing on ubuntu 12.04 with openjdk-7.

Module broke - Debian Wheezy / Puppet 3.6.2

Hi there,

the module is broke under Debian Wheezy with Puppet 3.6.2 i think

Just included the dependencies and made a .pp file with include jenkins and i get this error

Error: Could not apply complete catalog: Found 1 dependency cycle:
(Anchor[apt::key D50582E6 present] => Apt::Key[Add key: D50582E6 from Apt::Source jenkins] => File[jenkins.list] => Exec[apt_update] => Class[Apt::Update] => Stage[setup] => Stage[main] => Class[Jenkins::Repo::Debian] => Apt::Source[jenkins] => File[jenkins.list])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz

Why does plugin.pp take a parent plugin parameter?

It seems redundant to specify the parent directory of the plugin. On unix we could call dirname to find this string. In puppet we could do:

$plugin_dir = '/var/lib/jenkins/plugins'
$plugin_dir_parent = inline_template("<%= @plugin_dir.split('/')[0..-2].join("/") %>")

A bit gross, but better than duplicating. I'm somewhat suprised that a 'dirname' function doesn't exist in stdlib.

Tag of version 0.3.1 and 0.3.0

These versions are available on puppet forge but not tagged here. Is there a change that the right commits could be tagged to make the development easier to follow?

How to use the Firewall class?

Hi,

https://github.com/jenkinsci/puppet-jenkins states that configuring the firewall is an Advanced feature.

The firewall.pp file says the jenkins::firewall class integrates with the puppetlabs-firewall module.

I added this to my PuppetFile before running librarian-puppet install:

mod "firewall",
  :git => "git://github.com/puppetlabs/puppetlabs-firewall.git"

Then, i added this to my init.pp file:

jenkins::firewall { }

But I am getting this error when trying to apply the manifest:

Could not parse for environment production: All resource specifications require names

Does anyone know how to apply the firewall class? Thanks!

Albert.

Improve support for complete removal of Jenkins

I tried to purge Jenkins from my system, but it outputs a lot of warnings:

Notice: /Stage[main]/Jenkins::Package/Package[jenkins]/ensure: ensure changed '1.509.3' to 'purged'
Error: /Stage[main]/Jenkins::Config/Jenkins::Sysconfig[HTTP_PORT]/File_line[Jenkins sysconfig setting HTTP_PORT]: Could not evaluate: No such file or directory - /etc/default/jenkins
Notice: /User[jenkins]: Dependency File_line[Jenkins sysconfig setting HTTP_PORT] has failures: true
Warning: /User[jenkins]: Skipping because of failed dependencies
Notice: /Group[jenkins]: Dependency File_line[Jenkins sysconfig setting HTTP_PORT] has failures: true
Warning: /Group[jenkins]: Skipping because of failed dependencies
Notice: /Stage[main]/Jenkins::Plugins/Jenkins::Plugin[greenballs]/File[/var/lib/jenkins]: Dependency File_line[Jenkins sysconfig setting HTTP_PORT] has failures: true
Warning: /Stage[main]/Jenkins::Plugins/Jenkins::Plugin[greenballs]/File[/var/lib/jenkins]: Skipping because of failed dependencies
Notice: /Stage[main]/Jenkins::Plugins/Jenkins::Plugin[greenballs]/File[/var/lib/jenkins/plugins]: Dependency File_line[Jenkins sysconfig setting HTTP_PORT] has failures: true
Warning: /Stage[main]/Jenkins::Plugins/Jenkins::Plugin[greenballs]/File[/var/lib/jenkins/plugins]: Skipping because of failed dependencies
[...]
Notice: /Stage[main]/Jenkins::Service/Service[jenkins]: Dependency File_line[Jenkins sysconfig setting HTTP_PORT] has failures: true
Warning: /Stage[main]/Jenkins::Service/Service[jenkins]: Skipping because of failed dependencies
Notice: /Stage[main]/Jenkins/Anchor[jenkins::end]: Dependency File_line[Jenkins sysconfig setting HTTP_PORT] has failures: true
Warning: /Stage[main]/Jenkins/Anchor[jenkins::end]: Skipping because of failed dependencies

It also only removed a package and jenkins user but leaved other artifacts on my system:

  • jenkins group
  • key for jenkins repository
  • /etc/apt/sources.list.d/jenkins.list file

This is my puppet code I used for removal:

class { 'jenkins':
  version     => 'purged',
  lts         => 1, # use stable version
  repo        => 1, # install from repository
  config_hash => {
    'HTTP_PORT' => { 'value' => '8000' }
  },
  plugin_hash => {
    'greenballs'            => { version => '1.12'    }
  }
}

Misleading Documentation in init.pp

I just ran into an issue and wanted to get this posted for discussion:

I was trying to configure the module to install the latest version of Jenkins CI from their Ubuntu/Debian repo. The Jenkins CI repo is configured correctly.

Looking at the init.pp I was under the impression that keeping the default value of $lts and $repo, the module would pull the most recent version available.

This is not the case and I believe it is as a result of the default value for $version in init.pp and package.

When my Puppet run was triggered, the check for Jenkins being installed was successful and no further action was taken. I had to set $version = latest, in order for Jenkins to be automatically upgraded to the available version.

My initial thoughts are:

  1. $version in init.pp should be set to undef
  2. The documentation needs to be updated to properly educate the user and provide the available options
  3. Provide a basic example

Update plugins before adding new?

Hi,

Is there a way to update the default plugins in jenkins before adding additional ones using puppet? Specifying them again in puppet with a version does not work.
I ran into this issue [1].
Basicly the installed version of 'credentials' is incompatible with the 'git' plugin, and thus jenkins refuses to start. Manually removing the git plugins + jenkins restart + plugin update, solves the issue. But there has to be a better way to handle this.
Can this be done using a custom parameter on the jenkins class perhaps, or something else?

The Jenkins version I used is the latest LTS at time of writing (1.509.4), perhaps this doesn't occur with the latest (non-LTS) version, but the LTS version looks more geared towards bigger enterprises.

Best regards,
Steven

[1] https://answers.atlassian.com/questions/217427/git-plugin-error-for-stash

Install a plugin should not prevent jenkins home to be a symlink

In manifests/plugin.pp:

if (!defined(File[$plugin_dir])) {
    file { [$plugin_parent_dir, $plugin_dir]:
      ensure => directory,
      owner => 'jenkins',
      group => 'jenkins',
      mode => '0755',
      require => [Group['jenkins'], User['jenkins']],
    }
  }

This forces the $plugin_parent_dir to be a directory. In our case, we have defined it to be a symbolic link, now erased. And all jenkins rules now start against a new empty dir.

I don't understand why the plugin class should do that: Jenkins installation and Jenkins user are requirements for this class.

"invalid option: -p" for Jenkins Slave Status in CentOS 6.5

I'm using the jenkins::slave class to create a Jenkins slave in CentOS 6.5 (minimal version). It looks like the init.d script for the service isn't behaving correctly. In the slave_status() function it calls status -p $PID_FILE and it looks like "-p" isn't a valid parameter for the status program, so it throws an error.

Service not restarting after changing configuration file

I've changed a HTTP_PORT from 8080 to 8000 and run puppet, it changes config but didn't restart service:

Info: Applying configuration version '1379015892'
Notice: /Stage[main]/Jenkins::Config/Jenkins::Sysconfig[HTTP_PORT]/File_line[Jenkins sysconfig setting HTTP_PORT]/ensure: created
Notice: Finished catalog run in 2.07 seconds

I think we should restart service in this case.

support for disabling plugins

I'd love to see support for disabling Jenkins plugins. The core distribution ships with some plugins that aren't necessarily used in all deployments (i.e. CVS). This can be handled by writing an empty "{plugin-name}.jpi.disabled" file to the plugins directory.

Packaging Cruft in 1.1.0

Looks like some packaging cruft made it into the latest release of this module. Quick glance pulls up:

Swap files:

  • ./lib/facter/.jenkins.rb.swp
  • ./lib/puppet/.jenkins.rb.swp
  • ./lib/puppet/jenkins/.facts.rb.swp
  • ./lib/puppet/jenkins/.plugins.rb.swp
  • ./spec/unit/.jenkins_plugins_spec.rb.swp

Another Git Repo:

  • ./puppet-jenkinstracking/

Support plugin dependencies

If a Jenkins plugin requires another plugin this dependency can't be resolved automatically currently within puppet-jenkins, it would be nice if there would be a way to also (automatically) install dependencies.

Thanks for puppet-jenkins!

Some plugins not updating

Hi,

I'm using the 1.0.1 release of this module with PE 3.1.3 on RHEL6.

I'm using the plugin code like this:

create_resources(jenkins::plugin, hiera('jenkins_plugins', {}))

Where "jenkins_plugins" is a hash structure containing something like:

jenkins_plugins:
  'multiple-scms':
    version: '0.3'
  'token-macro':
    version: '1.10'
...

I'm finding that some plugins do not update - it seems to be those that are distributed as plugin_name.hpi, eg. credentials.

When puppet runs, it says it installed the plugin:

Notice: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/Exec[download-credentials]/returns: executed successfully
Notice: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]/owner: owner changed 'root' to 'jenkins'
Notice: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]/mode: mode changed '0600' to '0644'
Info: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]: Scheduling refresh of Service[jenkins]
Info: /Stage[main]/Profile_jenkins/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]: Scheduling refresh of Service[jenkins]

However, Update Centre still shows the old version and the same code runs again next time puppet runs.

Any ideas?

R.

Parameterize the Firewall configuration option

Users should have the ability to enable/disable the firewall class depending on their environment via a parameter that gets passed during the Puppet run. Eg:

class { 'jenkins':
firewall => false,
}

Should we include the puppet-jenkinstracking code?

@kohsuke has been working on a Puppet module to correspond with a Puppet plugin for Jenkins to close the loop on what files are where.

An example of usage from a manifest would be:

class foo {
    file {
        '/tmp/foo.war':
            source => "puppet:///modules/foo/foo.war"
    }

    track { '/tmp/foo2.war':
    }

My personal opinion is that this is acceptable to have in the "canonical Jenkins module for Puppet." I wanted to see what my co-maintainers thought.

//cc @jlambert121 @matthewbarr

jenkins::firewall hardcodes the jenkins port

Since the port can be configured using jenkins::config, the jenkins::firewall class should follow that. Granted, it's fairly easy to replicate the functionality of jenkins::firewall locally, and set the right port there...

Question about using config_hash

Hi all,

I'm desperately hoping I'm not missing something obvious and about to ask a dumb question but I suspect that is the case.

Could someone please provide me with an example of how to use jenkins::config? I tried following the example in config.pp and just got blasted by Puppet for trying to redefine a class. I am unclear on how and where to pass in a config hash.

Thanks!

Add ability for removing jenkins plugin

Please provide ability to remove installed plugin. I suggest the following syntax:

class { 'jenkins':                                                                                  
  plugin_hash => {
    'cvs' => { version => 'absent' }
  }
}

"Invalid relationship" when installing plugin

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid relationship: File[/var/lib/jenkins/plugins/swarm.hpi] { require => Exec[download-swarm] }, because Exec[download-swarm] doesn't seem to be in the catalog

the offending code seems to be L51 on plugin.pp:

exec { download-${name} } being wrapped in an if statement. this results in the Exec["download-${name}"] not being part of the catalog making require => Exec["download-${name}"] impossible to fulfill.

Jenkins Puppet Package provider discussion

I actually found a way to do some of what I want for plugins via groovy, which can be executed via a curl.

It was that, or the use the cli. CLI required Java, which was a pain.

Todo:

  • find a groovy method for installing a plugin
  • Maybe find a way to remove plugin via groovy.
  • parse plugin results so puppet can deal with it.

Update Center URL broken

It appears that the update center cannot be accessed unless using https. The url in the plugin is hard coded to http.

Update plugin if it already installed

Jenkins 1.509.2 provided bundled javadoc plugin with version 1.0

When I want to update it to the latest version (or manually specify it):

class { 'jenkins':                                                                                  
  lts => 1
  repo => 1
  plugin_hash => {                                                                                  
    'javadoc' => { version => '1.1' }
  }
}

Plugin wasn't updated because code only checks if plugin presents or not. It would be better to also check installed version and update plugin if newer version requested.

Some plugins after being installed are not picked up by Jenkins

Most of the plugins install just fine, but a few such as gerrit-trigger and sectioned-view do not seem to be picked up after a service reboot. The files seem to be correctly deployed to the 'plugins' directory and I have not yet identified a pattern for which plugins do or do not work properly, but it does appear to be consistent for a given plugin.

I am able to go into the Jenkins portal and install the plugin and it works just fine. But obviously that defeats the purpose.

Update Puppet Forge to reference new repo

On the Puppet forge, the module is still showing the install line as:

puppet module install rtyler/jenkins

Can a request be made to update that Forge module to reference the new jenkinsci/puppet-jenkins repo?

cli option broken w/ jenkins 1.563 on ubuntu precise

Using a simple manifest like:

class { 'jenkins':
    cli                => true,
}

I get

err: /Stage[main]/Jenkins::Cli/Exec[jenkins-cli]/returns: change from notrun to 0 failed: unzip /usr/lib/jenkins/jenkins.war WEB-INF/jenkins-cli.jar && mv WEB-INF/jenkins-cli.jar /usr/lib/jenkins/jenkins-cli.jar && rm -rf WEB-INF returned 9 instead of one of [0] at /tmp/vagrant-puppet/modules-0/jenkins/manifests/cli.pp:22

And it looks like this is because the war is in a different location (/usr/share/jenkins).

Package information:

vagrant@tcomdigi-jenkins:/var/lib/jenkins$ apt-cache policy jenkins
jenkins:
  Installed: 1.563
  Candidate: 1.563
  Version table:
 *** 1.563 0
        500 http://pkg.jenkins-ci.org/debian/ binary/ Packages
        100 /var/lib/dpkg/status

I'll see if I can come up with a patch for you.

Remove old jenkins::plugin::install code, & update test

Accidentally messed up my remotes, so pushed it directly. This is open for a reference.

Commit is: 95f32be

Minimal diff between jenkins::plugin::install & jenkins::plugin, only referenced in these files:

mbarr$ grep "jenkins::plugin::install" -R *
manifests/plugin/install.pp:# Define: jenkins::plugin::install
manifests/plugin/install.pp:define jenkins::plugin::install($version=0) {
spec/defines/jenkins_plugin_install_spec.rb:describe 'jenkins::plugin::install' do

Additionally, updated test for the spec to use the current code.

Re-Release to the forge

There are .swp files in the forge release, if someone could re-release to fix that, I would appreciate it.

Enhancement: ability to puppetize Jenkins jobs

I would like the ability to be able to specify my jenkins jobs in puppet, include the config.xml as an erb template, and have all my puppetized hosts receive the new jenkins job. Subsequent changes to the jenkins job in puppet would also get pushed and updated on the puppetized hosts.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.