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

chore: Read Gitlab server URL from env for prime integrations #9910

Merged
merged 2 commits into from
Jul 2, 2024

Conversation

Dschoordsch
Copy link
Contributor

@Dschoordsch Dschoordsch commented Jul 1, 2024

Description

Right now it is hardcoded, but private Gitlab instances behave like the public one, so for some Parabol instances it might make sense to point it to a different Gitlab instance.

Demo

https://www.loom.com/share/bd9d06ef81b74f74b46ca2e80af04383?sid=3e3369ab-3e94-4d7e-8fb2-7d960cffe032 🔒

Testing scenarios

  • Set the URL
  • run yarn build && yarn predeploy
  • check the correct value is set in PG

Final checklist

  • I checked the code review guidelines
  • I have added Metrics Representative as reviewer(s) if my PR invovles metrics/data/analytics related changes
  • I have performed a self-review of my code, the same way I'd do it for any other team member
  • I have tested all cases I listed in the testing scenarios and I haven't found any issues or regressions
  • Whenever I took a non-obvious choice I added a comment explaining why I did it this way
  • I added the label Skip Maintainer Review Indicating the PR only requires reviewer review and can be merged right after it's approved if the PR introduces only minor changes, does not contain any architectural changes or does not introduce any new patterns and I think one review is sufficient'
  • PR title is human readable and could be used in changelog

Right now it is hardcoded, but private Gitlab instances behave like the
public one, so for some Parabol instances it might make sense to point
it to a different Gitlab instance.
Copy link
Contributor

@rafaelromcar-parabol rafaelromcar-parabol left a comment

Choose a reason for hiding this comment

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

Other than my inline comment, LGTM.

This would be a great use case for you to test the process of adding a new environment variable to the application 😸 You have Loom videos and documentation explaining how to do it, but please, let me know if you need any help with that 😃

@@ -8,7 +8,7 @@ const upsertGlobalIntegrationProvidersFromEnv = async () => {
authStrategy: 'oauth2',
scope: 'global',
teamId: 'aGhostTeam',
serverBaseUrl: 'https://gitlab.com',
serverBaseUrl: process.env.GITLAB_SERVER_URL ?? 'https://gitlab.com',
Copy link
Contributor

Choose a reason for hiding this comment

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

Why a default value? IMHO we should just use the env GITLAB_SERVER_URL and on the .env.example we can have our default value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did not want to touch the current deployments without any need.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's true that removing that default value is a breaking change. Ok, let's keep it there.

I'm just against default hardcoded values in general 😸

@Dschoordsch Dschoordsch merged commit 830235d into master Jul 2, 2024
5 checks passed
@Dschoordsch Dschoordsch deleted the chore/readGitlabServerURLFromEnv branch July 2, 2024 15:07
@github-actions github-actions bot mentioned this pull request Jul 4, 2024
24 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants