Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Oleg Nenashev
    @oleg-nenashev
    @jeffpearce bump, are you around?
    @ShenJack presents now
    lloydchang
    @lloydchang
    When I joined, I didn’t receive a consent to be recorded pop-up. Anyhow, when looking at participants list, Zoom says Oleg, Martin, Marky, are recording as co-hosts. Hence people can view recording afterwards for evaluation and learning purposes.
    Jesse Glick
    @jglick
    Oleg Nenashev
    @oleg-nenashev
    Yeah, it is in the dev list now
    Jesse Glick
    @jglick
    I guess a side effect of using <iframe> would be that you cannot access API endpoints on model objects using relative URIs the way you would from a Jelly fragment.
    Marky Jackson
    @markyjackson-taulia
    @jeffpearce please note the questions above ^
    Jesse Glick
    @jglick
    Seems there is already a pretty rich thread on the dev list about technical topics (thanks @oleg-nenashev for link).
    The warnings-ng plugin also did some pretty rich UI. Anything that could be shared?
    Oleg Nenashev
    @oleg-nenashev
    The approaches are pretty close actually
    Jesse Glick
    @jglick
    (this is @longngn)
    Jesse Glick
    @jglick
    Do we have any measurements of the startup & throughput overhead compared to the socket-based JNLP4-Connect agent used by the kubernetes plugin?
    Oleg Nenashev
    @oleg-nenashev
    Jesse Glick
    @jglick
    What in 3.34 would relate to performance?
    Jeff Thompson
    @jeffret-b
    Throughput shouldn't change any with remoting-3.34. Startup can improve in 3.34 if using the mechanism.
    Jesse Glick
    @jglick
    Oh, by avoiding one HTTP round trip during startup, yes. Probably smallish compared to JVM overhead, remote class loading, etc.
    Oleg Nenashev
    @oleg-nenashev
    depends on the configuration
    classloading can be cached
    Jeff Thompson
    @jeffret-b
    Agreed. Probably small.
    Jesse Glick
    @jglick
    So you said there was 2019 Phase III demo video somewhere showing the cloud provisioning?
    Marky Jackson
    @markyjackson-taulia
    Yes, it is on the youtube channel
    Jesse Glick
    @jglick
    https://github.com/jenkinsci/remoting-kafka-plugin#links talks about a Phase III but I think that was from 2018
    Pham Vu Tuan
    @pvtuan10
    yeah we will update the links here, this README is not updated yet
    Marky Jackson
    @markyjackson-taulia
    Jesse Glick
    @jglick
    Thanks!
    Marky Jackson
    @markyjackson-taulia
    most welcome :-)
    Oleg Nenashev
    @oleg-nenashev
    @longngn @ShenJack @AbhyudayaSharma @stopalopa thanks a lot for your presentations!
    recording is being processed, not sure it works today
    Oleg Nenashev
    @oleg-nenashev
    @longngn @ShenJack @AbhyudayaSharma @stopalopa could you please publish your slides and add the links to the Google Doc with abstracts?
    stopalopa
    @stopalopa
    Couple of questions about @jglick’s comment about sharing a cache with the ~/.m2/repository/. 1) Would all plugins be in the following path: ~/.m2/repository/io/jenkins/plugins/? 2) When you say “share a cache” do you mean that plugins wouldn’t have to be downloaded and they could just be copied over to the plugin directory Jenkins uses? Or that Jenkins would actually look to the ~/.m2 directory for some of its plugins? Or maybe you’d have something like a soft link ?
    Marky Jackson
    @markyjackson-taulia
    stopalopa
    @stopalopa
    Marky Jackson
    @markyjackson-taulia
    :metal:
    Jesse Glick
    @jglick
    @stopalopa by sharing a cache I would mean that any time your tool was looking to download a specific version of a specific plugin, it would first check ~/.m2/repository/ and use that copy instead; and, if possible, conversely if it did need to download a plugin, it would save it in the Maven local repository where it would be available without an Internet connection for both this tool and any Maven build. (The latter part is harder, since to write the associated metadata files correctly and work with mirror settings in ~/.m2/settings.xml you need to embed a Maven library.) The group ID is not in general predictable (org.jenkins-ci.plugins and io.jenkins.plugins are the two most common), but if I recall correctly is defined in both an actual plugin archive (*.jpi) as well as the update-center.json from the Jenkins UC.
    (HTH)
    stopalopa
    @stopalopa
    Ok, thanks for the feedback. I’ll create a Jira ticket for that feature
    Jesse Glick
    @jglick
    For context, this is an example of a DiY system I have used in the past out of frustration with the limitations of install-plugins.sh (both the lack of cache sharing with Maven, and the fact that it picks up transitive plugin dependencies in nondeterministic versions acc. to whatever is on the UC that day): https://github.com/jenkinsci/parallel-test-executor-plugin/blob/f50c3d8b8a7d3223e8575247ff4303975aa293e0/demo/pom.xml#L32-L213 (which could now be simplified using https://github.com/jenkinsci/bom/#usage) and https://github.com/jenkinsci/parallel-test-executor-plugin/blob/f50c3d8b8a7d3223e8575247ff4303975aa293e0/demo/Makefile#L8-L17
    stopalopa
    @stopalopa

    @jglick for your point about

    fact that it picks up transitive plugin dependencies in nondeterministic versions acc. to whatever is on the UC that day
    this is because in install-plugins.sh by default pulls in the latest version of the dependencies?

    Jesse Glick
    @jglick
    Yes. I have a general aversion to any build process that might behave differently at different times! You should need to specify the versions of all plugins you want to include. (And it should be easy to update those versions to the latest available…so long as that becomes an SCM commit you can test in a pull request. Hence @dependabot.)
    Jesse Glick
    @jglick
    Of course you might want to make different tradeoffs depending on your typical use case. I was just letting you know about some prior art that might have been missed otherwise.
    stopalopa
    @stopalopa
    @jglick So your comments very much tie into some discussions we were having on the gitter channel earlier today and I’d love to get your feedback. The way I currently have it implemented is different from the original bash script in that instead of downloading the latest version of the transitive dependencies, the versions of the dependent plugins are determined by what’s specified in either the update center metadata or the plugin manifest for the original plugin that was requested. On the one hand, the versions of the listed dependent plugins listed are probably somewhat conservative and the user wouldn’t necessarily get the latest versions. On the other, it does lead to a consistent set of plugins across different runs. We were talking that we should probably also add the ability for users to specify that they want the latest of all plugins (or at least, if they specify the latest version of one plugin, then it dependencies should also be the latest). There was some debate about what the default behavior should be, so I’d like to get your opinion on how you think the tool should work.
    Oleg Nenashev
    @oleg-nenashev
    Recording of the today;s demos: https://www.youtube.com/watch?v=g19o24uzy6c
    Parichay Barpanda
    @baymac
    @oleg-nenashev My blog and project page has not been updated yet. Should it be updated before Aug 26th (before gsoc evaluation deadline)?
    Oleg Nenashev
    @oleg-nenashev
    @baymac something is wrong with the site deployment. I pinged the infra team yesterday
    Parichay Barpanda
    @baymac
    @oleg-nenashev thanks. Kindly let me know if this issue is not resolved before time what link I can share for GSoC evaluation.
    Oleg Nenashev
    @oleg-nenashev
    Pinged the infra folks again, hopefully it will be resolved by the EoD. If not, let's discuss Plan B tomorrow