OK, so this is kind of complex so hang with me. We're moving from StarTeam to Github and I'm trying to reproduce what I'm doing in StarTeam with Github. StarTeam was easy because I owned the repository machine as well as administrated the tool. With Github, we're hosted. So I'm admin on the project but can't create an RSA Token on the machine for easy access. So I had to play around to make a personal access token work. In order to make that access token work, I had to run the checkout job on a different node so that it was running as a user that lived in Github as well (access token's namesake). So when this job gets called from the jenkins job, I want it to clone to the calling job's workspace (/opt/jenkins/workspace/<project_name>). Well since in order to authenticate, it lives in it's own shell, the workspace for this guy, and where it wants to clone to, is /home/<username>/<project_name>. All that for my question: how can I specify what folder to checkout to? I tried to use "checkout to specific local branch" but it fails saying "is not a valid branch name". Well, yeah, branch is referring to branch not folder, lol. In StarTeam this is easy, you just specify working folder. Any help? Thanks!
--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/128374b8-63d5-4b8c-86bb-5f214f5e68d2n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/605e9199.1c69fb81.932c2.d78c%40mx.google.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/921876ab-23ac-4272-b990-04925cf8352bn%40googlegroups.com.
It was a bit painful, but at least it gets it done. What I've implemented is passing the workspace to the checkout, checking out as my user to my user workspace (home directory), moving the files checked out to the jenkins workspace, using sudo to chown the folder and files to be owned by the jenkins user. It's very crude but it works. I'm going to take a look at Mark's option above, but at least I found something that will work...
--
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/Ob42FqU-0UY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/1f5a073cd7dd8172fff194b00193e4b52f6b2772.camel%40opentext.com.
Thanks for your reply Dirk! I'm a unix guy and that would have been my first choice, however I don't have access to the GitHub OS, only my particular repositories.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/Ob42FqU-0UY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/7363fbe30406b54bee9b6671dc9754cbf78081c7.camel%40opentext.com.
Building on master in workspace /var/lib/jenkins/workspace/Git-Checkout using credential JenkinsSSHKey > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://myGitRepo.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 No valid HEAD. Skipping the resetting > git clean -fdx # timeout=10 Fetching upstream changes from https://myGitRepo.git > git --version # timeout=10 using GIT_SSH to set credentials
> git fetch --tags --progress https://myGitRepo.git +refs/heads/*:refs/remotes/origin/* # timeout=10 ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://myGitRepo.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167) at hudson.scm.SCM.checkout(SCM.java:505) at hudson.model.AbstractProject.checkout(AbstractProject.java:1206) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509) at hudson.model.Run.execute(Run.java:1907) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://myGitRepo.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: remote: Password authentication is not available for Git operations. remote: You must use a personal access token or SSH key.
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAByBicb7irzVcbgHO0vV39EE7f515%3DVCkcHqrYE5eefkjbZT%3Dg%40mail.gmail.com.
I do add the domain and hsot to my known host file before to avoid that nasty confirm:
sh("ssh -R ${domain} -f \".ssh/known_hosts\"")
sh("ssh -t rsa ${domain} >> \".ssh/known_hosts\"")
that should do the trick and avoid that prompt when later used. Use the domain of the repos url domain.
Jérôme Godbout, B. Ing.
Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114
C: (581) 777-0050
godb...@dimonoff.com
1015 Avenue Wilfrid-Pelletier,
Québec, QC G1W 0C4, 4e étage
From:
jenkins...@googlegroups.com <jenkins...@googlegroups.com> on behalf of eric....@gmail.com <eric....@gmail.com>
Date: Monday, March 29, 2021 at 3:27 PM
To: Jenkins Users <jenkins...@googlegroups.com>
Subject: Re: GitHub Clone to Different Local Directory
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/578014bd-9a78-49c9-99fb-2b0ab66c2354n%40googlegroups.com.
Please make sure you have the correct access rights and the repository exists.
Am Montag, den 29.03.2021, 11:07 -0700 schrieb eric....@gmail.com:Please make sure you have the correct access rights and the repository exists.Oh, yes, forgot that: On the host(s) that does/do the cloning, you need to either
- connect to g...@github.com once per SSH on the console and as the user who runs Jenkins, to add the GH host key to that users known_hosts file, or
- add a host block to that users ~/.ssh/config file like:
host github
Hostname github.com
User git
IdentityFile ~/.ssh/my_github_key
ServerAliveInterval 15
StrictHostKeyChecking noIn the second case, you also don't need to store the credentials in Jenkins, since you can use the alias "github" directly in your URLs, like "github:path/to/repo" (instead of "g...@github.com:..."). If you're reluctant to skip host key verification, you can also omit the last line and combine the two methods.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/QB1PR01MB38441677B7426D136A949FBFCD7E9%40QB1PR01MB3844.CANPRD01.PROD.OUTLOOK.COM.
Oups my bad, in my hurry I forgot to change the right exe, I keep those into variable and I badly refilled them here:
sh("ssh-keygen -R ${domain} -f \".ssh/known_hosts\"")
sh("ssh-keyscan -t rsa ${domain} >> \".ssh/known_hosts\"")
The first one removes any old entry, the second one adds the record to the file.
Jérôme Godbout, B. Ing.
Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAByBicbOCiWvNLhhATFmhKAH0YPsB%3DZUDCbAHESpK9grnya1WQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/QB1PR01MB3844E30F21F2D7759011267ECD7D9%40QB1PR01MB3844.CANPRD01.PROD.OUTLOOK.COM.
Do not check if the first command succeed, it remove previous entry if any. If none was present the command will fail.
Do the following:
String domain = “github.com”;
sh("ssh-keygen -R ${domain} -f \".ssh/known_hosts\"", returnStatus: true);
sh("ssh-keyscan -t rsa ${domain} >> \".ssh/known_hosts\"")
Now that should do it, you do not really care if the remove hit something or not, just make sure you do not have an old invalid entry.
Jérôme Godbout, B. Ing.
Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAByBicZ4gG%2BYFL3%2B_-EC5jWoYOA%2Bpb6DEOd9QrXTcdv5QiTTJA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/QB1PR01MB3844F3C252A602FEEDA3D14BCD7D9%40QB1PR01MB3844.CANPRD01.PROD.OUTLOOK.COM.
The only thing I can guess is that ssh is getting a question when he attempts to connect wanting to be added to the known_hosts file. Wondering if maybe there's a way to establish this if this is indeed the issue?
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/Ob42FqU-0UY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d8bd7d209c38e258fa083e78f484d2529a9b4cab.camel%40opentext.com.
Hi Dirk, sorry I didn't respond earlier, but I did try these things. They just didn't work. Questioning whether I didn't run into a firewall rule. Even though they allow us to add an SSH Key in GitHub, that doesn't mean they've opened port 22 on the server. When I try to ssh g...@github.com, it ends up "Connection timed out". I would kind of expect a refusal if the firewall were slapping it down, but not sure.