Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 31 22:50
    stale[bot] labeled #1242
  • Mar 31 22:50
    stale[bot] commented #1242
  • Mar 31 21:39

    Jetersen on gitter-chat-link

    (compare)

  • Mar 31 21:39

    Jetersen on master

    Add Gitter Q&A tab to the New I… (compare)

  • Mar 31 21:39
    Jetersen closed #1344
  • Mar 31 21:36
    oleg-nenashev commented #1344
  • Mar 31 21:36
    oleg-nenashev review_requested #1344
  • Mar 31 21:36
    oleg-nenashev ready_for_review #1344
  • Mar 31 16:42
    oleg-nenashev commented #1344
  • Mar 31 16:42
    codecov[bot] commented #1344
  • Mar 31 16:40
    Jetersen commented #1344
  • Mar 31 16:40
    codecov[bot] commented #1344
  • Mar 31 16:38
    codecov[bot] commented #1344
  • Mar 31 16:37
    codecov[bot] commented #1344
  • Mar 31 16:32
    codecov[bot] commented #1344
  • Mar 31 16:32
    codecov[bot] commented #1344
  • Mar 31 16:31
    codecov[bot] commented #1344
  • Mar 31 16:29
    codecov[bot] commented #1344
  • Mar 31 16:14
    daniel-beck review_request_removed #1344
  • Mar 31 16:14

    oleg-nenashev on gitter-chat-link

    Remove the security link (compare)

Mark Waite
@MarkEWaite
I had an alternate hack technique that came to mind. Would love to hear your thoughts on my hack idea.
Robert Sandell
@rsandell
It's not clear cut to me now that I'm thinking about it if it should or not. XStream does it after deserializing from disk. but in form submission it doesn't. And perhaps JCasC is a bit of both or somewhere in between.
Mark Waite
@MarkEWaite
There are only two special strings that identify the JGit implementations, "jgit" and "jgitapache". What if the git client plugin data bound constructor for CliGit detected one of those two strings and called out to the JGit implementation instead?
I assume (my guessing) that making JCasC call readResolve is a much more invasive change that the team will be ready to make. It will invoke many pieces of code that had not been run before in this context
Robert Sandell
@rsandell
Well you can't really construct another object from the constructor
my readresolve does that; detecting if name is the magic name and in that case returns the appropriately constructed object
Mark Waite
@MarkEWaite
Could the CliGit data bound constructor somehow "queue" a call to readResolve if it detects it is called in from JCasC?
Robert Sandell
@rsandell
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.
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