Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 21:47
    codecov[bot] commented #1280
  • 21:45
    codecov[bot] commented #1280
  • 21:44
    codecov[bot] commented #1280
  • 21:23
    timja synchronize #1280
  • 21:22
    timja synchronize #1280
  • 21:01
    timja synchronize #1280
  • 20:56
    timja synchronize #1280
  • 20:31
    timja unlabeled #1280
  • 20:31
    timja labeled #1280
  • 20:31
    timja labeled #1280
  • 20:30
    timja review_requested #1280
  • 20:30
    timja opened #1280
  • 20:16
    timja reopened #1262
  • 20:16
    timja commented #1262
  • 20:15
    timja closed #1262
  • 19:59
    casz commented #1279
  • 19:33
    darkn3rd labeled #1279
  • 19:33
    darkn3rd opened #1279
  • 08:35
    choeffer labeled #1278
Jake Burns
@burnsjake
A plugin being the CasC plugin.
Joseph Petersen
@casz
@burnsjake why won't you use docker? :confused:
for installing plugins
Tim Jacomb
@timja
@oleg-nenashev did you want to do a jcasc release soon?
Someone just asked on github:
https://github.com/jenkinsci/configuration-as-code-plugin/pull/1053#issuecomment-535865314
Daniel Estermann
@d.esterman_gitlab
I also wait for a release to test if ConfiguratorException: serverAuthenticationToken is required to configure class hudson.plugins.sonar.SonarInstallation has been fixed
Robert Sandell
@rsandell
Hello, I'm working on fixing JCasC support for the git-client tool installations, and it's a bit of an unusual beast to fix.
Mark Waite
@MarkEWaite
That is the understatement of the year. @rsandell .
Robert Sandell
@rsandell
My second attemt I thought was a clever and beautiful hack where I used readResolve to "fix" the things that jcasc was doing wrong when using the databound constructor logic
But alas it turns out that jcasc is not calling readResolve after creating the objects.
Mark Waite
@MarkEWaite
Ah, that hurts.
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
@casz
@burnsjake JRE should not be a requirement to run or install jenkins. :laughing:
Jake Burns
@burnsjake
Huh?
Joseph Petersen
@casz
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
@casz
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.