Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:46
    sladyn98 commented #1037
  • Mar 28 22:45
    codecov[bot] commented #1301
  • Mar 28 22:45
    codecov[bot] commented #1121
  • Mar 28 22:45
    codecov[bot] commented #1312
  • Mar 28 12:04
    codecov[bot] commented #1302
  • Mar 28 12:00
    codecov[bot] commented #1302
  • Mar 28 11:57
    codecov[bot] commented #1302
  • Mar 28 11:29
    codecov[bot] commented #1302
  • Mar 28 11:29
    Jetersen synchronize #1302
  • Mar 28 11:22
    codecov[bot] commented #1338
  • Mar 28 11:21

    timja on master

    Remove vault integration test (… (compare)

  • Mar 28 11:21
    timja closed #1338
  • Mar 28 11:19
    codecov[bot] commented #1338
  • Mar 28 10:54

    timja on master

    [JENKINS-51856] Apply configura… (compare)

  • Mar 28 10:54
    timja closed #1262
  • Mar 28 10:54
    timja closed #1026
  • Mar 28 10:54
    timja closed #280
  • Mar 28 10:54
    timja commented #1262
  • Mar 28 10:50
    timja commented #1338
  • Mar 28 10:49
    timja labeled #1338
Robert Sandell
@rsandell
Would you be against adding that optional dependency mark?
Mark Waite
@MarkEWaite
I don't object to adding an optional JCasC dependency into the git client plugin. A mandatory dependency would not be acceptable, but optional would be fine.
Robert Sandell
@rsandell
ok.
How do people feel about adding a call to readresolve in the handling of DataboundConstructorConfigurator? or maybe it was called DescribableConfigurator (the default one)?
I've heard a rumor that Oleg doesn't like the custom configurator approach :)
Mark Waite
@MarkEWaite

How do people feel about adding a call to readresolve in the handling of DataboundConstructorConfigurator? or maybe it was called DescribableConfigurator (the default one)?

@casz and @timja seem like the two best suited to answer that question along with @oleg-nenashev

Robert Sandell
@rsandell
Oleg is on vacation so I didn't dare pinging him :) But other's opinions are welcome ;)
oleg-nenashev @oleg-nenashev waves
Mark Waite
@MarkEWaite
Sorry for my mistake pinging him on vacation!
Mark Waite
@MarkEWaite
If that didn't work, could we modify the CliGit data bound constructor to have it detect the name argument is "jgit" (or "jgitapache") and then act as though it were JGit internally? I assume that would be a more dramatic change to the git client plugin, but would avoid inserting a readResolve call into a highly used portion of JCasC
Robert Sandell
@rsandell
possible, but quite ugly Ithink. The UI config would change as well possibly confusing users further
Mark Waite
@MarkEWaite
Good point
Oleg Nenashev
@oleg-nenashev
Adding support of readResolve() to JCasC might be doable
Robert Sandell
@rsandell
I don't think adding a readResolve call would harm anything as most of those implementations looks for things deserialized from an old format and if so converts to newer fields already set by the databound constructor. But there is always corner cases I guess :)
is the rumor true @oleg-nenashev that you preffer not to use custom Configurators if avoidable?
it would make the yaml a bit better in this case, but much more work since it's not very documented so I'm fumbling a bit in the dark trying to user it :)
Oleg Nenashev
@oleg-nenashev
@rsandell for me readResolve() is rather a part of a wider topic about retaining JCasC backward compatibility for configurations. Right now we have no answer of it, and it would be great to have one
I will not push back any Configurator implementation FTR. If a plugin maintainer is fine AND if it is really need to resolve an issue, why not?
Robert Sandell
@rsandell
OK :)
Tim Jacomb
@timja

My second attempt that I'm currently working on is using a custom Configurator, that would probably make it possible to have a bit more nice looking yaml, but it would mean adding an optional dependency to jcasc in the git-client plugin. And the Configurator API in jscasc is badly documented to say it mildly :) so the work is going slow on that approach.

Far too nice, the API really needs some docs improvements :(

Open to a PR for readResolve in jcasc, just depends on how the integration tests go, this is the second time i've heard about lack of readResolve being an issue, last time was in one of the google plugins..
Jake Burns
@burnsjake
@casz Because docker should not be a requirement to run or install jenkins.
Joseph Petersen
@Jetersen
@burnsjake JRE should not be a requirement to run or install jenkins. :laughing:
Jake Burns
@burnsjake
Huh?
Joseph Petersen
@Jetersen
Java runtime environment
Jake Burns
@burnsjake
I know what JRE is. I just don't understand what your reply has to do with the complaint that docker shouldn't be required to run jenkins.
Mark Waite
@MarkEWaite
@burnsjake there was sarcasm strongly laced in the reply from @casz. Docker is not required to run Jenkins. It runs from many different locations and formats. I believe @casz was trying to understand if you had specific concerns related to Docker or if it was more a preference for operating system native packages rather than Docker images
Joseph Petersen
@Jetersen
What @MarkEWaite said :)
Jake Burns
@burnsjake
Oh. I do have concerns about using docker for jenkins and documenting that as the standard method of installation. Docker adds a layer of complexity and reduces portability. It's wholly unneeded to run jenkins or the CasC plugin.
I do prefer native packages from repos.
Mark Waite
@MarkEWaite

