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

task: enabled in OSS. #8856

Merged
merged 7 commits into from
Nov 29, 2024
Merged

task: enabled in OSS. #8856

merged 7 commits into from
Nov 29, 2024

Conversation

chriswk
Copy link
Member

@chriswk chriswk commented Nov 26, 2024

Add a column to projects and environments signifying if they're on even if instance is reverted back to OSS after having been in enterprise.

Points of discussion before merging:

  • I've updated the environments store to only return environments where enabled_in_oss is true when isOss is true.
  • I've updated the project store to only return id = 'default' when isOss is true
  • I've updated the client features endpoint to only return project = 'default' configurations.
  • Going back and forth between Enterprise and OSS does not delete any data, but it just won't be visible when running OSS
  • Currently our isOss math is !isEnterprise && ui.environment !== 'pro' && !isTest // the isTest was included to avoid having to set all our tests up to flag themselves as enterprise.
  • I would've liked the isOss check to be replaced with a call to license service and maybe two separate checks hasAdditionalProjects and hasAdditionalEnvironments, but didn't want to have a store depending on a service so for now, the check is only dependent on configuration.

@chriswk chriswk self-assigned this Nov 26, 2024
Copy link

vercel bot commented Nov 26, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
unleash-monorepo-frontend ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 28, 2024 3:01pm
1 Skipped Deployment
Name Status Preview Comments Updated (UTC)
unleash-docs ⬜️ Ignored (Inspect) Visit Preview Nov 28, 2024 3:01pm

Copy link
Contributor

github-actions bot commented Nov 26, 2024

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

PackageVersionScoreDetails

Scanned Files

Copy link
Contributor

@gastonfournier gastonfournier left a comment

Choose a reason for hiding this comment

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

Overall looks fine, I'm wondering (not requiring) if moving the calculation of isOss outside the constructor would be better... maybe a method in config object could be central enough

Comment on lines 3 to 4
ALTER TABLE environments ADD COLUMN enabled_in_oss BOOLEAN NOT NULL DEFAULT false;
ALTER TABLE projects ADD COLUMN enabled_in_oss BOOLEAN NOT NULL DEFAULT false;
Copy link
Contributor

Choose a reason for hiding this comment

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

Hacking this would not be difficult... just run a query against the db changing all enabled_in_oss to true... it adds some complexity though

Copy link
Member Author

@chriswk chriswk Nov 27, 2024

Choose a reason for hiding this comment

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

indeed, or you can just hack the store and remove the isOss check. The goal is not to stop all use of enterprise features (users willing to change the code won't be deterred for long anyway), but to at least make it require a conscious action to work around.

Copy link
Member

Choose a reason for hiding this comment

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

I think G has a point here though. I think the barrier between touching source code and touching database entities is very different, because patching source code means redoing that every time we create updates and dealing with the merges and database patches are trivially executed once.

I'm not sure I'm convinced either way but I wouldn't object to seeing "default", "development", "production" as a constant in source code

Copy link
Member Author

Choose a reason for hiding this comment

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

And we hide default by default these days, so it's really only development and production.
Yeah ok, let's be explicit then. Updating

@chriswk
Copy link
Member Author

chriswk commented Nov 27, 2024

This failing e2e test is real, because it's testing additional projects, and we haven't enabled enterprise here. I'll look into how to solve that.

Copy link
Member

@sighphyre sighphyre left a comment

Choose a reason for hiding this comment

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

I think the approach is okay because I can't see another way but I would really like to see some tests around this, if for no other reason than the likelihood of future patches to adjacent code completely borking the queries

@@ -27,6 +27,7 @@ export class ClientFeatureToggleService {
this.logger = getLogger('services/client-feature-toggle-service.ts');
this.segmentReadModel = segmentReadModel;
this.clientFeatureToggleStore = clientFeatureToggleStore;
const isTest = process.env.NODE_ENV === 'test';
Copy link
Member

Choose a reason for hiding this comment

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

Why this change?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because my initial thought had the oss check on services, and I forgot to remove the last trace. :)

Comment on lines 3 to 4
ALTER TABLE environments ADD COLUMN enabled_in_oss BOOLEAN NOT NULL DEFAULT false;
ALTER TABLE projects ADD COLUMN enabled_in_oss BOOLEAN NOT NULL DEFAULT false;
Copy link
Member

Choose a reason for hiding this comment

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

I think G has a point here though. I think the barrier between touching source code and touching database entities is very different, because patching source code means redoing that every time we create updates and dealing with the merges and database patches are trivially executed once.

I'm not sure I'm convinced either way but I wouldn't object to seeing "default", "development", "production" as a constant in source code

@sighphyre
Copy link
Member

the isTest was included to avoid having to set all our tests up to flag themselves as enterprise.

Nice

Add a column to projects and environments signifying if they're on even
if instance is reverted back to OSS after having been in enterprise
Copy link
Contributor

@gastonfournier gastonfournier left a comment

Choose a reason for hiding this comment

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

Ok, looks good to me, it's still easy to hack, but it's better than not doing anything

Comment on lines +446 to +448
if (isOss) {
return queryBuilder.andWhere('project', '=', 'default');
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks easy to hack, but fair enough

@chriswk chriswk merged commit 663b169 into main Nov 29, 2024
11 checks passed
@chriswk chriswk deleted the task/enabledInOss branch November 29, 2024 08:43
sjaanus added a commit that referenced this pull request Nov 29, 2024
sjaanus added a commit that referenced this pull request Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants