-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Allow ConfigDeprecationProvider functions to access current "branch" #112221
Comments
Pinging @elastic/kibana-core (Team:Core) |
Seems like this could be another use case for #95389, as the docLinks service is intended to help solve this problem. Then instead of exposing a branch/version to the deprecation providers, we just inject the docLinks. |
The docLinks are currently client-side only (and note that moving it elsewhere would require changes in the doc build CI job) |
Yeah, I know it is client-side only, I guess what I was saying is that if we addressed #95389 & moved it to the server, we could then inject it into the deprecation providers. This would require passing However, I think the ideal solution would be moving docLinks to a package (and updating the doc build job) as you outlined in #95389 (comment). If we wanted to inject the branch name, that would be fairly straightforward in the current implementation as |
Another use case for this is when consumers use the Deprecations Service to register deprecations (example: #110960). |
Btw, if possible, we need this for 7.16 as we want to make sure those running 7.16 once 8.0 comes around still sees the right deprecation URLs |
With such short-time notice, imho our only option would be to go the hacky way and simply expose the version to the config deprecation provider, at least for now. export type ConfigDeprecationProvider = (factory: ConfigDeprecationFactory) => ConfigDeprecation[]; could become export type ConfigDeprecationProvider = (factory: ConfigDeprecationFactory, context: DeprecationContext) => ConfigDeprecation[];
interface DeprecationContext {
version: string;
branch: string;
// then, later, we could inject the docLinks here
} which would also have the upside to not be breaking the existing usages of this type/API |
We discussed with the team during today's weekly, and decided to go with the quickest approach for We'll include this issue in our current sprint |
That's great, do you think we can expose those fields in the existing kibana/src/core/server/deprecations/types.ts Lines 81 to 84 in 249c5fb
|
Would make sense, will look at it too |
@jportner After taking a look, I'm not sure about the need to add these info to Config deprecations are 'statically' registered via the Feature deprecations, on the other hand, are registered from the plugin's Do you think this would significantly improve the DX to expose them directly from |
@pgayvallet i think it makes sense to expose them to both contexts especially since we might need this information for config deprecations. I believe it is possible to access this information in there. |
This is handled by #113600. I was specifically asking about feature deprecations here (registered directly via |
Yeah, I was aware, it just seems like all consumers of feature deprecations will need to know the current branch, so we might as well expose that from the context if it's not too much trouble. If it's going to be a headache I don't think it's critical though. |
In the custom deprecation messages (created inside functions of type
ConfigDeprecationProvider
), it's possible to put a URL for a documentation page:kibana/x-pack/plugins/security/server/config_deprecations.ts
Lines 39 to 40 in 4b33115
However currently, the deprecation code doesn't have access to the current release "branch" (e.g.
6.8
,7.15
,7.16
) so that it can customize that part of the URL, e.g:For example, say you're writing a deprecation message that's meant to go live in 7.16, and you want to link to a documentation URL in that version of the documentation. If 7.16 isn't released yet, it's documentation isn't live either. So if you hardcode
7.16
into the URL it will be a 404 until the documentation is released. Alternatively you can putcurrent
. But when 8.0.0 is released,current
will now point to that and everybody who's still running 7.16 might now not see the right documentation or even get a 404 if that page has been removed in 8.0.0.So we need some way to make these
documentationUrl
properties "dynamic".The text was updated successfully, but these errors were encountered: