Giter Club home page Giter Club logo

jenkins's Introduction

Image with automated Jenkins setup/configuration

This repository contains files for generating a Docker image based on jenkins/jenkins:alpine.

When the image is started for the first time it will configure some basic Jenkins settings (security, plugins, etc.) based on configuration files supplied in a volume.

Use / Configuring Image

This is a slightly opinionated build. Certain things will be turned on or off based on current recommended hardening (CLI, JNLP, etc.). Other things will be configurable via supplied property files.

  • You must supply the location of the configuration YAML files. By default it will expect these files in /jenkins-config, but this location can be overridden by supplying a value for the CONFIG_PATH environment variable for the container. Examples of the needed configuration files can be found in the examples/config directory.
    • The authentication mechanism configured is GitHub OAuth. OAuth is my personal preferred method, as no credentials are stored locally. At some point in the future I may investigate other OAuth provider options (gitlab, google, facebook, etc.).
    • The authorization mechanism configured is the Jenkins matrix authorization. No real reason other than it being the one I found examples to use.
    • Credentials created via the initialization script are created in the default namespace at the root folder. This is something I hope to rectify in a future release, as it can quickly lead to a long list of credentials to sort through for jobs.
    • At this time all configuration files are required. You can supply an empty YAML file, but the file must exist or the startup will fail.
  • You may supply job definition scripts. By default the initialization script will expect these files in /jenkins-jobs, but this location can be overridden by supplying a value for the JOB_PATH environment variable for the container. If no scripts are detected, no jobs will be created. A few examples can be found in the examples/jobs directory. You can see all the available options for job configuration at the Jenkins Job DSL API site.

Build

The build for this image will use the latest jenkins/jenkins:alpine image as a base, and apply the latest version of plugins listed in plugins.txt.

Versioning

