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

Support installing plugins from GitHub Enterprise #1643

Closed
bendrucker opened this issue Jan 9, 2023 · 3 comments · Fixed by #1751
Closed

Support installing plugins from GitHub Enterprise #1643

bendrucker opened this issue Jan 9, 2023 · 3 comments · Fixed by #1751

Comments

@bendrucker
Copy link
Member

bendrucker commented Jan 9, 2023

TFLint plugins are installed from GitHub, using its releases API. While there are no plans to support other plugin sources, we should support alternate GitHub installations (GitHub Enterprise).

See BaseURL: https://pkg.go.dev/github.com/google/go-github/github#Client

Currently the code creates a new GitHub client for each installation rather than sharing across the whole command run. So it's theoretically possible to mix plugins from different hosts without major refactoring. Currently, the internal plugin config has SourceOwner and SourceRepo. It would also need SourceHost. That could then be used to construct the base URL for the GitHub client for that plugin.

Debug logs that hardcode https://api.github.com should be amended to use BaseURL.

Originally requested in #1202 (comment)

@ChiefAntiphates
Copy link

This is an issue that we've just encountered. We've written a custom plugin and created a release but are unable to use that plugin because the source is github.<company_name>.com as we are using a github enterprise.

Are there plans to implement this in the near future?

@bendrucker
Copy link
Member Author

There are no plans, if you need this in the near future please take the time to follow the guidance above and make an attempt at a PR.

@bendrucker
Copy link
Member Author

Re: #1734

If this could be altered to include a wildcard between github and .com then we could use our plugin hosted on our enterprise

Works for your setup, sure, but not an appropriate generic solution. There's no requirement on hostnames and users could pick gh, ghe, or literally anything else.

If anything, the way to validate a GitHub server is to make a request to / and look for either response headers (X-Github-Request-Id) or body keys (respository_url). Or the requests could just be allowed to fail later if an invalid host is supplied, no different than providing a non-existing org/repo.

If you can get this 80% of the way there, I can review/finish it. I don't have a GHES instance to test against nor can we test this in CI so we definitely need someone to step up to see this one through.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants