Coder Social home page Coder Social logo

jenkinsci / packaging Goto Github PK

View Code? Open in Web Editor NEW
41.0 113.0 83.0 5.01 MB

Native packaging for Jenkins

Home Page: https://jenkins.io

Shell 54.38% Makefile 5.94% Python 15.54% PowerShell 10.09% HTML 10.91% Jinja 3.12%
native-packages rpm deb macos windows installers

packaging's Introduction

Native package script for Jenkins

This repository contains scripts for packaging jenkins.war into various platform-specific native packages. The following platforms are currently supported:

  • Windows MSI: msi/
  • RedHat/CentOS RPM: rpm/
  • Debian/Ubuntu DEB: deb/
  • OpenSUSE RPM: suse/

Pre-requisites

Running the main package script requires a Linux environment (currently Ubuntu, see JENKINS-27744.) Run make setup to install (most of the) necessary tools. Alternatively you can manually install the following onto a base install of Ubuntu:

  • make
  • unzip
  • devscripts
  • debhelper
  • rpm
  • expect
  • createrepo-c
  • ruby
    • net-sftp (gem install net-sftp)
  • maven
  • java

You also need a Jenkins instance with dist-fork plugin installed. URL of this Jenkins can be fed into make via the JENKINS_URL variable. This Jenkins needs to have a Windows build agent that has WiX Toolset (currently 3.5), msbuild, cygwin and .net 2.0. This build agent is used to build MSI packages, which can be only built on Windows.

You'll also need a jenkins.war file that you are packaging, which comes from the release process. The location of this file is set via the WAR variable.

Remark:

A docker image is available to run following script

logo

Run docker-compose run --rm packaging bash to get a shell in the official Docker image for this repository.

Generating packages

Run ./prep.sh to perform the preparatory actions of downloading the WAR and importing the GPG key. Run make package to build all the native packages. At minimum, you have to specify the WAR variable that points to the war file to be packaged and a branding file (for licensing and package descriptions). You will probably need to pass in the build environment and credentials.

For example:

make package BRAND=./branding/jenkins.mk BUILDENV=./env/test.mk CREDENTIAL=./credentials/test.mk

Packages will be placed into target/ directory. See the definition of the package goal for how to build individual packages selectively.

Running functional tests

The functional tests require Python 3 and Docker. Having built the packages as described above, run the functional tests with:

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
molecule test
deactivate

Publishing packages

This repository contains scripts for copying packages over to a remote web server to publish them. Run make publish to publish all native packages.

See the definition of the publish goal for individual package publishment.

Running local tests

These tests install packages from a web server where they are published. So if you want to run tests prior to publishing them, you need to create a temporary web server that you can mess up.

The default branding & environment (branding/test.mk and env/test.mk) are designed to support this scenario. To make local testing work, you also need to have /etc/hosts entry that maps test.pkg.jenkins.io hostname to 127.0.0.1, and your computer has to be running ssh that lets you login as you.

Once you verified the above prerequisites, open another terminal and run make test.local.setup This will run a docker container that acts as your throw-away package web server. When done, Ctrl+C to kill it.

Branding

branding/ directory contains *.mk files that control the branding of the generated packages. It also include text files which are used for large, branded text blocks (license and descriptions). Specify the branding file via the BRAND variable.

You can create your own branding definition to customize the package generation process. See branding readme for more details. In the rest of the packaging script files, these branding parameters are referenced via @@NAME@@ and get substituted by bin/branding.py. To escape a string normally like @@VALUE@@, add an additional two @@ symbols as a prefix: @@@@VALUE@@.

Environment

env/ directory contains *.mk files that control the environment into which you publish packages. Specify the environment file via the BUILDENV variable.

You can create your own environment definition to customize the package generation process. See environment readme for more details.

Credentials

credentials/ directory contains test.mk file that controls the locations of code-signing keys, their passwords, and certificates. Specify the credentials file via the CREDENTIAL variable.

For production use, you need to create your own credentials file. See credentials readme for more details.

TODO (mostly note to myself)

  • Split resource templates to enable customization

packaging's People

Contributors

abayer avatar armfergom avatar basil avatar daniel-beck avatar dependabot[bot] avatar djanavar avatar emonty avatar hayderimran7 avatar jglick avatar jieryn avatar jtnord avatar kohsuke avatar kwhetstone avatar markewaite avatar notmyfault avatar oep avatar olblak avatar oleg-nenashev avatar olivergondza avatar paxswill avatar petere avatar raul-arabaolaza avatar renovate[bot] avatar resmo avatar slide avatar stisti avatar svanoort avatar timja avatar timp avatar tn-osimis avatar

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

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

packaging's Issues

Staging for packages

Jenkins core takes ~2->2.5 hours to release

Yep, we do this a few days earlier and I don't care.

Packages are painful at 17-20 minutes each too, and I've requested staging there forever ๐Ÿ˜ข

So, yes, staging here would be great. We have Docker repos on repo.jenkins-ci.org which can probably support that.

Originally posted by @daniel-beck in jenkinsci/docker#1149 (comment)

MSI Parameters PORT and INSTALLDIR do not work

Jenkins and plugins versions report

Environment
Issue with Installer not with Jenkins

What Operating System are you using (both controller, and any agents involved in the problem)?

Windows Server 2016

Reproduction steps

Starting with a Windows machine with a compatible version of Java available at $JavaHome.

  1. Download Jenkins MSI
  2. Attempt to silently install Jenkins, passing arguments such as PORT or INSTALLDIR, e.g.
    msiexec /qn /norestart /l*v "~\Desktop\latestAttempt.log" /i "~\Desktop\jenkins-2.331.msi" INSTALLDIR=C:\ Jenkins PORT=9080 JAVA_HOME="$JavaHome" JENKINS_ROOT=$env:ProgramData\Jenkins\
  3. Check in the install log that PORT and INSTALLDIR are being set
  4. Check the directory Jenkins is installed to
  5. Check within the jenkins.xml config that the port has not been updated

Expected Results

  • Jenkins would be "installed" to the directory passed to INSTALLDIR.
  • Jenkins would use the port passed to PORT

Actual Results

  • Jenkins was installed to the default directory, C:\Program Files\Jenkins
  • Jenkins used the default port, 8080

Anything else?

Looking at the WXS file, it seems that PORT and INSTALLDIR are ignored in favour of PORTNUMBER and JENKINSDIR.

I will note that JENKINS_ROOT can also be passed in, but is ignored on all but the first install - but that seems to be the right behaviour unless additional migration logic is added.

This may also be the reason the Chocolatey package within this repository needs to update configuration files post-install.

openSUSE Leap testing is flaky

Jenkins and plugins versions report

Environment
Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

openSUSE Leap 15.3 x86_64

Reproduction steps

Run molecule test with no changes as described in the README.

Expected Results

The tests pass.

Actual Results

Observed in https://ci.jenkins.io/job/Packaging/job/packaging/job/master/16/consoleFull and https://ci.jenkins.io/job/Packaging/job/packaging/job/PR-248/4/consoleFull

fatal: [opensuse-leap-15]: FAILED! => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3.6"}, "changed": false, "msg": "Unable to start service jenkinstest: Job for jenkinstest.service failed because the control process exited with error code.\nSee \"systemctl status jenkinstest.service\" and \"journalctl -xe\" for details.\n"}

Anything else?

I can't reproduce the failure locally, and it often passes in re-runs on CI.

Package jenkinstest created, documentation not clear how to prevent this

Describe your use-case which is not covered by existing documentation.

When "make rpm" is used to create an RPM for testing, this rpm has the suffix "test" on the package name, directories, etc.

