jenkinsci / configuration-as-code-plugin Goto Github PK

https://plugins.jenkins.io/ssh-credentials

https://plugins.jenkins.io/script-security

Need some way to configure users and UserProperties, including (but not limited) to HudsonPrivateSecurityRealm$Details to pre-configure admin user with a password

Not all Describable instances have @Symbol defined (e.g. RoleStrategy). In order to support such plugins in custom configurators, it would be great to consult with configurators when Symbol is not found.

yaml with example build slaves configured needs to be available in demos folder

https://plugins.jenkins.io/matrix-project

This should in result become a part of documentation, but first we'll use it to discover possible use cases and create follow up issues.

1. running from scratch with official docker image (provided by us, plugin preinstalled, wizard disabled)
2. installing plugin on working Jenkins instance (wizard not an issue)
3. pre-packaged opinionated Jenkins distributions (plugin preinstalled, wizard an issue)

A customer have many teams, each with their own Jenkins. The teams needs to inherit a standard configuration available, and then add their own team specific configuration.
The standard configuration should be able to be overwritten if the team want to use 99% and not only add to it.
What happens when the standard configuration is updated?

We need a stable CI if we want to safely review PRs and do some refactoring

https://ci.jenkins.io/job/Plugins/job/configuration-as-code-plugin/job/master/7/console

Refresh button - so I can reload configuration from files, without restarting Jenkins
Optional locking down changes in the UI blocking users from changing it without updating the config file
Export configuration - if I have Jenkins already configured, or just made some changes in UI and want to keep them in the file

I have a configuration-as-code demo, which demoes a ci,jenkins.io-alike setup for Pipeline development: https://github.com/oleg-nenashev/demo-jenkins-config-as-code

It would be great to migrate the prototype to CasC so that we get some info from close-to-real instances. It requires #48 and probably patches for some other plugins

as discussed on mailing list
We have no way to guess Descriptors data model, until they move to DataBoundSetters to "document" their UI databinding.
But this is not enough : Descriptor are mutable objects, and DataBound mechanism don't reset object so some optional attribute becomes null if not-set on UI. So it might be necessary to ask plugin developers to implement the configure(StaplerRequest, JSONObject) method as:

• reset everything to default values
• invoke data binding req.bind(json)
• save descriptor save()

Maybe there's some way to make this the default mechanism ?

When we update the global configuration in jenkins.yml in the git repository, we need the jenkins master to refresh the configuration without restarting.

Even after #47 the plugin does not start up well due to the collisions

https://plugins.jenkins.io/credentials

https://plugins.jenkins.io/junit

The current implementation silently ignores fields with NOOP converters. It is not something preferable IMHO, it would be better to fail initialization in such case

The current Jenkinsfile in praqma/dev is incompatible with ci.jenkins.io (the CI instance of the Jenkins project that builds all plugins in the @jenkinsci organization) by selecting a node label that just doesn't exist. This adds queue items that never start.

Since we're using a GH org folder, our ability to configure individual projects is limited.

While I personally would advocate for just using that Jenkins instance for all your CI needs, a quick fix could be to just return from the Jenkinsfile if the JENKINS_URL.contains('.jenkins.io') or similar.

https://github.com/Praqma/configuration-as-code-plugin/issues/75

Some attributes are owned by Jenkins root class for legacy reasons but managed from a web UI point of view using GlobalConfiguration implementation (typically : security has a dedicated page).
We'd like to be able to discover this from the java codebase so we can mimic in the yaml model, so

jenkins:
  securityRealm: ...

would become :

jenkins:
  security:
     securityRealm:  ...

Currently there is no way to pass authorizationStrategy for Jenkins instance. The plugin injects NOOP setter for that.

I hit if for Role Strategy in #48, @kohsuke hit it for Unsecure Strategy at the same time

To make it really easy migrate already running Jenkins instances to Configuration as Code, or to just use Jenkins itself as editor for the YML file an export functionality should be supplied to the user from our UI footprint.

I imagine a kind of Export current configuration button or link, that will show the current Jenkins configuration as YML and make it easy to download it.

The user can then save the YML file to git and other places, and supply it back to a new or existing Jenkins instance to start using Configuration as Code Plugin.

I would expect also to be able to download the needed plugin.yml that described the needed plugin on my current instance.

Configuration as code should fully setup Jenkins, so setup wizard should be automatically disabled.

On web UI, tool installers are all configured within Jenkins > Manage > Tools subpage. As we consider the web UI to be some "natural end-user documentation" we want to mimic this in the YAML document structure.

If we install new plugins in the plugin.yml file, how can they be updated without restart as many plugins require restart on update.

https://github.com/jenkinsci/tfs-plugin

On host/plugin/configuration-as-code the helpful documentation can be found, but it is hard to read due to indentation and layout.

