Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mark Waite
    @MarkEWaite
    If Rishabh and Justin aren't in the meeting, then let's assume it is every Wednesday as you thought it was. I'll remove the Tuesday meeting from the Jenkins calendar
    Rishabh Budhouliya
    @rishabhBudhouliya
    @arpoch @MarkEWaite I saw the invite but I assumed we are defaulting to the Wednesday office hours
    Justin Harringa
    @justinharringa:matrix.org
    [m]
    Wednesday works for everyone at the currently scheduled time? I believe Harshit had perhaps another conflict but maybe only one?
    Mark Waite
    @MarkEWaite
    Wednesday works for me at the currently scheduled time
    Harshit Chopra
    @arpoch
    @MarkEWaite, I test the freestyle project with and without parameter expression using command git fetch --all, it worked as expected no issues. Will check my config.xml with the one you send.
    Mark Waite
    @MarkEWaite
    Very interesting @arpoch . I assume that the repository you were using in your test was a private repository and that if you remove the credentials binding, then the git fetch --all fails. I'll need to explore further after my working day today.
    Rishabh Budhouliya
    @rishabhBudhouliya
    @arpoch will you be presenting the GSoC project in the summit tomorrow?
    Harshit Chopra
    @arpoch
    I added my name under ignite talks, I will be showing a small demo of git username and password binding.
    Harshit Chopra
    @arpoch
    @MarkEWaite, @rishabhBudhouliya , @justinharringa:matrix.org, should credential storage be a concern as credentials will be locally cached if credential.helper is set to store or cache on the system, as mentioned here.
    Harshit Chopra
    @arpoch
    From my point of view I think it could be a concern, because if a user performs a git checkout using credentials and then performs batch/shell build step to perform git fetch --all then it will work even if not using git credential binding, I missed this case since I was not storing my credentials.
    Mark Waite
    @MarkEWaite

    @arpoch the git plugin has always assumed that cached credentials were not enabled on the agent. If a user enables credential caching on an agent, they do so at their own risk. I think it is enough to document that assumption without taking active measures to disable cached credentials.

    Jenkins users are very creative. I would not want to actively disable credential caching because I fear it would break some existing configurations where users intentionally enabled credential caching and rely on it.

    Agent information latency (repository on disc during the build, credentials on disc during the build, repository left after the build, job configuration left after the build, etc.) happens with Jenkins as soon as someone allows themselves to reuse an agent or allows more than one job to run on the same agent concurrently.

    1 reply
    Harshit Chopra
    @arpoch
    @MarkEWaite, I went through the config.xml of JENKINS-28335-freestyle-parameterized-credential-binding, I found that the credentialsId under buildWrappers was already expanded, your parameter name was MY_USERNAME_PASSWORD_CREDENTIAL, but the credentialsId was given as MarkEWaite-github-token-2019-05-25, should not it be ${MY_USERNAME_PASSWORD_CREDENTIAL}?
    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