fix(repositoryUrl): on beta repositoryUrl needs auth for pre-release flows

[jmodjeski75]

Fixing issue with authentication for repositoryUrl not being used for prerelease workflow

[jmodjeski75]

possible fix for #1170 #1156

[gr2m]

Thanks for the great PR 👍

[pvdlg]

I'm not sure those changes were necessary. It seems the change is to use the authenticated URL to call git ls-remote. However this command should work without authentication, as the the CI was able to clone the repo.

My understanding is that if git clone works then git ls-remote should work as well.
How come the repo was cloned successfully but the branches couldn't be read on the remote?

[pvdlg]

Also this commit make the build fail: https://travis-ci.org/semantic-release/semantic-release/builds/541896951?utm_source=github_status&utm_medium=notification

[gr2m]

Let’s revert and then try again

[pvdlg]

The build error happens only on Travis though, not locally.
I'll investigate a bit more and if I can't find a solution I'll revert and work on it later.

[jmodjeski75]

I'm not sure those changes were necessary. It seems the change is to use the authenticated URL to call git ls-remote. However this command should work without authentication, as the the CI was able to clone the repo.

My understanding is that if git clone works then git ls-remote should work as well.
How come the repo was cloned successfully but the branches couldn't be read on the remote?

@pvdlg
Are you using a private repository? git ls-remote for a private repository requires auth

See: https://git-scm.com/docs/git-ls-remote.html references https://git-scm.com/docs/git-fetch#_git_urls_a_id_urls_a

[pvdlg]

Are you using a private repository? git ls-remote for a private repository requires auth

Yes but that auth should already be provided one way or another by your CI (ssh key or environment variable or other).

How could your CI run git clone otherwise?
What I don’t understand is how git clone could work while git ls-remote doesn't?

[jmodjeski75]

git clone <with-auth-url>

[pvdlg]

The git clone is done by your CI way before semantic-release run.

Where does the <with-auth-url> come from? If your CI uses an authenticated URL to clone why doesn't it set that URL in the origin of the repo.
How do you end up in the situation of your CI running git clone <with-auth-url> then setting the non authenticated URL as the origin of the clone?

Before this PR, the git ls-remote was called with origin in order to use whatever remote URL the CI uses which should at least gives read permission.

[jmodjeski75]

why doesn't it set that URL in the origin of the repo.

Where is this documented?
Because this would not be necessary
https://github.com/semantic-release/semantic-release/blob/master/lib/get-git-auth-url.js#L17

Before this PR, the git ls-remote was called with origin in order to use whatever remote URL the CI uses which should at least gives read permission.

no it assumed there was a remote named origin

[semantic-release-bot]

🎉 This PR is included in version 16.0.0-beta.20 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[pvdlg]

Where is this documented?

What do you mean? In the your CI doc? I don't know.
It's the way that every CI I tested works. It doesn't make much sense for the CI to set the origin as an URL that doesn't works.

What CI are you using?

no it assumed there was a remote named origin

I don't know is assumed is the right term here. Every repo on which semantic-release would run is a local clone and calling git clone <some_url> setts the origin to <some_url>.

It seems your CI, for some reason calls git clone <auth_url> and then git remote set-url origin <non_auth_url>. I don't see what's the point of doing that.

[jmodjeski75]

What do you mean? In the your CI doc? I don't know.

Here in this repository, no where in the docs does it indict having to call git remote add origin <auth_url> if this were true, this would not be necessary. If the consumer, CI or not, should explicitly have a remote named origin and set to the appropriate url for both git fetch and git push it should be clearly documented.
But based on the documentation here that convenience of figuring out which auth scheme to use and what the correct repository url with auth for git fetch and git push should be is provided but if that is incorrect, remove, close the loop.

[pvdlg]

I tested semantic-release on something like 20 different CI. All of them set the origin of the cloned repo as a URL that has read access to the repo. Some use and ssh key, some other use use an URL formatted with credentials, but they all make sure you can run git commands that read the repo without having to do anything (if you don't specify a URL git will use origin by default).

This is why the doc doesn't say to call git remote add origin <auth_url> because for the CIs I tested it's not necessary. Setting the origin of the repo to an URL that is unusable doesn't make sense to me, this is why I assumed this case would never happen. Your issue is the first occurence of this problem.

It seems your CI behave differently. Again, what CI are you using?

[jmodjeski75]

(if you don't specify a URL git will use origin by default).

sure but the repository may not have a remote called origin but I digress. See git remove.
IE. git remove remove origin or git remove rm origin

It seems your CI behave differently. Again, what CI are you using?

I am using Jenkins
#1156 - TeamCity
#1170 - a docker based CI of some kind

[alexan]

yes jenkins uses different git authentication, for checkout and for what is available, when you use git binary directly. It even gets more complicated, when the pipeline is running in a docker container,

[alexan]

I don't know if these changes are connected. But after updating and usage of beta-20 in a existing project I got another error: #1199

[semantic-release-bot]

🎉 This PR is included in version 16.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