Two different projects can be added with the same slug

[jldec]

It's quite common to own repos in different GitHub orgs with the same repo name. E.g. website or commonly forked repos.

Adding those as projects under the same user or team results in projects with the same slug.

This creates a variety of problems e.g. clicking on either of the 2 projects in the Projects list, opens the same project tabs in the UI (the other project cannot be opened).

To reproduce

• find or create 2 owned repos with the same name under 2 different orgs (or 1 user, 1 org) in GitHub
• use those to create 2 projects in the same team (or user)
• observe that the URLs for both projects (and their sub-paths) are identical

Suggested mitigation

see comment below

[JanKoehnlein]

/schedule

[roboquat]

@JanKoehnlein: Issue scheduled in the meta team (WIP: 0)

In response to this:

/schedule

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[laushinka]

Checked it together with @jldec and it's because of how we structure our url /projects/:projectName/ - it assumes projectName will always be unique. This problem doesn't occur when the same project names are in different teams. We'll write down ideas here on how best to solve this name collision.

[jldec]

Discussed ideas with @laushinka for how to address this issue short term (without redesigning the flow.)

The simplest way may be to block users from creating projects with the same slug in the same team, the same way we block projects which point to the same repo.

In this case, it would be nice to tell users which existing project (in the same team) is using the slug - e.g. with a message like "Name already used by project-x" instead of the rather obscure "already taken" message below.

[laushinka]

Mentioning @AlexTugarev here after a brief mention of this issue earlier today.

[laushinka]

Also looping-in @gtsiolis for the text and design.

[jldec]

A refinement of the above suggested behavior (which simply blocks creation of a duplicate slug) would be somehow to track the GitHub org (or GitLab group) associated with a team, and issue a warning when anyone creates a project which potentially shadows an existing repo in that org.

A variation would be a bulk project creation feature, which helps users to mirror all or some of the repos in the org/group, as projects in the team.

[jankeromnes]

What about using a suffix to guarantee that new Project slugs are always unique within the Team?

E.g. in your example:

• github.com/jldec/website could have been created first, with the slug website
• github.com/fmctraining/website could have been created later, with a slug like website-1
• (then, if you try to add another repository called "website" or "website-1", it could get the slug website-2, etc)

[jankeromnes]

Alternatively, we could also use input field validation to enforce uniqueness, and allow users to edit the slug until it is unique, like when creating new GitHub repositories:

[jldec]

Excellent ideas - I like them both.

Let's move forward the automatic addition of -2, -3, ... for the 2nd, 3rd slug etc. if it isn't too much extra work to implement. That's much better than simply blocking the process as proposed earlier.

I don't think we have a good place in the /new UI to prompt for the slug name - but the proposed owner + name + validation input UI would great for a separate enhancement which allows users to modify the project team/owner and slug in the Project settings later. Was that the place where you were imagining it @jankeromnes ?

[jankeromnes]

Let's move forward the automatic addition of -2, -3, ... for the 2nd, 3rd slug etc. if it isn't too much extra work to implement. That's much better than simply blocking the process as proposed earlier.

Sure! Sounds good to me. 👍

/assign

Was that the place where you were imagining it @jankeromnes ?

I was more thinking of a single page that contains the entire Project creation flow (i.e. replacing our current multi-page wizard flow). Such a UI could live in there, although I don't have a very clear picture of what exactly such a single page form should look like.