For non-authorized user this would left Overview with a message saying that the content of the repo is private and Issues, for authorized users they would have everything but the Pull-requests tab.

@pingou should the private repo be visible under "All projects"?

No, actually.

Any progress on this?

I'm also interested to this feature and I hope to see it soon :)

Two things about this subject:

• We will probably want a big on/off switch to entirely disable private repos on a pagure instance (ie: a boolean in the configuration file)

• We could do two approaches to create private repos: self-service just like what we do now, or only allow admins to create private repos

One more thought:
we had the request a while back for a private git repo with public tickets, so this might also be a settings to add, allow public tickets but hide the code.

Two things about this subject:

We will probably want a big on/off switch to entirely disable private repos on a pagure instance (ie: a boolean in the configuration file)
I think this is a good idea.

We could do two approaches to create private repos: self-service just like what we do now, or only allow admins to create private repos

Personally, i think we should do both of these -- with a pagure option to choose the one a pagure instance wants to use. For pagure.io the setting here is probably for admins to have the ability to create private repos, as it is only a select few that should have that ability in pagure.io

One more thought:
we had the request a while back for a private git repo with public tickets, so this might also be a settings to add, allow public tickets but hide the code.

For this one, it might be better to just think of it as adding an option to make tickets public / private (this is proabably a seperate issue TBH) and this would be not dependent on if the code in a repo is public or private -- the use case here would be if someone wants to close off issues but let admin / people with commit access to be able to see them.

also, we need to think of how PR's are going to work on this one too...

Do we want people with commit access to a repo to still be able to create a fork (that is also private), so they can use that workflow? and also, what happens if commit access is revoked from someone that has a fork.

Two things about this subject:
We will probably want a big on/off switch to entirely disable private repos on a pagure instance (ie: a boolean in the configuration file)
I think this is a good idea.

+1

We could do two approaches to create private repos: self-service just like what we do now, or only allow admins to create private repos

Personally, i think we should do both of these -- with a pagure option to choose the one a pagure instance wants to use. For pagure.io the setting here is probably for admins to have the ability to create private repos, as it is only a select few that should have that ability in pagure.io

I would give priority to self-service but I agree both are important.

One more thought:
we had the request a while back for a private git repo with public tickets, so this might also be a settings to add, allow public tickets but hide the code.

For this one, it might be better to just think of it as adding an option to make tickets public / private (this is proabably a seperate issue TBH) and this would be not dependent on if the code in a repo is public or private -- the use case here would be if someone wants to close off issues but let admin / people with commit access to be able to see them.

+1

Having a mode where admins need to make a project public, with private by default is useful. This can keep people from inadvertantly making repos public, say when cloning.

This could be a key feature when someone is choosing between gitlab and pagure for a creating a forge service.

I am also interested in private repository... in fact in "group based" private repository.

Even more, I consider "project" does not mean "single source repository". In fact, it should be great if a project may hold multiple repositories with common configurations (and per repository dedicated configurations).

This could have value for Fedora in general as well.

It'd be useful for OpenMandriva and Mageia as well.

OpenMandriva is considering moving to private Pagure deployment and they use a few private GitHub repositories for storing specific secrets for their build/deploy environment.

Being able to still make those private on an OpenMandriva-hosted Pagure server would be very helpful.

Mageia has something similar for its own infrastructure secrets.

This last comment makes me realize this ticket is still open, this feature has been implemented a while back. It is turned off by default but changing the (PRIVATE_REPO)[https://docs.pagure.org/pagure/configuration.html#private-projects] configuration key will turn on this feature.

(Note: we don't use it much so there are a couple of issues around this feature that has been reported and will need fixing)

See also: #3273

Doesn't seem to be enabled on pagure.io. Can it be?

@mikem the code supports it but it's an instance-wide configuration option which is not enabled for pagure.io.

It'll have to be a fedora-infra discussion to turn it on, but tbh, I'm not sure I'm in favor.

This one seems to be complete from a Pagure general point of view, so i think we should close it.

Maybe discussions with Fedora infra are needed to getting this enabled on pagure.io

This one seems to be complete from a Pagure general point of view, so i think we should close it.
Maybe discussions with Fedora infra are needed to getting this enabled on pagure.io

+1, let's close :)

Any idea how we can ask the Fedora team to enable Private Repos on Pagure.io?

That'd be super useful.

Any idea how we can ask the Fedora team to enable Private Repos on Pagure.io?
That'd be super useful.

What use do you see for them?

Literally no use at all, in fact it'd take up their resources.

@dylanger

Literally no use at all, in fact it'd take up their resources.

Perhaps Pagure is having an attribution problem. It seems that you asked for them to be enabled in https://pagure.io/pagure/issue/300#comment-538774

I agree that they are not needed on the current pagure.io

@dylanger

Literally no use at all, in fact it'd take up their resources.

Perhaps Pagure is having an attribution problem. It seems that you asked for them to be enabled in https://pagure.io/pagure/issue/300#comment-538774
I agree that they are not needed on the current pagure.io

Useful for me but not for Pagure is what I mean.

Right. So, @dylanger what is your use case? i.e. what kind of data do you want to store? Is it Fedora related?