The Jenkins installation methods directly maintained by the Jenkins project are described as:

In addition to those installers maintained by the Jenkins project, there are also installers for:

  • FreeBSD
  • OpenBSD
  • OpenIndiana

As far as I can tell, they are all able to use JCasC.

Jake Burns
@burnsjake
Maybe I'm not explaining this well. I'm looking to automate the installation of jenkins and use the CasC plugin to do the configuration. The getting started part of the readme: https://github.com/jenkinsci/configuration-as-code-plugin#getting-started says I should preinstall the CasC plugin, and the only example cited is using Docker. Which brings me back to my original question..."Is there a good howto on how to bootstrap a brand new jenkins installation (without docker) with the configuration as code plugin?"
Mark Waite
@MarkEWaite

@burnsjake as far as I know, there is not a

good howto on how to bootstrap a brand new jenkins installation (without docker) with the configuration as code plugin?"

Most of the Jenkins installations that I've managed with a package manager (Linux, Windows) do not attempt to automate the bootstrap process. In my case, I didn't attempt to automate the bootstrap process because I was running very few of them and could perform the initial installation tasks interactively much faster than I performed them with automation. I did automate the recording of the configuration of those systems, their backup, and their disaster recovery processes, but not their initial installation.

If I were automating the initial installation on my favorite Linux (Debian) or one of its derivative, I think I would probably use the following steps:
1 - Add the Jenkins repository to sources.list
2 - Update the repository contents with apt-get update
3 - Install Jenkins with apt-get install -y jenkins
4 - Stop the newly installed Jenkins service with systemctl stop jenkins
5 - Change to the Jenkins user and clone the git repo that I use to track Jenkins configuration into the JENKINS_HOME directory
6 - Start the Jenkins server

I'm sure others have better ways of doing that. I'm a git user, so every time I need to remember the content of files, I immediately think that git is the answer.

If you'd like to see an example of that technique in action, refer to https://github.com/MarkEWaite/docker-lfs/tree/lts-with-plugins/ref . That subdirectory is a git copy of the contents of JENKINS_HOME, with a few modifications to make it portable between computers with different hostnames.

Tim Jacomb
@timja
I also replied earlier with links to jenkins_plugin with ansible and https://github.com/jenkinsci/plugin-installation-manager-tool for installing plugins
but if you aren't using docker there's no real generic method, there's lots of different ways of doing it
It might be a plausible solution for non-docker setups
Jake Burns
@burnsjake
Jenkins for the default install on ubuntu uses /etc/init.d/jenkins still. How should one declare a variable that CasC can use in the world of systemd in compatibility mode? I tried adding --env=SSHKEY=MYSSHKEYVALUE to the DAEMON_ARGS= line and that failed miserably.
Jake Burns
@burnsjake
I even tried adding SSHKEY=base64 -d pathtomyencodedkey to /etc/environment and that failed.
Tim Jacomb
@timja
It's easier to use the 'docker' secrets mode, which is to place the files on the file system somewhere and set the SECRETS environment variable
Robin Yonge
@gilmoregrills
hello! I'm having some issues triggering config reloads, at the moment the config is loaded from s3, and reloading it in the console works fine, and so does doing:
curl -X POST -u user:api-token https://<jenkins-url>/configuration-as-code/reload
but if we try to reload it using something like:
curl -X POST "https://<jenkins-url>/reload-configuration-as-code/?casc-reload-token=123456789
then we get a crazy exception:
Caused: io.jenkins.plugins.casc.ConfiguratorException:
that says loads of our parameters are incorrect or missing
the same config also works fine when passed to jcasc as a file!
oh and I can see the casc.reload.token in /systemInfo
bit stuck
to be clear, the jcasc-reload-token method (if it works) would be our preferred way of doing this, it seems much easier to automate
Jake Burns
@burnsjake
Tim, unfortunately, I'm not using docker.
Tim Jacomb
@timja
you don't need to use docker @burnsjake
it just reads files from the file system
@gilmoregrills that should work :( will have to have a look