I created the deployment via CLI, so I don’t know what GitHub has to do with anything.
I doubly don’t know what that repository has to do with anything because even if I had deployed from a GitHub repository, it wouldn’t have been that.
If I had to deploy from a public GitHub repository in order to create a sharable link, that would totally not work for my use case and defeat the purpose of being able to create a sharable link.
I don’t want anyone commenting on anything, I just want a sharable link to the deployment.
In the screenshot in the instructions it says:
Anyone with the link can view
Visitors must be logged in to comment
That sounds like it might be what I want.
After that, I found that on the project “Overview” page in the “Active Branches” section there’s a single item. In that single item the “Source” button links to a fork of the aws-sdk-js repo in my GitHub account. I never setup any association between my Vercel account and GitHub, so I don’t know how it made the connection to which GitHub account is mine, or why it thinks that random repository has anything to do with anything.
Alright, I figured out what was going on. At some point via old command history I had accidentally executed a git remote add origin and apparently when I then ran vercel it sent information about the Git remote configuration to the server. That’s where the reference to the seemingly random repo came from.
When I removed the remote and ran vercel again, the “Source” button linking to the repo went away and I was able to create the shareable link.
The section of the instructions “Managing Shareable Links” still doesn’t match my experience. That says there will be an “Access” tab in “Settings” :: “Deployment Protection”. I don’t see any tabs there and the “Shareable Links” section doesn’t include anything about the one I created.
I was able to work around the issue, but was going to post again to clarify that the behavior seems like a bug to me.
The CLI is one of the options provided for deployment and according to the documentation:
This method works whether your project is connected to Git or not.
So to recap for clarity:
I’m in a directory that is a Git repository.
The Git repository has a remote configured (on GitHub).
I have not done anything to intentionally connect the Vercel project to the GitHub repository. E.g. I didn’t import a GitHub repository into Vercel or do anything in the Git section of project settings.
I’m using the CLI to deploy (vercel or vercel deploy).
Just by virtue of doing that, I don’t want Vercel to automagically create an association between the Vercel project and the Git repository and do things like:
Change the behavior of creating shareable links.
Link to the remote repository.
I don’t know if the issue is in the CLI, the back end, or a combination, but it seems things are going sideways somewhere.
Re: the other issue, I didn’t follow the instructions closely enough. They say to start at the Dashboard. If I navigate to Settings :: Deployment Protection from there, I do have an Access tab.
What I was doing before was navigating from a project’s Overview to Settings :: Deployment Protection, in which there’s no Access tab, and even the Shareable Links section doesn’t have anything about the link that was created.
That UX initially seems a bit confusing to me, but I’d have to take a closer look now that I know there’s team level and project level settings that have some of the same sub-sections but with different behavior.
This is a feature of the Vercel CLI to collect some repository metadata to enhance the user experience by linking directly to commits or branches from the deployments. It is different than the GitHub integration between the Vercel project and the GitHub repository for preview deployments and automatic deployments.
I understand the message you saw in the tooltip is a bit confusing, but it’s more about the Hobby plan’s limitations than about the state of your remote repository. As you will see in these comparisons, the Hobby plan isn’t suitable for team collaboration, and hence you cannot create public shareable links for private repositories.
Hi @anshumanb, thanks for looking into that and replying.
I’m not sure the scenario I encountered is understood.
This is a feature of the Vercel CLI to collect some repository metadata to enhance the user experience by linking directly to commits or branches from the deployments.
This definitely didn’t enhance my user experience, because I didn’t want, need, or opt-in to linking to GitHub, but I did want and need to create a shareable link.
and hence you cannot create public shareable links for private repositories.
And I don’t want to do that – I want Git / GitHub repositories to have nothing to do with my deployment. That’s why deployed via the CLI. Since I didn’t ask Vercel to do anything with my local or remote repos, the fact that I’m tracking my project with a local Git repo (and have a private remote configured if I choose) should not disable a feature that Vercel would normally provide.
I understand the message you saw in the tooltip is a bit confusing, but it’s more about the Hobby plan’s limitations than about the state of your remote repository.
The tooltip is confusing specifically because what it shows is not a limitation of the Hobby plan. The Hobby plan does allow creating one shareable link per account, which is exactly what I was trying to do. The only reason it didn’t work is because Vercel automagically linked to the remote repo and then had logic that blocked creating the shareable link because of that.
In order to create the shareable link I had to delete the remote configured in my local Git repo and deploy again. That’s literally the only change I made. Since I never asked for an association to be created, I should not have to choose between configuring my Git repo / remote as normal and being able to deploy to Vercel and use the features included in the Hobby account.
