Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support of dynamically-modifyable system properties in YAML #81

Open
oleg-nenashev opened this issue Feb 5, 2018 · 8 comments
Open
Labels
feature A PR that adds a feature - used by Release Drafter

Comments

@oleg-nenashev
Copy link
Member

Jenkins core has an engine for defining system properties on the flight (SystemProperties in the code or just non-final static fields). It would be great to support such engine in the Condifugation-as-Code plugin

The implementation is TBD

@ndeloof
Copy link
Contributor

ndeloof commented Aug 9, 2018

Can you please provide a link to this mechanism ? Never heard about his

@jetersen jetersen added feature A PR that adds a feature - used by Release Drafter and removed enhancement labels Apr 23, 2019
@jetersen
Copy link
Member

jetersen commented Aug 29, 2019

I think what @oleg-nenashev meant is to control system properties that Jenkins reads.

So instead of this in a docker image

ENV JAVA_OPTS="-Dhudson.model.DirectoryBrowserSupport.CSP=\"sandbox allow-same-origin allow-scripts; default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src blob: 'self';\" ${JAVA_OPTS}"

It could be something like this:

systemProperties:
  - hudson.model.DirectoryBrowserSupport.CSP: "sandbox allow-same-origin allow-scripts; default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src blob: 'self';"

I'd really love if we got around to this issue 😆

@chroche
Copy link

chroche commented Oct 18, 2019

I'd really like to see that feature implemented too.

To clarify, there is an official list of Jenkins features controlled by system properties here.

Some values like hudson.TcpSlaveAgentListener.hostName are required for configuring a server/agent setup but cannot be set any other way than with a init.grovy.d script as far as I can tell, e.g.,

# ref/init.groovy.d/properties.groovy

host = "jenkins-master"
port = "50000"

System.setProperty("hudson.TcpSlaveAgentListener.hostName", host)
System.setProperty("hudson.TcpSlaveAgentListener.port", port)

jenkins.model.Jenkins.getInstance().save()

Another striking example is the server timezone, which requires something like

time_zone = "Europe/London"

System.setProperty("org.apache.commons.jelly.tags.fmt.timeZone", time_zone)

It would be very nice to have these values handled by CasC, this would help getting rid of the init.groovy.d scripts for good.

@jetersen
Copy link
Member

jetersen commented Nov 25, 2019

The problem with #1204 is you would have another chicken and egg problem (at least with the current implementation) 😭

@jtnord
Copy link
Member

jtnord commented Nov 25, 2019

as mentioned in #1204 system properties need to be set much earlier than configuration as Jenkins and/or plugins can change behaviour based on them and they are not expected to change post initialisation.

@timja
Copy link
Member

timja commented Nov 25, 2019

The problem with #1204 is you would have another chicken and egg problem (at least with the current implementation) 😭

I assume you would run it as the very first configurator, possibly even in an earlier initialiser?

@oleg-nenashev
Copy link
Member Author

We could add support for it directly in the Jenkins core 🤷‍♂ . Even with YAML input, why not

@giovinazzorocco
Copy link

are there any updates?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A PR that adds a feature - used by Release Drafter
Projects
None yet
Development

No branches or pull requests

7 participants