This in turn breaks external integration with jenkins that needs to be tested.

The README.md file needs to be updated to be clear how to turn the "test" suffix off.

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

RPM artifact names do not make much sense

Jenkins and plugins versions report

Environment

N/A

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 22.04.1 LTS x86_64

Reproduction steps

Visit https://ci.jenkins.io/job/Packaging/job/packaging/job/master/lastSuccessfulBuild/ and look at the names of the build artifacts.

Expected Results

The names shouldn't have the logical flaws described below in the Actual Results section.

Actual Results

This repository produces three (3) artifacts, e.g.

  • jenkins_2.373_all.deb
  • jenkins-2.373-1.1.noarch.rpm
  • jenkins-2.373-1.2.noarch.rpm

The first of these is obviously a Debian package, but it is not obvious that the second is for Red Hat systems and the third is for openSUSE systems, resulting in awkward downstream workarounds like https://github.com/jenkinsci/jenkins/blob/47322f3da67d29380ec7f16381f32d1f0cf9472f/.github/workflows/publish-release-artifact.yml#L201-L202. Furthermore, the version numbers "1.1" and "1.2" make no sense: why would the same source code yield two different versions?

Anything else?

No response

Problem on package with postinstall script

Jenkins and plugins versions report

Environment
Jenkins: 2.361.4
OS: Linux - 5.4.0-1089-aws
---
PrioritySorter:4.1.0
ace-editor:1.1
additional-metrics:45.vc0cdf94c7d5b_
analysis-model-api:10.20.0
ant:481.v7b_09e538fcca
antisamy-markup-formatter:155.v795fb_8702324
apache-httpcomponents-client-4-api:4.5.13-138.v4e7d9a_7b_a_e61
atlassian-jira-software-cloud:2.0.7
authentication-tokens:1.4
authorize-project:1.4.0
aws-credentials:191.vcb_f183ce58b_9
aws-global-configuration:106.v106dc1d8d86e
aws-java-sdk:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-cloudformation:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-codebuild:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-ec2:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-ecr:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-ecs:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-efs:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-elasticbeanstalk:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-iam:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-logs:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-minimal:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-sns:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-sqs:1.12.287-357.vf82d85a_6eefd
aws-java-sdk-ssm:1.12.287-357.vf82d85a_6eefd
awseb-deployment-plugin:0.3.21
bitbucket-oauth:0.12
bitbucket-push-and-pull-request:2.8.3
blueocean:1.25.8
blueocean-autofavorite:1.2.5
blueocean-bitbucket-pipeline:1.25.8
blueocean-commons:1.25.8
blueocean-config:1.25.8
blueocean-core-js:1.25.8
blueocean-dashboard:1.25.8
blueocean-display-url:2.4.1
blueocean-events:1.25.8
blueocean-git-pipeline:1.25.8
blueocean-github-pipeline:1.25.8
blueocean-i18n:1.25.8
blueocean-jwt:1.25.8
blueocean-personalization:1.25.8
blueocean-pipeline-api-impl:1.25.8
blueocean-pipeline-editor:1.25.8
blueocean-pipeline-scm-api:1.25.8
blueocean-rest:1.25.8
blueocean-rest-impl:1.25.8
blueocean-web:1.25.8
bootstrap4-api:4.6.0-5
bootstrap5-api:5.2.1-3
bouncycastle-api:2.26
branch-api:2.1051.v9985666b_f6cc
build-monitor-plugin:1.13+build.202205140447
build-name-setter:2.2.0
build-pipeline-plugin:1.5.8
build-timeout:1.24
build-token-root:151.va_e52fe3215fc
caffeine-api:2.9.3-65.v6a_47d0f4d1fe
checks-api:1.8.0
cloudbees-bitbucket-branch-source:791.vb_eea_a_476405b
cloudbees-folder:6.758.vfd75d09eea_a_1
command-launcher:90.v669d7ccb_7c31
commons-lang3-api:3.12.0-36.vd97de6465d5b_
commons-text-api:1.10.0-27.vb_fa_3896786a_7
compress-buildlog:1.2
conditional-buildstep:1.4.2
config-file-provider:3.11.1
copyartifact:1.47
crap4j:0.9
credentials:1189.vf61b_a_5e2f62e
credentials-binding:523.vd859a_4b_122e6
dashboard-view:2.466.vdfefd95a_b_f8d
data-tables-api:1.12.1-4
display-url-api:2.3.6
docker-commons:1.21
docker-workflow:528.v7c193a_0b_e67c
dtkit-api:3.0.2
durable-task:501.ve5d4fc08b0be
echarts-api:5.4.0-1
embeddable-build-status:304.vdcf48d6b_d2eb
envinject:2.881.v37c62073ff97
envinject-api:1.199.v3ce31253ed13
extended-read-permission:3.2
external-monitor-job:203.v683c09d993b_9
favorite:2.4.1
font-awesome-api:6.2.0-3
forensics-api:1.16.0
git:4.13.0
git-changelog:3.25
git-client:3.13.0
git-forensics:1.11.0
git-server:99.va_0826a_b_cdfa_d
github:1.36.0
github-api:1.303-400.v35c2d8258028
github-branch-source:1696.v3a_7603564d04
handlebars:3.0.8
handy-uri-templates-2-api:2.1.8-22.v77d5b_75e6953
htmlpublisher:1.31
instance-identity:116.vf8f487400980
ionicons-api:31.v4757b_6987003
jackson2-api:2.13.4.20221013-295.v8e29ea_354141
jakarta-activation-api:2.0.1-2
jakarta-mail-api:2.0.1-2
javadoc:226.v71211feb_e7e9
javax-activation-api:1.2.0-5
javax-mail-api:1.6.2-8
jaxb:2.3.7-1
jdepend:1.3.1
jdk-tool:63.v62d2fd4b_4793
jenkins-design-language:1.25.8
jjwt-api:0.11.5-77.v646c772fddb_0
jnr-posix-api:3.1.16-1
job-dsl:1.81
jobConfigHistory:1176.v1b_4290db_41a_5
jquery:1.12.4-1
jquery-detached:1.2.1
jquery3-api:3.6.1-2
jsch:0.1.55.61.va_e9ee26616e7
junit:1160.vf1f01a_a_ea_b_7f
last-changes:2.7.11
ldap:2.12
lockable-resources:1069.v726298f53f8c
mailer:438.v02c7f0a_12fa_4
mapdb-api:1.0.9-28.vf251ce40855d
matrix-auth:3.1.5
matrix-project:785.v06b_7f47b_c631
maven-plugin:3.20
mercurial:1260.vdfb_723cdcc81
mina-sshd-api-common:2.9.2-50.va_0e1f42659a_a
mina-sshd-api-core:2.9.2-50.va_0e1f42659a_a
momentjs:1.1.1
monitoring:1.91.0
nodejs:1.5.1
okhttp-api:4.9.3-108.v0feda04578cf
pam-auth:1.10
parameterized-trigger:2.45
pipeline-build-step:2.18
pipeline-github-lib:38.v445716ea_edda_
pipeline-graph-analysis:195.v5812d95a_a_2f9
pipeline-groovy-lib:621.vb_44ce045b_582
pipeline-input-step:456.vd8a_957db_5b_e9
pipeline-milestone-step:101.vd572fef9d926
pipeline-model-api:2.2118.v31fd5b_9944b_5
pipeline-model-definition:2.2118.v31fd5b_9944b_5
pipeline-model-extensions:2.2118.v31fd5b_9944b_5
pipeline-rest-api:2.27
pipeline-stage-step:296.v5f6908f017a_5
pipeline-stage-tags-metadata:2.2118.v31fd5b_9944b_5
pipeline-stage-view:2.27
plain-credentials:139.ved2b_9cf7587b
plot:2.1.11
plugin-util-api:2.18.0
popper-api:1.16.1-3
popper2-api:2.11.6-2
preSCMbuildstep:36.vca_61785795a_2
prism-api:1.29.0-1
publish-over:0.22
pubsub-light:1.17
rebuild:1.34
resource-disposer:0.20
role-strategy:569.v7476f8e4fe29
run-condition:1.5
s3:0.12.3436.v674b_46258039
scm-api:621.vda_a_b_055e58f7
scmskip:1.0.3
script-security:1218.v39ca_7f7ed0a_c
simple-theme-plugin:136.v23a_15f86c53d
slack:631.v40deea_40323b
snakeyaml-api:1.33-90.v80dcb_3814d35
sse-gateway:1.26
ssh-agent:295.v9ca_a_1c7cc3a_a_
ssh-credentials:305.v8f4381501156
ssh-slaves:2.854.v7fd446b_337c9
sshd:3.249.v2dc2ea_416e33
structs:324.va_f5d6774f3a_d
subversion:2.16.0
thinBackup:1.13
throttle-concurrents:2.10
timestamper:1.21
token-macro:321.vd7cc1f2a_52c8
trilead-api:2.84.v72119de229b_7
variant:59.vf075fe829ccb
warnings-ng:9.20.1
workflow-aggregator:590.v6a_d052e5a_a_b_5
workflow-api:1200.v8005c684b_a_c6
workflow-basic-steps:994.vd57e3ca_46d24
workflow-cps:3536.vb_8a_6628079d5
workflow-durable-task-step:1217.v38306d8fa_b_5c
workflow-job:1254.v3f64639b_11dd
workflow-multibranch:716.vc692a_e52371b_
workflow-scm-step:400.v6b_89a_1317c9a_
workflow-step-api:639.v6eca_cd8c04a_a_
workflow-support:839.v35e2736cfd5c
ws-cleanup:0.43
xunit:3.1.2

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 18.04.1