This image does not follow traditional SemVersion versioning. Instead, the version is based on the build date and if it is built from master or a feature/* branch. The possible version formats are: YYYY.MM.R# / latest: Built from master. The number after 'R' indicates the build number for the month. YYYY.MM.F#.#: Built from a feature/* branch. The number after 'F' indicates which feature branch, and the number after the final '.' indicates the build number for the month. The reasons for this version scheme are:

  1. This scheme provides a clear indication of when it was built. If it hasn't been built for a while, a manual rebuild of latest will be performed. However, as a general practice, the latest release build should match the latest tag.
  2. The build will pickup the latest version of Jenkins and plugins each time it is built. While some people would prefer a consistent build, the purpose of this image is to be a 'bleeding edge build'. Each time it is built, new plugin versions may break something. If this becomes a problem, certain plugins may become version-locked on at least a temporary basis.

Changelog

All changes should be captured in CHANGELOG.md. If you're wondering what was changed as part of a specific version, look there first.

jenkins's People

Contributors

surrettcharles avatar

jenkins's Issues

Multi-branch projects are not scanned at initialization

Expected behavior

If a multi-branch pipeline job is defined as part of initialization, all branches with a Jenkinsfile are identified and/or immediately built.

Actual behavior

No branches are identified or built.

steps to reproduce the issue

Create a new container with a multi-branch pipeline job defined in the /jenkins-jobs mount

Attach any files/logs that will assist in troubleshooting

FileNotFoundException thrown when /jenkins-jobs is not mounted

Expected behavior

Initialization completes, and assumes no jobs to create.

Actual behavior

FileNotFoundException thrown. Initialization still completes.

steps to reproduce the issue

  1. Create a new container with the latest image, omitting the mount for /jenkins-jobs
  2. Start Jenkins
WARNING: Failed to execute /var/jenkins_home/init.groovy.d/9-SetupJobs.groovy
java.io.FileNotFoundException: /jenkins-jobs
        at org.codehaus.groovy.runtime.ResourceGroovyMethods.checkDir(ResourceGroovyMethods.java:1043)
        at org.codehaus.groovy.runtime.ResourceGroovyMethods.eachFile(ResourceGroovyMethods.java:1062)
        at org.codehaus.groovy.runtime.ResourceGroovyMethods.eachFile(ResourceGroovyMethods.java:1088)
        at org.codehaus.groovy.runtime.dgm$936.invoke(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at 9-SetupJobs.run(9-SetupJobs.groovy:15)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585)
        at jenkins.util.groovy.GroovyHookScript.execute(GroovyHookScript.java:136)
        at jenkins.util.groovy.GroovyHookScript.execute(GroovyHookScript.java:127)
        at jenkins.util.groovy.GroovyHookScript.run(GroovyHookScript.java:110)
        at hudson.init.impl.GroovyInitScript.init(GroovyInitScript.java:41)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
        at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
        at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
        at jenkins.model.Jenkins$5.runTask(Jenkins.java:1068)
        at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
        at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

DisableAdminSetup.groovy throws exception on subsequent starts

Expected behavior

Jenkins container is able to start without issue

Actual behavior

During subsequent startups Jenkins throws a NullPointerException while processing 1-DisableAdminSetup.groovy.

java.lang.NullPointerException
        at jenkins.model.Jenkins.setInstallState(Jenkins.java:1038)
        at jenkins.model.Jenkins$setInstallState$0.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at 1-DisableAdminSetup.run(1-DisableAdminSetup.groovy:13)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:585)
        at jenkins.util.groovy.GroovyHookScript.execute(GroovyHookScript.java:136)
        at jenkins.util.groovy.GroovyHookScript.execute(GroovyHookScript.java:127)
        at jenkins.util.groovy.GroovyHookScript.run(GroovyHookScript.java:110)
        at hudson.init.impl.GroovyInitScript.init(GroovyInitScript.java:41)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
        at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
        at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
        at jenkins.model.Jenkins$5.runTask(Jenkins.java:1068)
        at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
        at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

steps to reproduce the issue

  1. Create new Jenkins container
  2. Restart the container

Attach any files/logs that will assist in troubleshooting

Server requests final unlock on first start

Expected behavior

Server should be past initial unlock after a fresh image is applied

Actual behavior

Server requests first time unlock code and plugin installation

steps to reproduce the issue

Create a fresh image in a Docker instance and start it

Need a way to set the (global) git user

Expected behavior

As part of configuring either a job or the global system default, there needs to be a way to set the git user/email

Actual behavior

System and job defaults to not set and throws an error if the job needs to do things with the repo (e.g. tag the commit)

steps to reproduce the issue

  1. Create a fresh container
  2. Define a job via DSL
  3. Note when job attempts to do a git command (e.g. tag the commit) it throws an error indicating the user information is not set

Attach any files/logs that will assist in troubleshooting

Jenkinsfile should build the image instead of just tagging the repo

Expected behavior

When the build is executed the new container is built and pushed to Docker Hub

Actual behavior

Repository is tagged to trigger Docker Hub automated build. For tags this doesn't seem to be triggering the correct build anymore.

steps to reproduce the issue

  1. Make a commit to the repository on a feature branch
  2. Push the commit(s) to GitHub
  3. Note the build type triggered on Docker Hub

Attach any files/logs that will assist in troubleshooting

Rebuild of container resets successful build count for version plugin

Expected behavior

When rebuilding the container, the current number of successful builds is retained

Actual behavior

Number of successful builds is reset

steps to reproduce the issue

  1. Create container with (multi-branch) pipeline build
  2. Trigger X number of successful builds
  3. Rebuild the container with the job DSL file present
  4. Trigger a new build
  5. Note the version number that utilizes the number of successful builds has been reset

Attach any files/logs that will assist in troubleshooting

Need a way to configure jobs as part of initialization

Expected behavior

As part of initial configuration of a new Jenkins container, jobs need to be manually configured. There should be an automated way to accomplish this.

Actual behavior

No way to automatically create jobs as part of initialization

steps to reproduce the issue

  1. Create a new container
  2. Login to the UI
  3. Notice no jobs are configured

Attach any files/logs that will assist in troubleshooting

Need a way to create credentials for jobs

Expected behavior

When initializing a new container, credentials can be created for use in job definitions.

Actual behavior

No method for creating credentials is currently provided during initialization.

steps to reproduce the issue

  1. Add job definitions to be created when initializing the container
  2. Create a new container

Attach any files/logs that will assist in troubleshooting

Jenkins is insecure after initialization

Expected behavior

After starting a fresh image of Jenkins, the server should be secured.

Actual behavior

New Jenkins instance allows anyone to do anything.

steps to reproduce the issue

  1. Start a new container
  2. Open the Jenkins UI

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.