I'm using libgit2sharp and I'd like to be able to test the connection to a specific repository providing its URL and a username/password. So far, I've only been able to do this by cloning the repository but I don't want the files to be retrieved, I just want to see if the information provided can be used to connect to the repo.
Would you only want to test the connectivity, I believe the quickest way would be to use the static Repository.ListRemoteReferences() method.
This will retrieve the list of known references from the remote repositories, leveraging the whole network stack.
An override allows you to pass in your credentials (for private repositories, for instance).
Related
In our GitHub we have around 20 repositories. For the CI Build we have enabled Git polling option.
Our Jenkins master has attached with multiple nodes. For Git Polling we usually add our Jenkins Master ssh key to repective user's GitHub under settings SSH key section. While adding the key getting Error: Key already in use. Let me know to add the same.
As per error message for other repository build we have already added our Jenkins Master key with different user's
account.
A SSH key can only be attached to a single user on GitHub, since it is used to authenticate and authorize this user. There is no way to add to multiple accounts.
GitHub provides a guide about dealing with SSH keys for automated scripts here: Managing deploy keys. The two interesting options are:
Typically, you would use deploy keys to gain access to a repository from a server. Deploy keys have a similar restriction as a user's SSH key though, and can only be attached to a single repository. This reduces the potential damage that can be done if the key is compromised. For build servers they are often not well suited, because it is often not possible to configure authentication per repository.
For your use case, a machine user seems to be the best option. This is a dedicated user account that is only used by your build server. Make sure to use a strong password and two factor authentication for this account, and add Jenkins' master key to it. You can then add the machine user as a collaborator on the repositories you need in Jenkins.
With regards to security, be as restrictive as possible: only the repositories that are required, and only with read permissions. This is also the reason why you should use a machine user instead of an actual user account. For Jenkins, you (usually) don't need write access to a repository. By limiting the access rights for the server key, the impact of a compromised key is reduced.
Questions:
If I have a user group related to clients added to a repository with read access, would they be able to clone the repository on their local system?
If yes, what measures should I take to keep a group or user restricted to issue tracker only and not the code, means they should be able to create,update and close the issues but they should not be able to clone the repository, is there any way to do it, as I do not want the client to have access to the code until he has paid for the whole project.
Bitbucket's permissions do not support what you want to do.
Users with read access can clone the repository:
View, clone, and fork the repository code. All public repositories grant all Bitbucket Cloud users read permissions automatically. Read access on a repository also allows users to create issues, comment on issues, and edit wiki pages.
There is no configuration that permits users to create and freely browse issues while restricting read access to the repository. The most likely setting would be private repository / public issue tracker, but in this case access to the issue tracker for users without repository access is restricted:
Only users who have access to the private repository can create an issue. Other Bitbucket users and any Internet browser can view the issue tracker if you publish the URL.
There may be other services that support your requirements.
I'm a collaborator with https://github.com/martinh/libconfuse/, so I can
push and tag stuff. Most references on the Interwebs is for this URL, so
it would be convenient to be able to set up Travis-CI (and more) for this
repo, not my own fork. Is this possible? (The original maintainer can no
longer spare the time.)
Considering my options, maybe the simplest way to go about this would be to
maintain everything in my own fork? (https://github.com/troglobit/libconfuse)
You're required to have Github admin access for setting up the hooks, so yes use the simple way and fork it or see that the owner gives you the required access.
Alternatively he might be convinced to transfer ownership but github does not do redirects for repo's (they do for hosted sites), which would defeat the purpose (https://help.github.com/articles/transferring-a-repository/)
From https://groups.google.com/forum/#!topic/cocoapods/i7dwMV4EqZ8
I'm a bit of a CocoaPods newbie and have never created a Pod before, but I'm looking into how one would be able to automate publishing of public podspecs from within my organization's continuous deployment infrastructure, which has some properties about it that makes using Trunk difficult. They are:
The account/owner that does the publishing is a non-human system account.
The aforementioned system account does not have a home directory on the machine that it runs on, which will hamper usage of a .netrc file (what Trunk uses for storing session tokens). This should be able to be worked around by creating a fake home directory and setting the HOME environment variable to it, since that's what the netrc gem looks for.
The machine that does the publishing is assumed to have "no state," meaning the publish could always occur on a different machine that has never been registered.
I've thought about creating the initial .netrc for this account, storing the token from that in our secure storage, and retrieving it to build a .netrc file when publishing. There's a few things about this that I don't think work well:
The tokens returned by Trunk appear to expire, which would mean having a human to periodically create a new token and update our secure storage.
Trunk sessions appear to be tracking the IP address of the machine they were created from, which I assume publishing requests are validated against and fail if the IP addresses do not match. Because publishing takes places on different machines, this would imply requiring to create a new session every time this publishing automation is ran. Practically speaking, I would hope that the IP addresses for these machines would come from the same external IP address, but that's not an assumption I can live with.
The next alternative I would have is much more complex: having the publish automation register a new session, wait for the registration email, then verify the session with the link in the email before proceeding with the publish. I don't know how to actually accomplish this off the top of my head, but I think it's a viable, if not time-consuming to implement, solution. Any suggestions on how to accomplish that are welcome.
Are there any alternatives for publishing public podspecs? It seems to me that Trunk doesn't really support this use case; it'd be great if there was a way to accommodate for it in Trunk.
No until now.
But I issued Question to be possible to automate pod trunk push with CI service like travisCI.
And then, a developer merged the commit (Allow specifying a Trunk token via the COCOAPODS_TRUNK_TOKEN environment variable) that will allow to automate publishing.
I don't try it, but maybe can push automatically.
[Added] After I wrote above, I tried it and it worked well.
I'm wiring up some LibGit2Sharp code to VSO, so I need to use alternate credentials to access it. (NTLM won't work) I don't want to have to manage these cleartext credentials - I'm already using git-credential-winstore to manage them, and I'm happy logging onto the box if I ever need to update those creds.
I see that I can pass in DefaultCredentials and UsernamePassword credentials - is there any way I can get it to fetch the creds from the global git cred store that's already configured on the machine?
Talking to external programs is outside of the scope of libgit2, so it won't talk to git's credential helper. It's considered to be the tool writer's responsibility to retrieve the credentials from the user, wherever they may be.
The credential store is a helper for the git command-line tool to integrate with whatever credcential storage you have on your environment while keeping the logic outside of the main tool, which needs to run in many different places. It is not something that's core to a repository, but a helper for the user interface.
When using libgit2, you are the one who is writing the tool which users interact with and thus knows how to best get to the environment-specific storage. What libgit2 wants to know is what exactly it should answer to the authentication challenge, as any kind of guessing on its part is going to make everyone's life's harder.
Since the Windows credential storage is accessed through an API, it's not out of the question to support some convenience functions to transform from that credential storage into what libgit2's callback wants, but it's not something where libgit2 can easily take the initiative.