Reproduction steps

Open the terminal, switch to sudo and run command
apt-get update

Expected Results

updating Jenkins to version 2.361.4

Actual Results

Setting up jenkins (2.361.4) ...
/var/lib/dpkg/info/jenkins.postinst: 29: /var/lib/dpkg/info/jenkins.postinst: getent: not found
/var/lib/dpkg/info/jenkins.postinst: 30: /var/lib/dpkg/info/jenkins.postinst: addgroup: not found
dpkg: error processing package jenkins (--configure):
installed jenkins package post-installation script subprocess returned error exit status 127

Anything else?

This happened in the previous 4-5 versions before it was OK.
I have user Jenkins and group Jenkins and if I run the commands manually from script file it works and shows output
Using war with ubuntu package.

Diagnostic message "no matches found: [signed-by=/usr/share/keyrings/jenkins-keyring.asc]" following installation instructions

When following the (current) installation instructions on https://pkg.jenkins.io/debian/ a diagnostic message is given:

no matches found: [signed-by=/usr/share/keyrings/jenkins-keyring.asc]

It is in the second installation step:

Then add a Jenkins apt repository entry:

  echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
    https://pkg.jenkins.io/debian binary/ | sudo tee \
    /etc/apt/sources.list.d/jenkins.list > /dev/null

The message stems from the shell expanding the glob expression (square brackets).

Jenkins and plugins versions report

Environment

Shell, Debian based system.

What Operating System are you using (both controller, and any agents involved in the problem)?

Irrelevant, this is before operating Jenkins on the system.

Reproduction steps

  1. Follow the installation instructions on a Debian based system
  2. Specifically the second one.

Expected Results

Command should not expand glob expression in square brackets.

Actual Results

Command expands glob expression in square brackets.

Anything else?

Originally reported in https://community.jenkins.io/t/venue-for-issue-patch-on-installation-instructions/13851

The diagnostic message given irritates users that copy and paste the installation instructions unmodified into their shell and submit the command.

Best practices should be followed which includes quoting parameters to prevent unintended glob expansion. Many interactive shells have the option to expand globs enabled by default.

Are you interested in contributing a fix?

Yes, already in preparation. Mark Waite already referenced the two repositories to apply changes to.

The systemd unit file does not define an optional EnvironmentFile

Jenkins and plugins versions report

rpm: jenkins-2.332.1-1.1.noarch

What Operating System are you using (both controller, and any agents involved in the problem)?

CentOS 7

Reproduction steps

The easiest example of this regression is:

  1. Install Jenkins from http://pkg.jenkins.io/redhat-stable
  2. Modify JENKINS_ARGS in /etc/sysconfig/jenkins
  3. Restart jenkins
  4. Run ps auxfww and note that jenkins does not have JENKINS_ARGS appended.

Expected Results

Jenkins use the EnvironmentFile option in its systemd unit file jenkins.service to optionally load /etc/sysconfig/jenkins (and all other vendor supported environment file locations).

Actual Results

  • After modifying /etc/sysconfig/jenkins none of the alterations I made are used.
    • Jenkins continues to start on port 8080 despite setting JENKINS_PORT in /etc/sysconfig/jenkins
    • Jenkins is not started with JENKINS_ARGS

Anything else?

The default systemd unit should never be hand modified, so to temporarily get around this issue I created /etc/systemd/system/jenkins.service.d/override.conf with the content of:

[Service]
EnvironmentFile=-/etc/sysconfig/jenkins

I do not consider that creating an override file is a fix and am using it only a work around.

See EnvironmentFile under https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment

The argument passed should be an absolute filename or wildcard expression, optionally prefixed with "-", which indicates that if the file does not exist, it will not be read and no error or warning message is logged.

EnvironmentFile can be specified multiple times to ensure that all locations on all distributions can be used; i.e.

[Service]
EnvironmentFile=-/etc/sysconfig/jenkins
EnvironmentFile=-/etc/default/jenkins

I created this ticket as a bug because it's a regression from previous releases and modifying the environment file does nothing to modify Jenkins when it's started.

Pin and automatically update Python dependencies

What feature do you want to see added?

As was pointed out in #353 the dependencies in requirements.txt are not installed deterministically nor updated automatically. The principle of reproducible builds dictates that dependencies should be installed deterministically, and the principle of software maintenance dictates that these dependencies be updated periodically, ideally automatically.

Upstream changes

No response

Link to install documentation instead of providing an incomplete copy

What feature do you want to see added?

The installation instructions on the pkg and mirror sites like:

are brief summaries of the more detailed instructions provided in the Linux section of the Installing chapter of the Jenkins User Handbook.

Those brief summaries lack the detailed information provided in the Linux section about Java requirements, hardware requirements, and operating system requirements. The brief summary of the Red Hat Enterprise Linux instructions recommends the rpm tool even though dnf is the default package manager on Fedora Linux. The brief summary of the Red Hat Enterprise Linux instructions uses an incorrect spelling ("Redhat") to refer to Red Hat Enterprise Linux and its derivatives. The brief summary of the Red Hat Enterprise Linux instructions does not mention the service control commands that are needed to start the service and enable the service.

Rather than having a brief and incomplete summary of the installation instructions on those the pkg and mirrors pages, I think that we should make the pkg and mirrors pages redirect to the jenkins.io site. A link already exists at the end of each of the pages, but making them redirect to the installation pages will take readers to the most complete instructions that we offer.

Upstream changes

No response

Cannot override systemd AmbientCapabilities

Jenkins and plugins versions report

