🐛 Add a workaround for organisations in GitLab #4415
Conversation
This fixes Contributors. Currently organisations are an experimental features in GitLab this change makes it use the users email domain as a pseudo organisation. The domains are anonymised as these are printed as part of the report and shouldn't be exposed. It's uncertain if the uptake in organisation will be large considering GitLab users are used to using groups for this purpose. Signed-off-by: Amar Takhar <amar@rtems.org>
verm
requested review from
justaugustus and
spencerschrock
and removed request for
a team
| *orgDomain = append(*orgDomain, orgName) | ||
|
|
||
| // Search for domain and use index as unique marker | ||
| for i, domain := range *orgDomain { |
There was a problem hiding this comment.
Not sure how to leverage that to get what I need do you have an example? Thank you.
| // pointer to maintain list of domains and email returns an anonymised | ||
| // string with the slice index as a unique identifier. | ||
| // Pointer is required as we are modifying the slice length. | ||
| func getOrginisation(orgDomain *[]string, orgReal string) string { |
There was a problem hiding this comment.
Should be in clients/gitlabrepo/commits.go since we're dealing with commit email addresses.
There was a problem hiding this comment.
I did not put that there since this should only be a temporary measure and this is specific to GitLab if you want me to move it after happy to do so.
Orginisations in GitLab are an experimental feature with no interface other than the API to get to it. There is no other unique identifier. I agree that it's not ideal nore a good indicator the only other option is to remove it completely but this at least gives us something that may be useful. I did it this way as it seemed the least invasive to support this until Orginisation is settled as a public feature. |
|
We use the Users API to get the Organization, not the Organizations API. As I understand it, it's just the API that's experimental, and Organizations are part of GitLab to stay. |
Yes they are here to stay the way GitLab wants you to set them up is using groups which don't exist in GitHub. If you go to GitLab docs they just want you to setup groups -- this is not what the API being used is it's an entirely new concept for Orginizations similar to how GitHub has them. The concept of 'orginization' does not exist in GitLab yet it is only exposed via an API and it's all experimental. This is why in nearly every case using this API right now is going to return an empty string. The web UI isn't even enabled for it: To summerise: The only way you're going to get a user with an orgnization is if you enable experimental flags and use the API directly. It won't show up anywhere on the web UI nore can you edit it. You can also see here that all of the feature flags are disabled by default for orginization: |
Would it be better to use groups then? e.g if a user is in group |
The problem with this is groups are used for organising permissions. While some may use it in that way there are plenty that don't look at RTEMS for example: I think it will be years until Orgs in GitLab will be used in the same way as GitHub. I'd argue at least email domains being no worse than using groups but my original point is valid. Orgs are coming to GitLab and this is just a temp measure and the ones that causes the least churn since we are running these queries anyway. |
|
This pull request has been marked stale because it has been open for 10 days with no activity |
|
Going to discuss this alternative to Contributors at the weekly sync, as the use of emails also came up in the AzureDevops client |
This fixes Contributors.
Currently organisations are an experimental features in GitLab this change makes it use the users email domain as a pseudo organisation. The domains are anonymised as these are printed as part of the report and shouldn't be exposed.
It's uncertain if the uptake in organisation will be large considering GitLab users are used to using groups for this purpose.
What kind of change does this PR introduce?
Fixes a bug where Contributors were always set to 0 I did not see an open issue for this.
What is the current behavior?
Contributors will always be 0.
What is the new behavior (if this is a feature change)?**
Which issue(s) this PR fixes
NONE
Special notes for your reviewer
What I've done here is used the email domains as a pseudo orginisation and anonymomised it using the slice index as
gitlab-N. This lets Contributors give somewhat useful data and in the future when Orginisation is no longer experimental we'll be able to remove this. I found this to be the least invasive method of handling the situation.Does this PR introduce a user-facing change?
NONE