As a user I would like a simple styling making the indentation very visual and match the YAML configuration I'm supposed to write.

A very simple layout with font's and other styling helping read it would be nice as well. Maybe a also a table of content.

hudson.security.AuthorizationStrategy.Unsecured has no DataBoundConstructor. From configuration-as-code point of view it appears as a custom implementor for newinstance that we can't support.

Maybe we can introduce as an extended convention to search enclosing class for a constant with same name (i.e UNSECURED).

How can we test that YML file is persisted as the exact global configuration I imagine…

Current prototype do load configuration from ./jenkins.yaml
We force sure want more flexibility

• Load from a set of files
• Load from a configurable folder (env variable)
• Load from a kubernetes configMap
• Load from docker config

Defining an SPI for configuration source that a complementary plugin can implement would make this flexible enough to support extensibility to various use-cases.

we're trying to mimic UI as much as possible, but our current solution doesn't support it

in UI we have

• jenkins
  -- mailer
  -- artifactorybuilder
  -- ...
• tools
  -- git
  -- ...

when in yaml it's

• jenkins
  -- ...
• mailer
• artifactorybuilder
• tools
  -- git
  -- ...

can we maybe treat each element UNDER jenkins as root element? so it can be matched with RootElementConfigurators even if it's not a root in yaml? does it even make sense?

Rile Strategy plugin has a complex Authorization configuration logic, which use custom logic in Descriptors. So CasC plugin won't support it OOTB, but the plugin is an important part of the plugin ecosystem. I would like to add the plugin support, the implementation and code location is TBD

LSP would enable support within IDEs (vscode, eclipse...) for configuration-as-code syntax.

CredentialsRootConfigurator extension has Credentials class existence check neither in declaration nor in static declarator. In such case the extension will be loaded and then it will eventually cause class not found exception if used.

If we have all global configuration as CasC, we still need to get at least one job up and running to start with that can create all job- and view-related things. This is not part of CasC, so maybe this should be a feature of our container docker4jcasc much like the old one contribute with this genesis seedjob thing.

There are conflicting dependencies in the plugin, ideally they should be resolved so that we have no library conflicts

short document describing the process of contributing changes to the plugin

To help new users try the concept, there should be a Jenkins Configuration as Code Docker image available that can be started with a pointer to a configuration spinning up a new Jenkins from scratch with the configuration given.

I expect to be the usual Jenkins LTS image, with only two modifications:

• setup wizard disabled
• Latest Configuration as Code plugin installed

describe how to proceed when someone wants to migrate existing traditionally configured Jenkins to as-code solution

https://plugins.jenkins.io/matrix-auth

https://plugins.jenkins.io/artifactory

Bit confusing to see this message when we actually only today are working in the jenkinsci fork.

We should clean up so they are in sync, or a least the the jenkinsci fork in front.

As being part of Praqma I like this really cool initiative is forked from Praqma's github account, but it doesn't constitute a really good excuse to make it look like a mess.

We also had one contribution to our Praqma repo... so users might also be confused.

If it isn't easy to clean up, we can have Github support staff break the fork.

Hi,

I've tried to express that with the current version without success:

import jenkins.security.s2m.AdminWhitelistRule
import jenkins.model.Jenkins

Jenkins.instance.injector.getInstance(AdminWhitelistRule).masterKillSwitch = false

I believe it will have to be some glue code here.

on praqma/dev branch we have implemented support for reading location of jenkins.yaml file from environment variable, that can point to local file, or repository - maybe it's time to move this functionality to master branch?

To show the concept for real and running we have discussed to have a demon instance running live people can visit and also browse the documentation and configuration of as we propose it to be used.

We can host such one in Praqma, and I see two options for us:

1. our current Jenkins cloud instance running the old concept JenkinsAsCodeReference could be migrated casc, but we miss a series of plugin to do that
2. we could create an deploy a new one we where we would then only host this plugin and a pipeline for it

No matter what option we go for, we should point the users to this "demo" instance as an example and supply them with information like:

• our jenkins.yml and plugin.yml files - public repository
• documentation on how we maintain the instance (deployment, upgrades etc)
• how they could clone the project, and create a copy test instance of it themselves (without our credentials it would only work with how far their own credentials reach though)

Handling credentials as code may not be a trivial issue, from security and usability point of view.

The way it was used in the old JAC version is not satisfying - keep credentials, like passwords, in a plain text file under .ssh directory on a host machine.
When deploying Jenkins remotely it meant you had to ssh to the machine and create files there, then JAC redeployment - heavy operation just to add credentials... No better solution in my head yet, but maybe it's time to start discussing it.

There is a plugin to maintain build slaves, allowing slave administrators to configure their slaves. How can that work if the slave configuration is in our new jenkins.yml file? The customer said they have delegated responsibility for this configuration based on the ownership plugin.