With #285, Jenkins got support on systemd with port numbers less than 1024.
When migrating over, I discovered setting the AmbientCapabilities in override.conf using systemctl edit jenkins does not work. I had to set it directly in the file jenkins.service, a file which should not be edited.

What Operating System are you using (both controller, and any agents involved in the problem)?

Linux

Reproduction steps

  1. Run systemctl edit jenkins
  2. Change JENKINS_HTTPS_PORT to 443 or JENKINS_PORT to 80
  3. Add Environment="AmbientCapabilities=CAP_NET_BIND_SERVICE"

Expected Results

Jenkins running on port 443/80

Actual Results

2022-03-11 09:55:00.419+0000 [id=1] SEVERE winstone.Logger#logInternal: Container startup failed
java.net.SocketException: Permission denied
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:455)
at java.base/sun.nio.ch.Net.bind(Net.java:447)
at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
at java.base/sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:80)
at org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:344)
Caused: java.io.IOException: Failed to bind to 0.0.0.0/0.0.0.0:443

Anything else?

No response

Generate pages independently of the release process

During the GPG update process, a few people have pointed out that the -stable pages have not been updated.

The current generation happens in indexGenerator.py, if a weekly or LTS release takes place. If there is no release, the pages don't update.

I recommend separating the current progress to allow maintaining and updating the pages independent of core builds, to communicate future changes on the -stable pages too.

Disable the ability to upgrade a Windows install with the installer

Dependencies

None

Feature Request

I think it would be good to disable upgrades using the MSI installer on Windows. Generally speaking the internal upgrade capability for the WAR file is preferred I think. The only thing I can think of that would be a possible reason to allow upgrade is for the service wrapper.

Any thoughts?

`indexGenerator.py` doesn't seem to update `-stable` directories

Jenkins and plugins versions report

n/a

What Operating System are you using (both controller, and any agents involved in the problem)?

n/a

Reproduction steps

  1. Notice how https://get.jenkins.io/war/ and https://get.jenkins.io/war-stable/ look wildly different
  2. Look at https://github.com/jenkinsci/packaging/blob/e8fa928d2fdc8058ecc8fdbdec5aae4cb2a9bead/bin/indexGenerator.py and various publish.sh scripts
  3. Realize we're probably not generating -stable index pages

Expected Results

  1. Regular and -stable index pages to be largely in sync
  2. Weekly Java requirements on the weekly page, LTS Java requirements on the -stable index page.

Actual Results

  • Information on LTS pages is outdated
  • Weekly pages confusingly have both LTS and weekly Java requirements documented

Anything else?

No response

CentOS Stream 9 fails to import test key

Jenkins and plugins versions report

Environment
Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

CentOS Stream 9

Reproduction steps

Run the Molecule tests against CentOS Stream 9, or more succinctly:

$ docker pull dokken/centos-stream-9:latest
$ docker run -v $PWD/credentials:/credentials --rm -it dokken/centos-stream-9:latest /bin/bash
# rpm --import /credentials/test.ascii.key 

Expected Results

The test key is imported successfully. With OpenSSL 3.0.1-5.el9 (installed with dnf downgrade openssl), the import succeeds:

# rpm --import /credentials/test.ascii.key 
#

Actual Results

With OpenSSL 3.0.1-12.el9, the key import fails:

# rpm --import /credentials/test.ascii.key 
error: /credentials/test.ascii.key: key 1 import failed.

Anything else?

Need to investigate why the test key cannot be imported with recent versions of OpenSSL. Is this an upstream regression that might be fixed in a future release of the OpenSSL package? Or is this a breaking change to which we need to adapt our test key?

Also note that I tested our production key with rpm --import https://pkg.jenkins.io/redhat/jenkins.io.key, and I was able to import it successfully with both OpenSSL 3.0.1-5.el9 and 3.0.1-12.el9.

Add MSI build to `Jenkinsfile`

What feature do you want to see added?

Currently, the Jenkinsfile used for PRs to this repository builds the Linux packages but not the MSI. This incomplete build coverage can be corrected by adding a new parallel stage to the Jenkinsfile that runs the MSI build in a Windows container, using the same pod template and Pipeline Groovy logic used in the official release process.

CC @dduportal @MarkEWaite

Upstream changes

No response

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

regex
templates/base.html
  • @webcomponents/webcomponentsjs 2.8.0
templates/base.html
  • lit 3.2.0

  • Check this box to trigger a request for Renovate to run again on this repository

windows setup and comma in local password account

Jenkins and plugins versions report

Environment
Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

WINDOWS 10

Reproduction steps

  • local user's password with a comma
  • start the installation
  • Enter the credentials : test passed
  • press on continue button

Expected Results

  • the jenkins service should be started
  • the installation should continue

Actual Results

  • error message and the installation process can't continue
  • you get an error message when the service is start manually from the windows service manager.

Anything else?

The installation fails on WINDOWS if the local user's password contains a comma (this is my case).

The test credantials function works but the service does not start and the installation procedure cannot continue.

The user's password must be retyped in the Jenkins service settings for the service to start.

I already saw the problem in previous release.

Automated testing

What feature do you want to see added?

This repository lacks a Jenkinsfile or any CI/CD. This makes it all too easy for regressions to be introduced. As a result, this repository resists change. In order to move forward with critical modernization efforts such as systemd(1) support, a prerequisite task is adding test coverage to this repository. Once there is test coverage, we will be able to make major changes with confidence that we are not introducing regressions.

Upstream changes

No response

Current documentation does not work for me despite using Docker

Describe your use-case which is not covered by existing documentation.

Hi there ๐Ÿ‘‹

I have started to modify the documentation in the hope of submitting a PR shortly.
I am using docker as it is the only supported platform.

Following the existing documentation, after setting the WAR and JENKINS_URL environment variables

(not necessary if I read correctly the docker-compose.yaml
- "WAR=/srv/releases/jenkins/jenkins.war"

, I launch ./prep.sh. Unfortunately, ./prep.sh does not work for me inside this container:

jenkins@420db984a78b:/srv/releases/jenkins$ ./prep.sh
: invalid option

make setup does not work either with the same kind of error:

make setup
bash -ex -c 'for f in */setup.sh; do $f; done'
+ for f in */setup.sh
+ deb/setup.sh
: invalid option
make: *** [Makefile:24: setup] Error 1

bash -x prep.sh outputs:

+ set -o $'pipefail\r'
: invalid option name pipefail
++ dirname prep.sh
+ cd $'.\r'
prep.sh: line 3: cd: $'.\r': No such file or directory
+ $'\r'
prep.sh: line 4: $'\r': command not found
+ $'\r'
prep.sh: line 10: $'\r': command not found
prep.sh: line 21: syntax error: unexpected end of file

Apparently, pipefail is a bashism, but we're using bash, aren't we? Furthermore, are these files Windows encoded?

I would have like to debug by modifying the script files, but there is no editor bundled in the image (as far as I know).
Would anyone have a hint to get me out of the rut?

Here is the complete set of environment variables, just in case:

BASH=/usr/bin/bash
BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:globasciiranges:histappend:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=([0]="0")
BASH_ARGV=()
BASH_CMDS=()
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]="5" [1]="1" [2]="16" [3]="1" [4]="release" [5]="x86_64-pc-linux-gnu")
BASH_VERSION='5.1.16(1)-release'
BRAND=/srv/releases/jenkins/branding/jenkins.mk
BRANDING_DIR=/srv/releases/jenkins/branding
BUILDENV=/srv/releases/jenkins/env/test.mk
COLUMNS=230
DEBIAN_FRONTEND=noninteractive
DIRSTACK=()
EUID=1000
GPG_FILE=/srv/releases/jenkins/credentials/sandbox.gpg
GPG_KEYNAME=551F7B8423F34E8A1E9EEE1B3DD66EC9C147FCD1
GPG_PASSPHRASE=s3cr3t
GPG_PASSPHRASE_FILE=/srv/releases/jenkins/credentials/test.gpg.password.txt
GROUPS=()
HISTCONTROL=ignoreboth
HISTFILE=/home/jenkins/.bash_history
HISTFILESIZE=2000
HISTSIZE=1000
HOME=/home/jenkins
HOSTNAME=420db984a78b
HOSTTYPE=x86_64
IFS=$' \t\n'
JAVA_HOME=/opt/jdk-8
JENKINS_URL=http://192.168.0.144:8080/
LANG=C.UTF-8
LINES=66
LS_COLORS='rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:'
MACHTYPE=x86_64-pc-linux-gnu
MAILCHECK=60
MSI=/srv/releases/jenkins/jenkins.msi
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/opt/jdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PIPESTATUS=([0]="0")
PPID=0
PS1='\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
PS2='> '
PS4='+ '
PWD=/srv/releases/jenkins
RELEASELINE=-experimental
SHELL=/bin/sh
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
SHLVL=1
TERM=xterm
TZ=UTC
UID=1000
USER=jenkins
WAR=/srv/releases/jenkins/jenkins.war

Thanks.

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

Native package script for Jenkins

This repository contains scripts for packaging jenkins.war into various platform-specific native packages.
The following platforms are currently supported:

  • Windows MSI: msi/
  • RedHat/CentOS RPM: rpm/
  • Debian/Ubuntu DEB: deb/
  • OpenSUSE RPM: suse/

Pre-requisites

Running the main package script requires a Ubuntu Linux 18.04 environment (see JENKINS-27744.)

Remark:
A docker image is available to run the following scripts. It's the only supported environment.

logo

Run docker-compose run --rm packaging bash to get a shell in the official Docker image for this repository.

Workaround

If your machine doesn't run this mandatory version of Ubuntu Linux, you can use these scripts within a VM or with the provided Docker image. The use of the Docker image is not compulsory but any other environment is not supported.

Run make setup to install (most of the) necessary tools. Alternatively you can manually install the following onto a base install of Ubuntu:

  • make
  • unzip
  • devscripts
  • debhelper
  • rpm
  • expect
  • createrepo
  • ruby
    • net-sftp (gem install net-sftp)
  • maven
  • java

You will also need a Jenkins instance with dist-fork plugin
installed. The URL of this Jenkins can be fed into make via the JENKINS_URL variable.
If you want to package for Windows, this Jenkins controller needs to have a Windows build agent that has WiX Toolset (currently 3.5), msbuild, cygwin and .net 2.0. This build agent is used to build MSI packages, which
can be only built on Windows.

You'll also need:

  • a jenkins.war file that you are packaging, which comes from the release process.
    The location of this file is set via the WAR variable.
  • a jenkins.msi file if you are packaging for Windows, which also comes from the release process.
Download and reference `jenkins.war`

curl https://get.jenkins.io/war-stable/2.332.3/jenkins.war --output jenkins.war
# or  jv download
export WAR=/srv/releases/jenkins/jenkins.war
# if you want to build for windows
curl https://get.jenkins.io/windows-stable/2.332.3/jenkins.msi --output jenkins.msi
export MSI=/srv/releases/jenkins/jenkins.msi

Generating packages

Run ./prep.sh to perform the preparatory actions of downloading the WAR and importing the GPG key.
Run make package to build all the native packages.
At minimum, you have to specify the WAR variable that points to the war file to be packaged and a branding file (for licensing and package descriptions).
You will probably need to pass in the build environment and credentials.

For example:

make package BRAND=./branding/jenkins.mk BUILDENV=./env/test.mk CREDENTIAL=./credentials/test.mk

Packages will be placed into target/ directory.
See the definition of the package goal for how to build individual packages selectively.

Running functional tests

The functional tests require Python 3 and Docker.
Having built the packages as described above, run the functional tests with:

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
molecule test
deactivate

Publishing packages

This repository contains scripts for copying packages over to a remote web server to publish them.
Run make publish to publish all native packages.

See the definition of the publish goal for individual package publishment.

Running local tests

These tests install packages from a web server where they are published. So if you want to
run tests prior to publishing them, you need to create a temporary web server that you can mess up.

The default branding & environment (branding/test.mk and env/test.mk) are designed to support
this scenario. To make local testing work, you also need to have /etc/hosts entry that maps
test.pkg.jenkins.io hostname to 127.0.0.1, and your computer has to be running ssh that
lets you login as you.

Once you verified the above prerequisites, open another terminal and run make test.local.setup
This will run a docker container that acts as your throw-away package web server. When done, Ctrl+C
to kill it.

Branding

branding/ directory contains *.mk files that control the branding of the generated packages.
It also include text files which are used for large, branded text blocks (license and descriptions).
Specify the branding file via the BRAND variable.

You can create your own branding definition to customize the package generation process.
See branding readme for more details. In the rest of the packaging script files,
these branding parameters are referenced via @@NAME@@ and get substituted by bin/branding.py.
To escape a string normally like @@value@@, add an additional two @@ symbols as a prefix: @@@@value@@.

Environment

env/ directory contains *.mk files that control the environment into which
you publish packages. Specify the environment file via the BUILDENV variable.

You can create your own environment definition to customize the package generation process.
See environment readme for more details.

Credentials

credentials/ directory contains test.mk file that controls the locations of code-signing keys,
their passwords, and certificates. Specify the credentials file via the CREDENTIAL variable.

For production use, you need to create your own credentials file. See credentials readme
for more details.

TODO (mostly note to myself)

  • Split resource templates to enable customization

Systemd start script: allow * from JAVA_OPTS to be passed to the Jenkins process (escaping in eval)

What feature do you want to see added?

The Jenkins start script accidentally expands * (to all files in the working directory) originating from an environment variable with its eval.

This lead to a 500 error, when opening a file from the directory browser:

Error while serving https://qa-hidrive.de/job/XXXXX/XXXXX/Report.html
org.eclipse.jetty.http.BadMessageException: 500: Response header too large
    at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:768)
    at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241)
    at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:223)
    at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:550)
    at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:910)
    at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:987)
    at org.eclipse.jetty.server.HttpOutput.channelWrite(HttpOutput.java:285)
    at org.eclipse.jetty.server.HttpOutput.channelWrite(HttpOutput.java:269)
    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:869)
    at com.jcraft.jzlib.DeflaterOutputStream.deflate(DeflaterOutputStream.java:144)
    at com.jcraft.jzlib.DeflaterOutputStream.write(DeflaterOutputStream.java:102)
    at org.kohsuke.stapler.compression.FilterServletOutputStream.write(FilterServletOutputStream.java:41)
    at org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.write(OnCommittedResponseWrapper.java:638)
    at org.kohsuke.stapler.Stapler.serveStaticResource(Stapler.java:628)
    at org.kohsuke.stapler.ResponseImpl.serveFile(ResponseImpl.java:231)
    at hudson.model.DirectoryBrowserSupport.serveFile(DirectoryBrowserSupport.java:415)
    at hudson.model.DirectoryBrowserSupport.generateResponse(DirectoryBrowserSupport.java:164)
    at htmlpublisher.HtmlPublisherTarget$BaseHTMLAction.doDynamic(HtmlPublisherTarget.java:275)
    at htmlpublisher.HtmlPublisherTarget$HTMLAction.doDynamic(HtmlPublisherTarget.java:283)
    at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
    at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:398)
Caused: java.lang.reflect.InvocationTargetException
    at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:402)
    at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:410)
    ...

This is what we had in the config initially:

cat /etc/systemd/system/jenkins.service.d/override.conf 
[Service]
Environment="JAVA_OPTS=-Djava.awt.headless=true \"-Dhudson.model.DirectoryBrowserSupport.CSP=sandbox allow-same-origin allow-scripts; default-src 'self'; script-src * 'unsafe-eval'; img-src *; style-src * 'unsafe-inline'; font-src *;\""

This is what the process command looked like:

jenkins    22175       1 99 17:32 ?        00:00:16 /usr/bin/java -Djava.awt.headless=true -Dhudson.model.DirectoryBrowserSupport.CSP=sandbox allow-same-origin allow-scripts; default-src 'self'; script-src Report browserstack-id.txt caches com.browserstack.automate.ci.jenkins.BrowserStackBuildWrapper.xml <<<... OMITTED A LOT OF OTHER SYSTEM FILES ...>>> workflow-libs workspace 'unsafe-eval'; img-src *; style-src Report browserstack-id.txt caches com.browserstack.automate.ci.jenkins.BrowserStackBuildWrapper.xml <<<... OMITTED A LOT OF OTHER SYSTEM FILES ...>>> workflow-libs workspace 'unsafe-inline'; font-src *; -jar /usr/share/java/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --httpListenAddress=127.0.0.1

Initially I did not recognized this as an error until I compared that with the command, when the CSP config was absent:

jenkins    28509       1  8 09:26 ?        00:00:59 /usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --httpListenAddress=127.0.0.1

Now I understood * was expanded by the shell, so the CSP system property no longer contained the * but a lot of filenames from the working directory.

This is a MCVE for the underlying problem:

$ foo="\"a * b\"" ; eval echo ${foo}
a file-1.txt file-2 b
$ foo="\"a \* b\"" ; eval echo ${foo}
a \* b
$ foo="a \* b" ; eval echo ${foo}
a * b

$ foo="a * b" ; eval echo "${foo}"
a file-1.txt file-2 b
$ foo="\"a * b\"" ; eval echo "${foo}"
a * b

Although we probably stick with enumerating the actual domains instead of using *, I though you want to fix this.

This is a proposed fix:

--- /usr/bin/jenkins    2022-04-01 13:17:00.122267704 +0200
+++ /usr/bin/jenkins    2022-04-01 13:21:42.354954818 +0200
@@ -148,7 +148,7 @@
    unset JENKINS_WEBROOT
    eval exec \
        "${java_cmd}" \
-       ${java_opts_tmp} \
+       "${java_opts_tmp}" \
        -jar "${jenkins_war_tmp}" \
        ${inferred_jenkins_opts}
 }

This is the current Jenkins version:

$ sudo dpkg --list | grep 'jenkins'
ii  jenkins                               2.332.1                            all          Jenkins is an ...

Upstream changes

None.

`createrepo` doesn't exist in Ubuntu `20.04`

What feature do you want to see added?

I read in the README.md that

Running the main package script requires a Linux environment (currently Ubuntu)

I can also read that:

Alternatively you can manually install the following onto a base install of Ubuntu:
[...]
createrepo

The thing is createrepo disappeared in Ubuntu 20.04 and reappeared in another form in Ubuntu 21.04. It's now another package named createrepo-c because it has been rewritten in C.

Could we add the detection of the Ubuntu version we're running on, so that we can add the correct package?

I will make a PR to propose a draft bash implementation of the detection, and another one with the modified documentation.

Upstream changes

No response

Enumerate test scenarios

Describe your use-case which is not covered by existing documentation.

Currently the automated tests for this repository just install the .deb or .rpm package by filename, verify that the service started, verify that Jenkins is serving HTTP requests, and verify that the service stops. This is a good start, but it is not a comprehensive set of test scenarios.

This task covers enumerating all scenarios that need automated testing to prevent regressions. Off the top of my head I can think of the following:

  • Installing from HTTP rather than by raw .deb or .rpm, including GPG key checks
  • Configuring SSL/TLS

If there are additional scenarios to be tested, please enumerate them here.

CC @MarkEWaite

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

Installing on Windows using Java 21 as `JAVA_HOME` occasionally fails

Jenkins and plugins versions report

N/A

What Operating System are you using (both controller, and any agents involved in the problem)?

Windows 11, version 22H2 (OS Build 22621.2134)
OpenJDK 21, Build 35 (2023/8/11)
Jenkins 2.418

Reproduction steps

Set Java 21 as your JAVA_HOME and install Jenkins using the .msi

Expected Results

The installer installs Jenkins properly at anytime.

Actual Results

Occasionally, the installer becomes unresponsive at step Starting services Service: [1].

Anything else?

I cannot reproduce this issue constantly, sometimes it stalls, and sometimes it just takes longer than usual.

Debian packaging puts the PID file in an odd place

Jenkins and plugins versions report

Environment
Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu Jammy Jellyfish (development branch) x86_64

Reproduction steps

Build the package with:

$ docker-compose run --rm packaging bash
$ ./prep.sh
$ make package

Then set up a virtual environment and run Molecule:

$ python3 -m venv venv
$ . venv/bin/activate
$ pip install -U pip wheel
$ pip install -r requirements.txt
$ molecule create && molecule converge

Log in to the Ubuntu VM and list PID files:

$ molecule login --host ubuntu-22-04
$ systemctl start jenkinstest.service
$ ls -la /var/run/**/*.pid

Expected Results

The PID file should be in /var/run, like all the other Ubuntu PID files and the Jenkins PID file on RPM-based systems.

Actual Results

The PID file is in /var/run/jenkins, which is inconsistent with other Ubuntu PID files and the Jenkins PID file on RPM-based systems.

Anything else?

Fixing this needs to take into account the migration case where an existing installation has a PID file in the old location.

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Location: .github/renovate.json
Error type: Duplicate keys in JSON
Message: "Syntax error: duplicated keys \"packageRules\" near ules\": [\n "

Master branch builds are failing (currently mitigated)

The latest build on the master branch failed, I verified the failure with an empty PR; #341

I don't think the failures affect the release process, given 2.371 released without packaging issues.

19:54:12  TASK [Wait for instance(s) creation to complete] *******************************
19:54:12  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:12  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:12  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:12  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:13  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:13  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:13  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:13  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:13  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:14  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:14  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:14  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:14  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:15  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:15  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:15  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:15  failed: [localhost] (item=None) => {"attempts": 1, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:15  fatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}
19:54:15  
19:54:15  PLAY RECAP *********************************************************************
19:54:15  localhost                  : ok=8    changed=4    unreachable=0    failed=1    skipped=2    rescued=0    ignored=0
19:54:15  
19:54:15  WARNING  Retrying execution failure 2 of: ansible-playbook --inventory /home/jenkins/.cache/molecule/Packaging_packaging_PR-341/default/inventory --skip-tags molecule-notest,notest /home/jenkins/workspace/Packaging_packaging_PR-341/venv/lib/python3.8/site-packages/molecule_docker/playbooks/create.yml
19:54:15  CRITICAL Ansible return code was 2, command was: ['ansible-playbook', '--inventory', '/home/jenkins/.cache/molecule/Packaging_packaging_PR-341/default/inventory', '--skip-tags', 'molecule-notest,notest', '/home/jenkins/workspace/Packaging_packaging_PR-341/venv/lib/python3.8/site-packages/molecule_docker/playbooks/create.yml']
19:54:15  WARNING  An error occurred during the test sequence action: 'create'. Cleaning up.
19:54:15  INFO     Running default > cleanup
19:54:15  WARNING  Skipping, cleanup playbook not configured.
19:54:15  INFO     Running default > destroy

Jenkins Windows Packages documentation is outdated.

Describe your use-case which is not covered by existing documentation.

The Jenkins Windows Packages suggest using wget and points to a not existing key file. As I think the instruction is not for the WSL this block could be completely removed,

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

Test on Fedora 40

What feature do you want to see added?

Currently, we're testing Fedora 37 only when 40 is already available.

Upstream changes

No response

APT key exired on 2023-03-30

The GPG key used to sign the Debian package repo has expired:

Err:9 https://pkg.jenkins.io/debian-stable binary/ Release.gpg
  The following signatures were invalid: EXPKEYSIG FCEF32E745F2C3D5 Jenkins Project <[email protected]>
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://pkg.jenkins.io/debian-stable binary/ Release: The following signatures were invalid: EXPKEYSIG FCEF32E745F2C3D5 Jenkins Project <[email protected]>
W: Failed to fetch https://pkg.jenkins.io/debian-stable/binary/Release.gpg  The following signatures were invalid: EXPKEYSIG FCEF32E745F2C3D5 Jenkins Project <[email protected]>
W: Some index files failed to download. They have been ignored, or old ones used instead.
$ wget https://pkg.jenkins.io/debian-stable/jenkins.io.key -P /tmp/
$ gpg /tmp/jenkins.io.key 
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa4096 2020-03-30 [SC] [expired: 2023-03-30]
      62A9756BFD780C377CF24BA8FCEF32E745F2C3D5
uid           Jenkins Project <[email protected]>
sub   rsa4096 2020-03-30 [E] [expired: 2023-03-30]

Test on Debian 12

What feature do you want to see added?

Currently, we're testing Debian 10 and 11 only when 12 is already available.

Upstream changes

No response

jenkins.tmpfiles missing from Debian package

Jenkins and plugins versions report

Environment
Jenkins: 2.440.2
OS: Linux - 6.1.0-18-amd64
Java: 17.0.10 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)
---
Office-365-Connector:4.21.0
amazon-ecr:1.114.vfd22430621f5
analysis-model-api:12.1.0
ansicolor:1.0.4
antisamy-markup-formatter:162.v0e6ec0fcfcf6
apache-httpcomponents-client-4-api:4.5.14-208.v438351942757
asm-api:9.6-3.v2e1fa_b_338cd7
authentication-tokens:1.53.v1c90fd9191a_b_
aws-credentials:218.v1b_e9466ec5da_
aws-java-sdk-ec2:1.12.671-439.veec746c91fcb_
aws-java-sdk-ecr:1.12.671-439.veec746c91fcb_
aws-java-sdk-minimal:1.12.671-439.veec746c91fcb_
azure-ad:457.vf85d61f83b_26
azure-sdk:157.v855da_0b_eb_dc2
bootstrap5-api:5.3.3-1
bouncycastle-api:2.30.1.77-225.v26ea_c9455fd9
branch-api:2.1152.v6f101e97dd77
build-monitor-plugin:1.14-860.vd06ef2568b_3f
build-user-vars-plugin:1.9
buildtriggerbadge:251.vdf6ef853f3f5
caffeine-api:3.1.8-133.v17b_1ff2e0599
checks-api:2.0.2
cloudbees-folder:6.901.vb_4c7a_da_75da_3
commons-lang3-api:3.13.0-62.v7d18e55f51e2
commons-text-api:1.11.0-95.v22a_d30ee5d36
compact-columns:1.185.vf3851b_4d31fe
config-file-provider:968.ve1ca_eb_913f8c
copyartifact:722.v0662a_9b_e22a_c
coverage:1.13.0
credentials:1337.v60b_d7b_c7b_c9f
credentials-binding:657.v2b_19db_7d6e6d
customizable-header:83.vf51a_828deb_b_e
dark-theme:439.vdef09f81f85e
dashboard-view:2.508.va_74654f026d1
data-tables-api:2.0.2-1
database:230.v701f20b_8b_f95
database-postgresql:100.v2418e0a_c6909
display-url-api:2.200.vb_9327d658781
docker-commons:439.va_3cb_0a_6a_fb_29
docker-workflow:572.v950f58993843
downstream-build-cache:1.7
durable-task:550.v0930093c4b_a_6
echarts-api:5.5.0-1
email-ext:2.105
embeddable-build-status:467.v4a_954796e45d
extra-columns:1.26
favorite:2.208.v91d65b_7792a_c
flyway-api:9.22.3-75.vfdfb_f75a_a_9b_e
font-awesome-api:6.5.1-3
forensics-api:2.4.0
git:5.2.1
git-client:4.7.0
git-forensics:2.1.0
git-parameter:0.9.19
gitlab-api:5.3.0-91.v1f9a_fda_d654f
gitlab-branch-source:703.vc5fd7effcc6b_
gitlab-scm-filter-aged-refs:39.ve2e68cc3fa_78
groovy:457.v99900cb_85593
gson-api:2.10.1-15.v0d99f670e0a_7
handy-uri-templates-2-api:2.1.8-30.v7e777411b_148
htmlpublisher:1.33
instance-identity:185.v303dc7c645f9
ionicons-api:56.v1b_1c8c49374e
jackson2-api:2.17.0-379.v02de8ec9f64c
jakarta-activation-api:2.1.3-1
jakarta-mail-api:2.1.3-1
javadoc:243.vb_b_503b_b_45537
javax-activation-api:1.2.0-6
javax-mail-api:1.6.2-9
jaxb:2.3.9-1
jersey2-api:2.41-133.va_03323b_a_1396
jira:3.13
job-dsl:1.87
jobConfigHistory:1229.v3039470161a_d
joda-time-api:2.12.7-29.v5a_b_e3a_82269a_
jquery3-api:3.7.1-2
json-api:20240303-41.v94e11e6de726
json-path-api:2.9.0-52.v57de85cc4722
junit:1259.v65ffcef24a_88
junit-attachments:205.vc0677977deb_0
junit-sql-storage:282.v0b_9d0f91b_cec
kubernetes:4203.v1dd44f5b_1cf9
kubernetes-client-api:6.10.0-240.v57880ce8b_0b_2
kubernetes-credentials:0.11
lockable-resources:1246.v28b_e4cc6fa_16
mailer:472.vf7c289a_4b_420
mapdb-api:1.0.9-28.vf251ce40855d
matrix-auth:3.2.2
matrix-project:822.824.v14451b_c0fd42
metrics:4.2.21-449.v6960d7c54c69
mina-sshd-api-common:2.12.0-90.v9f7fb_9fa_3d3b_
mina-sshd-api-core:2.12.0-90.v9f7fb_9fa_3d3b_
next-executions:310.v52e770651319
okhttp-api:4.11.0-172.vda_da_1feeb_c6e
performance:957.v658a_7065b_92a_
pipeline-build-step:540.vb_e8849e1a_b_d8
pipeline-graph-analysis:216.vfd8b_ece330ca_
pipeline-graph-view:232.vc7ca_8d934725
pipeline-groovy-lib:704.vc58b_8890a_384
pipeline-input-step:491.vb_07d21da_1a_fb_
pipeline-maven:1390.v66456b_ea_3467
pipeline-maven-api:1390.v66456b_ea_3467
pipeline-maven-database:1390.v66456b_ea_3467
pipeline-model-api:2.2184.v0b_358b_953e69
pipeline-model-definition:2.2184.v0b_358b_953e69
pipeline-model-extensions:2.2184.v0b_358b_953e69
pipeline-rest-api:2.34
pipeline-stage-step:305.ve96d0205c1c6
pipeline-stage-tags-metadata:2.2184.v0b_358b_953e69
pipeline-stage-view:2.34
pipeline-utility-steps:2.16.2
plain-credentials:179.vc5cb_98f6db_38
platformlabeler:2325.v8f074df8840d
plugin-util-api:4.1.0
postgresql-api:42.7.2-40.v76d376d65c77
prism-api:1.29.0-13
role-strategy:713.vb_3837801b_8cc
s3:466.vf5b_3db_8e3eb_2
scm-api:689.v237b_6d3a_ef7f
script-security:1326.vdb_c154de8669
simple-theme-plugin:176.v39740c03a_a_f5
snakeyaml-api:2.2-111.vc6598e30cc65
sonar:2.17.2
ssh-agent:346.vda_a_c4f2c8e50
ssh-credentials:326.v7fcb_a_ef6194b_
ssh-slaves:2.948.vb_8050d697fec
sshd:3.322.v159e91f6a_550
structs:337.v1b_04ea_4df7c8
subversion:2.17.3
test-results-analyzer:0.4.1
text-finder:1.26
theme-manager:215.vc1ff18d67920
timestamper:1.26
token-macro:400.v35420b_922dcb_
trilead-api:2.142.v748523a_76693
variant:60.v7290fc0eb_b_cd
versioncolumn:243.vda_c20eea_a_8a_f
view-job-filters:369.ve0513a_a_f5524
warnings-ng:11.2.2
workflow-api:1291.v51fd2a_625da_7
workflow-basic-steps:1049.v257a_e6b_30fb_d
workflow-cps:3883.vb_3ff2a_e3eea_f
workflow-durable-task-step:1331.vc8c2fed35334
workflow-job:1400.v7fd111b_ec82f
workflow-multibranch:773.vc4fe1378f1d5
workflow-scm-step:427.v4ca_6512e7df1
workflow-step-api:657.v03b_e8115821b_
workflow-support:881.v7663695646cf
yet-another-build-visualizer:1.16

