Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Harshit Chopra
    @arpoch
    @MarkEWaite , @justinharringa:matrix.org , @rishabhBudhouliya , the Set Username as secret checkbox that we can set to hide the username while selecting credentials, is handled as a string in credential binding plugin here-https://github.com/jenkinsci/credentials-binding-plugin/blob/b6250417116ead0f4079b4c5759fbc7151d29933/src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/UsernamePasswordMultiBinding.java#L77
    and not as a Secret as I thought.
    Harshit Chopra
    @arpoch
    @MarkEWaite , @justinharringa:matrix.org , @rishabhBudhouliya , today I was test the git username password binding on an Ubuntu agent using ssh and windows as a controller, and I got some unexpected result , the script created to carry out git auth operation is alway created in windows even if the agent is linux based.
    Did this binding worked for you all over different agents using ssh?
    Mark Waite
    @MarkEWaite
    I haven't tested a Jenkins controller, but the results you are seeing match with what James Nord predicted. The newline constant is computed on the controller (Windows) but is then used on Linux
    3 replies
    Mark Waite
    @MarkEWaite
    It appears that git lfs is no longer available on the agents connected to ci.jenkins.io. It will likely be Monday before we're able to identify the issue and resolve it. We may need to disable the LFS tests in the git client plugin or make them conditional on the existence of the git lfs command so that we don't delay @arpoch with failing tests that are related to infrastructure
    1 reply
    Harshit Chopra
    @arpoch
    @MarkEWaite , @rishabhBudhouliya , @justinharringa:matrix.org, just a reminder I won't be able to contribute much for the upcoming week due to my examinations but will keep you all update if I make any progress during the week.
    Mark Waite
    @MarkEWaite
    Thanks @arpoch . All the best with your examinations. We'll use the time for more review and more testing of the implementation
    Justin Harringa
    @justinharringa:matrix.org
    [m]
    Hope your exams go well. Should we adjust our meetings for this week?
    1 reply
    Rishabh Budhouliya
    @rishabhBudhouliya
    @arpoch all the best for you exams
    Rishabh Budhouliya
    @rishabhBudhouliya

    @arpoch @MarkEWaite @justinharringa:matrix.org I have a doubt related to our decision of performing the binding on the git client plugin, instead of Git Plugin. (Sorry for doing this at this stage)
    context: As I was looking more into how the Git Plugin resolves a git tool in a multiple nodes/different environment scenario, I can see that the Git Plugin is responsible for interacting with a Run instance, that is, the git plugin is the place where a Jenkins job interacts with the git apis. We get the git apis from the git client plugin, it works as a utility plugin for the git plugin. The git plugin is supposed to be responsible for working with the Jenkins build and it has various utilities to handle git tool resolution or any other situation where we need to extract such information from the running Jenkins context.

    doubt: I am in no way suggesting to shift the implementation at this stage but I can see that we already have a way to resolve a git tool on nodes in the git plugin, I suspect we need to replicate the same in the git client plugin (which, technically, should be unaware of what happens with the Jenkins context).

    The reason why we don't have git tool resolution at the git client plugin reconfirms the fact that it is not supposed to work with the Jenkins build/instance.

    3 replies
    Mark Waite
    @MarkEWaite
    Good observation @rishabhBudhouliya . I hadn't considered that aspect. I think it is worth discussing next week after @arpoch completes exams. I assume that most of the implementation could be moved from git client plugin to git plugin without many changes, since the implementation can call the git client plugin public API's in either case.
    Rishabh Budhouliya
    @rishabhBudhouliya
    @MarkEWaite In the meantime, I will dig deeper into how Harshit's implementation is differing from the existing one. @arpoch please feel free to raise any point I may have missed.
    Rishabh Budhouliya
    @rishabhBudhouliya
    Are we having office hours tomorrow at the same time?
    1 reply
    Justin Harringa
    @justinharringa:matrix.org
    [m]
    Yeah let's start from that. Hopefully Rishabh didn't set his alarm for early. I feel bad that I didn't catch him before 😞
    1 reply
    I plan on using the time for review 🙂
    Justin Harringa
    @justinharringa:matrix.org
    [m]
    I won't be able to meet this week unfortunately. I'll be back next week.
    Harshit Chopra
    @arpoch
    @MarkEWaite @rishabhBudhouliya @justinharringa:matrix.org , regarding the openssh key format used for encrypted private key, should we use sshj library for this purpose or making our know implementation for this purpose is useful? Although the latter approach is tedious but could have benefits in long term.
    Mark Waite
    @MarkEWaite
    I generally prefer using someone else's implementation, especially when it seems the library is receiving regular maintenance (https://github.com/hierynomus/sshj/releases). However, if you see sshj as a significant liability or if we discover that it does not work well in the Jenkins plugin, we certainly can consider implementing only what is needed for the use case of the project.
    Harshit Chopra
    @arpoch
    @MarkEWaite , @rishabhBudhouliya , @justinharringa:matrix.org , if migrating the binding to git plugin then we need to explicitly ask for the git version installed on the machine from the user since the isAtleastVersion method has package-private scope, keeping this in mind I have not made any commits for the ssh binding yet.
    Will make the commits for ssh binding once sure in which plugin the binding are to be implemented. Currently the ssh binding is implemented in git client plugin.
    Mark Waite
    @MarkEWaite
    I thought that the git plugin already had a method that would determine CLI git version. We can certainly make that a public method in the git client plugin if that helps with the implementation.
    Harshit Chopra
    @arpoch
    Couldn't find it, making a public method for this purpose will surely help.
    Mark Waite
    @MarkEWaite
    Public method in git client is great with me.
    Harshit Chopra
    @arpoch
    @rishabhBudhouliya the resolveGitTool method resolves/finds Git Tool by name. So if using resolveGitTool for our specific use case then the gitTool name used will be Default as we are not taking any input from the user regarding the git Tool Name so we can't make any assumptions on what name the user will set for the git tool thus we can't supply the gitTool name for resolveGitTool method which comes down to using Default only.
    My implementation gitToolName is type specific, which only matches the type with the type of tool required irrespective of name set by the user. Both the implementation resolveGitTool and gitToolName are somewhat same only differs in the approach of the find the git tool. Also the time complexity of both the impl will be linear once the forNode method used in the gitToolName method is removed since it's not required their. So I think it's better to make a separate method in git plugin under GitUtils class which resolves the git Tool name based on the type rather than name.
    Harshit Chopra
    @arpoch
    @MarkEWaite, should I make a PR regarding the creation of a public method for comparing the cli git version with the required version. I am thinking of adding compareLeastGitVersion method signature in the GitClient interface. Will also create a test case for this change.
    Mark Waite
    @MarkEWaite
    Yes, a PR is the right approach to add a public method. Initially it will need an implementation in CliGitAPIImpl and a no-op in the JGit implementations
    Harshit Chopra
    @arpoch
    I have shifted the impl for compareLeastGitVersion to CliGitAPIImpl class and it seem reasonable as well since it is exclusively for cli git, also I have not added any additional test case but updated the existing assertVersionOutput method to check the compareLeastGitVersion method as well.
    Harshit Chopra
    @arpoch
    PR to resolve the above issue - jenkinsci/git-client-plugin#724
    Harshit Chopra
    @arpoch
    @rishabhBudhouliya , @MarkEWaite , the meeting haven't started yet?
    Rishabh Budhouliya
    @rishabhBudhouliya
    @arpoch I assumed it will begin at 8.30 AM on the CDF zoom account
    Mark Waite
    @MarkEWaite
    Sorry for my delay! Meeting ran longer than I expected
    Harshit Chopra
    @arpoch
    Created the PR for change of implementation from git-client to git plugin [jenkinsci/git-plugin#1104]
    Not added documentation changes in the PR though, I might need some changes, as I have added an input box to retrieve the git tool name from the user so let me know if this servers the purpose as expected, if the these changes are kept then documentation needs work.
    Also this https://www.jenkins.io/doc/developer/plugin-development/incrementals/ page needs improvement will open a PR with the required changes sooner or later.
    Mark Waite
    @MarkEWaite
    That's a great result @arpoch . I look forward to reviewing and interactive testing
    Harshit Chopra
    @arpoch
    I will join in a few mins
    Rishabh Budhouliya
    @rishabhBudhouliya
    I have joined
    Harshit Chopra
    @arpoch
    It says meeting has not started yet
    has the meeting started? I can't join though.
    Rishabh Budhouliya
    @rishabhBudhouliya
    I am not sure if Mark has joined yet, meanwhile I have created a session: https://narvar.zoom.us/j/96596666166?pwd=UzJQYkxxMUJmb0pCMjMya3Bmb1Jhdz09
    Harshit Chopra
    @arpoch
    @rishabhBudhouliya , apologies due my network issue
    Rishabh Budhouliya
    @rishabhBudhouliya
    @MarkEWaite @justinharringa:matrix.org apologies, I forgot to record the meeting. Harshit and I have tried to capture the details of the meeting in the meeting notes as much as we could, let us know if anything needs a discussion
    Mark Waite
    @MarkEWaite
    So sorry! I was playing with my grandchildren and forgot that we had a meeting today! See my comments in the pull request at jenkinsci/git-plugin#1104 . I'll review the meeting notes separately to assure that I'm current on the status.
    Harshit Chopra
    @arpoch
    @MarkEWaite , were should we add doc for git-credentials binding in git-plugin doc?
    Mark Waite
    @MarkEWaite
    In the README.adoc file
    Mark Waite
    @MarkEWaite

    Looking forward to the git credentials binding project office hours in about 30 minutes. I've spent an hour or two testing the most recent build and have good results to share.

    1. So long as I define the correct gitToolName, Pipeline and Freestyle jobs are working great in all the tests that I have run
    2. If I fail to define gitToolName, the job fails (Freestyle and Pipeline)

    Great work @arpoch !

    Mark Waite
    @MarkEWaite
    Shame on me for confusing one meeting with another. Docs office hours starts in a few minutes. Git credentials is tomorrow. Talk to you all tomorrow. Sorry for the mistaken calendar reading
    1 reply
    Harshit Chopra
    @arpoch
    1. If I fail to define gitToolName, the job fails (Freestyle and Pipeline)
    I believe the scenario of leaving git tool name input empty is not a valid behavior thus requires a check to ensure that at-least the git tool input contain Default.
    image.png
    Justin Harringa
    @justinharringa:matrix.org
    [m]
    Hey I'm sorry for the late notice but I have had some things come up and can't make it. Hopefully Mark has you set for the meet
    Mark Waite
    @MarkEWaite
    Meeting notes are in https://docs.google.com/document/d/1gZneYIDWrT5S-1ACG641wfvxs7vnDC0RCYqy-EuuhwY/edit?usp=sharing . Looks good to release a version of git client plugin with the new API and git plugin with the username / password credentials binding implementation
    Mark Waite
    @MarkEWaite
    @arpoch and @rishabhBudhouliya I've investigated further and I believe the logic is now implemented (with tests) that will allow gitToolName to be an optional argument and to use default if an invalid value is provided. See MarkEWaite/git-plugin@4f8e4d8
    Harshit Chopra
    @arpoch
    @MarkEWaite I believe you wanted something like this... for the git tool name selection
    2 replies