I am observing a strange behavior while setting up a new job with a “FreeStyle project” with “none” credentials.
Ideally, with none credentials, the Jenkins should throw an error, while authenticating thebitbucket url. However, surprisingly it got authenticated (at the time of configuring the job). Later when I ran the job (with “none” credentials) it also cloned the repository contents in my workspace folder and the job turned out to be successful.
I dont understand the following:
=> what’s the use of creating a new “Jenkins” credentials, when “none” itself downloads the code?
=> what’s the use of creating an “App Password” in Bitbucket?
I want that:
=> the Jenkins should throw authentication error while connecting the bitbucket url when I specify “none” in the “credentials” section
=> the Jenkins should successfully authenticate the bitbucket url when I specify / select a valid “Jenkins” user.
The repository is probably public. If the repository is public, then it can be cloned with https without requiring credentials. There are two options to achieve the behavior you describe:
Make the repository private
Use an ssh URL to clone the repository instead of an https URL. An ssh URL always requires a credential. If a credential is not provided, the clone will fail, even with a public repository.
Hello Mark,
Thank you very much for the same.
However, for option 1 suggested by you, I checked and found that in bitbucket the option “This is a private repository” is checked for this repository, thereby implying that its private. So why does it still authenticates with “none”?
Nevertheless, I will try for the second option. Will reach you if stucked up.
Hello Mark,
With the 2nd option (SSH) public - private combination, things are working .
However, will it be possibly for you to share your insights as to why it was working with “none” credentials over https, despite the repository having “private” access levels.?
Command line git includes a credentials manager feature that can retain repository credentials in a cache for a period after their initial use. The Jenkins git plugin does not enable the credentials manager but it is possible that the account where you are running the Jenkins agent has the git credentials manager enabled and a cached copy of the credentials was used to access the repository.
Credentials can also be embedded directly into the https repository url as in https://username@password:hostname/directoryname.git. Since you didn’t mention that form of the repository URL, I assume you did not embed the credentials in the http repository URL.
