[Env] Add buildFlavor to package info
#161930
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pgayvallet
added
Team:Core
|
Pinging @elastic/kibana-core (Team:Core) |
pgayvallet
commented
Jul 14, 2023
| @@ -15,6 +15,7 @@ export interface PackageInfo { | |||
| buildNum: number; | |||
| buildSha: string; | |||
| buildDate: Date; | |||
| buildFlavor: BuildFlavor; | |||
There was a problem hiding this comment.
The actual change. Everything else is just adapting the test usages.
| @@ -26,3 +27,5 @@ export interface EnvironmentMode { | |||
| dev: boolean; | |||
| prod: boolean; | |||
| } | |||
|
|
|||
| export type BuildFlavor = 'serverless' | 'traditional'; | |||
There was a problem hiding this comment.
I went with traditional for the "unflavored" version, but I can go with something else if we have a better idea.
Dosant
approved these changes
Jul 18, 2023
34 tasks
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Public APIs missing exports
History
To update your PR or re-run it, just comment with: |
ThomThomson
pushed a commit
to ThomThomson/kibana
that referenced
this pull request
Aug 1, 2023
## Summary Add a `buildFavor` property to `Env` (accessible from the plugin's initializer context), Mimicking the idea of ES's `version.buildFlavor` field. Note: this is not supposed to be a replacement for feature flags, but can be useful when wanting to toggle features based on actual capabilities of our serverless product. Also, we already expose this value through the configuration via the `serverless` context value, so it now adds another way to access the information. --------- Co-authored-by: Kibana Machine <[email protected]>
azasypkin
added a commit
that referenced
this pull request
Aug 23, 2023
Closes #161337 ## Summary Uses build flavor(see #161930) to disable specific Kibana security, spaces, and encrypted saved objects HTTP API routes in serverless (see details in #161337). HTTP APIs that will be public in serverless have been handled in #162523. **IMPORTANT: This PR leaves login, user, and role routes enabled. The primary reason for this is due to several testing mechanisms that rely on basic authentication and custom roles (UI, Cypress). These tests will be modified to use SAML authentication and serverless roles in the immediate future. Once this occurs, we will disable these routes.** ### Testing This PR also implements testing API access in serverless. - The testing strategy for disabled routes in serverless is to verify a `404 not found `response. - The testing strategy for internal access routes in serverless is to verify that without the internal request header (`x-elastic-internal-origin`), a `400 bad request response` is received, then verify that with the internal request header, a `200 ok response` is received. - The strategy for public routes in serverless is to verify a `200 ok` or `203 redirect` is received. ~~blocked by #161930~~ ~~blocked by #162149 for test implementation~~ --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Aleh Zasypkin <[email protected]> Co-authored-by: Aleh Zasypkin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Add a
buildFavorproperty toEnv(accessible from the plugin's initializer context), Mimicking the idea of ES'sversion.buildFlavorfield.Note: this is not supposed to be a replacement for feature flags, but can be useful when wanting to toggle features based on actual capabilities of our serverless product. Also, we already expose this value through the configuration via the
serverlesscontext value, so it now adds another way to access the information.