-
-
Notifications
You must be signed in to change notification settings - Fork 721
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
task: enabled in OSS. #8856
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files |
There was a problem hiding this 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
src/lib/features/client-feature-toggles/client-feature-toggle-store.ts
Outdated
Show resolved
Hide resolved
src/lib/features/client-feature-toggles/client-feature-toggle-store.ts
Outdated
Show resolved
Hide resolved
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
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. |
There was a problem hiding this 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'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
There was a problem hiding this comment.
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. :)
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; |
There was a problem hiding this comment.
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
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
dd43c67
to
be5b234
Compare
9c2039c
to
c585f8c
Compare
There was a problem hiding this 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
if (isOss) { | ||
return queryBuilder.andWhere('project', '=', 'default'); | ||
} |
There was a problem hiding this comment.
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
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:
enabled_in_oss
is true whenisOss
is true.id = 'default'
whenisOss
is trueproject = 'default'
configurations.!isEnterprise && ui.environment !== 'pro' && !isTest
// the isTest was included to avoid having to set all our tests up to flag themselves as enterprise.hasAdditionalProjects
andhasAdditionalEnvironments
, but didn't want to have a store depending on a service so for now, the check is only dependent on configuration.