What Operating System are you using (both controller, and any agents involved in the problem)?

Debian 12

Reproduction steps

  1. Add Environment="JENKINS_UNIX_DOMAIN_PATH=/run/jenkins/jenkins.socket" to /etc/systemd/system/jenkins.service.d/override.conf
  2. Restart Jenkins

Expected Results

Clean restart, with a new socket in /run/jenkins/jenkins.socket

Actual Results

Fails, because /run/jenkins does not exist:

jenkins[351226]: java.io.IOException: Failed to start Jetty
jenkins[351226]:         at winstone.Launcher.<init>(Launcher.java:209)
jenkins[351226]:         at winstone.Launcher.main(Launcher.java:496)
jenkins[351226]:         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
jenkins[351226]:         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
jenkins[351226]:         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
jenkins[351226]:         at java.base/java.lang.reflect.Method.invoke(Unknown Source)
jenkins[351226]:         at executable.Main.main(Main.java:351)
jenkins[351226]: Caused by: java.io.IOException: Could not bind UnixDomainServerConnector to /run/jenkins/jenkins.socket
jenkins[351226]:         at org.eclipse.jetty.unixdomain.server.UnixDomainServerConnector.bindServerSocketChannel(UnixDomainServerConnector.java:267)
jenkins[351226]:         at org.eclipse.jetty.unixdomain.server.UnixDomainServerConnector.openServerSocketChannel(UnixDomainServerConnector.java:234)
jenkins[351226]:         at org.eclipse.jetty.unixdomain.server.UnixDomainServerConnector.open(UnixDomainServerConnector.java:205)
jenkins[351226]:         at org.eclipse.jetty.unixdomain.server.UnixDomainServerConnector.doStart(UnixDomainServerConnector.java:153)
jenkins[351226]:         at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
jenkins[351226]:         at org.eclipse.jetty.server.Server.doStart(Server.java:428)
jenkins[351226]:         at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
jenkins[351226]:         at winstone.Launcher.<init>(Launcher.java:205)
jenkins[351226]:         ... 6 more
jenkins[351226]: Caused by: java.net.BindException: Permission denied
jenkins[351226]:         at java.base/sun.nio.ch.UnixDomainSockets.bind0(Native Method)
jenkins[351226]:         at java.base/sun.nio.ch.UnixDomainSockets.bind(Unknown Source)
jenkins[351226]:         at java.base/sun.nio.ch.ServerSocketChannelImpl.unixBind(Unknown Source)
jenkins[351226]:         at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
jenkins[351226]:         at org.eclipse.jetty.unixdomain.server.UnixDomainServerConnector.bindServerSocketChannel(UnixDomainServerConnector.java:261)
jenkins[351226]:         ... 13 more

Anything else?

AFAICS, #442 should have added a tmpfiles file to the Debian package, but it didn't?!?

Are you interested in contributing a fix?

Yes

Tests no longer run on systemd > 248

Jenkins and plugins versions report

Jenkins 2.379

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 22.04.1 LTS x86_64
systemd 249 (249.11-0ubuntu3.6)

Reproduction steps

$ docker-compose run --rm packaging bash
$ ./prep.sh
$ make package
$ exit
$ python3 -m venv venv
$ . venv/bin/activate
$ pip install -r requirements.txt
$ molecule test

Expected Results

The tests pass. They actually do pass in the CI build (which must be using a VM with systemd 248 or earlier) and used to pass on my local machine a few months ago, but no longer pass on my local machine in recent weeks after I have upgraded the packages in my local Ubuntu installation to systemd 249.

Actual Results

The tests fail to run systemctl daemon-reload. dmesg(1) reports:

[  977.256889] systemd[1]: Set hostname to <debian-11>.
[  977.258394] systemd[1]: Failed to create /init.scope control group: Read-only file system
[  977.258625] systemd[1]: Failed to allocate manager object: Read-only file system
[  977.258661] systemd[1]: Freezing execution.

Anything else?

systemd/systemd#19245 and moby/moby#42275 go into the gory details. Apparently this was never "supported" to begin with, and the "official" way to do this is to use Podman instead as in gjhenrique/rpi_stuff@10cf31f, though this would likely require some additional work to get Podman set up in the VM image for the CI build. johanssone/ansible-unbound@ec3cbb8 shows a way to do this with Docker and systemd > 248, but this might break the CI build unless the VM image for the CI build is also updated to systemd > 248 in lockstep. In other words I suspect that any solution to this problem involves working on the VM image used for the CI build.

Configuration is lost after every upgrade of Jenkins since using systemd

Jenkins and plugins versions report

Not relevant. Had this from 2.335=>2.336 and now from 2.336=>2.337 (before we used 2.332 with init.d)

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 20.04

Reproduction steps

Just calling following snipped when a new version Jenkins is available

sudo apt-get update && sudo apt-get -V dist-upgrade

Expected Results

Jenkins is successfully restarting after update with same settings as before

Actual Results

The file /etc/systemd/system/multi-user.target.wants/jenkins.service is reset to their default values, so I have always to add HTTPs settings again (enable port, set path to password store, set password for it, custom JAVA_ARGs)...

Anything else?

No response

rpm: please include either systemd unit or sysvinit script

What feature do you want to see added?

The jenkins rpm comes both with a systemd unit (/usr/lib/systemd/system/jenkins.service) and a sysvinit script (/etc/init.d/jenkins). When starting the daemon using systemctl the systemd unit is called, when using service the sysvinit script runs. Some people use service as a wrapper to call systemd units and don't expect a legacy script to run (if a systemd unit is available).
So please remove the sysvinit script from the rpm for el7 and up as well as for Fedora 15 and up.
Thanks!

Upstream changes

No response

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.