Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[projects] allow only github.com and gitlab.com #5113

Merged
merged 1 commit into from
Aug 19, 2021
Merged

Conversation

AlexTugarev
Copy link
Member

No description provided.

@roboquat roboquat requested a review from JanKoehnlein August 9, 2021 10:25
@AlexTugarev AlexTugarev removed the request for review from JanKoehnlein August 9, 2021 10:26
@@ -341,7 +341,8 @@ function GitProviders(props: {

useEffect(() => {
(async () => {
setAuthProviders(await getGitpodService().server.getAuthProviders());
const providers = await getGitpodService().server.getAuthProviders();
setAuthProviders(providers.filter(p => ["github.com", "gitlab.com"].includes(p.host)));
Copy link
Contributor

@gtsiolis gtsiolis Aug 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Does this limit Projects for repositories only from github.com and gitlab.com? I thought Projects could support repositories from self hosted GitHub and GitLab instances, but this is also something we could leave out of the scope of this first iteration. 💭

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. The current GitHub App integration is hard coded with github.com.
  2. I'm new to the GitLab integration for prebuilds in general. It would require testing as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha! Thanks for the insight, @AlexTugarev! Sounds good to leave this out of the scope for now until further demand. Added #5115 to track this feature request.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would still need an approval from a dashboard owner. Looping in @jankeromnes and @svenefftinge in case any of them can take a look at this two-line change. 🏓

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixing this in #5192 😁 also taking a quick look!

Copy link
Contributor

@jankeromnes jankeromnes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many thanks! The code seems to do what's intended, but I don't understand why this change is needed.

Could you please elaborate?

Also, @gtsiolis makes a great point about self-managed GitLabs. I'm aware that we haven't tested them and they might break, but maybe it's still preferable to have something that might "accidentally work" for self-managed GitLabs, rather than something that "definitely fails" (i.e. it's filtered out)?

Still, approving in case you feel this change is really necessary. 😊 Maybe I'm missing something.

/hold

/lgtm

/approve no-issue

@roboquat
Copy link
Contributor

LGTM label has been added.

Git tree hash: 6549ee27944cd231da149ac74d1af4c06c63c5e0

@roboquat
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jankeromnes

Associated issue requirement bypassed by: jankeromnes

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@AlexTugarev
Copy link
Member Author

Also, @gtsiolis makes a great point about self-managed GitLabs. I'm aware that we haven't tested them and they might break, but maybe it's still preferable to have something that might "accidentally work" for self-managed GitLabs, rather than something that "definitely fails" (i.e. it's filtered out)?

@jankeromnes, I'm not sure about the chances that it work nicely out-of-the box with self-manages GitLabs. It sure does not with GitHub Enterprise. But in general, we should deliver tested feature only.

@AlexTugarev
Copy link
Member Author

/unhold

@roboquat roboquat merged commit ea82dd4 into main Aug 19, 2021
@roboquat roboquat deleted the at/lmit-providers branch August 19, 2021 10:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants