-
Notifications
You must be signed in to change notification settings - Fork 6.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
scaffolder: Implement hooks for collecting secrets #25975
Conversation
Changed Packages
|
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
3184a5a
to
c821e6d
Compare
a33dbf7
to
ff0f407
Compare
@@ -69,6 +70,35 @@ export function createFormField< | |||
TUiOptions extends z.ZodType, | |||
>(opts: FormFieldExtensionData<TReturnValue, TUiOptions>): FormField; | |||
|
|||
// @public | |||
export function createScaffolderFormDecorator< |
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.
Does it make sense to expose it to zod as it is done here? #26957
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 that we want to align so that zod is exposed like the below:
It's copying how the new frontend system exposes zod, so that you write things like this:
createScaffolderFormDecorator({
input: {
myInput: (z) => z.string().optional(),
}
});
Same as this https://backstage.io/docs/frontend-system/architecture/extensions#extension-configuration
I think that other PR needs updating, just haven't had chance to leave feedback there yet.
e95c999
to
dae54bd
Compare
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
e980991
to
4a2e354
Compare
TInputSchema extends { [key in string]: (zImpl: typeof z) => z.ZodType } = {}, | ||
TDeps extends { [key in string]: AnyApiRef } = { [key in string]: AnyApiRef }, | ||
TInput extends {} = { | ||
[key in keyof TInputSchema]: z.infer<ReturnType<TInputSchema[key]>>; |
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.
Aim to have the defaults for these be the "any" version, so the first one would default to { [key in string]: (zImpl: typeof z) => z.ZodType }
. With that it should be possible to get rid of the AnyScaffolderFormDecorator
and just use ScaffolderFormDecorator
without type args instead
TInputSchema extends { [key in string]: (zImpl: typeof z) => z.ZodType }, | ||
TDeps extends { [key in string]: AnyApiRef }, |
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.
Aim to have the defaults for these be the "any" version but expressed with the more exact type than any
, so the first one would default to { [key in string]: (zImpl: typeof z) => z.ZodType }
. With that it should be possible to get rid of the AnyScaffolderFormDecorator
and just use ScaffolderFormDecorator
without type args instead.
}); | ||
} catch (ex) { | ||
// eslint-disable-next-line no-console | ||
console.error(ex); |
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.
Probably need proper error handling here no?
const formDecorator = formDecorators?.get(decorator.id); | ||
if (!formDecorator) { | ||
// eslint-disable-next-line no-console | ||
console.error('Failed to find form decorator', decorator.id); |
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.
Same here, would need to forward this to the user
input?: TInputSchema; | ||
}; | ||
deps?: TDeps; | ||
fn: ( |
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.
Thinking it might be nice to call this one decorator
or smth?
@@ -190,6 +220,50 @@ export interface ScaffolderFieldProps { | |||
required?: boolean; | |||
} | |||
|
|||
// @alpha (undocumented) | |||
export type ScaffolderFormDecorator< |
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.
As discussed I'm thinking it's best to make this an opaque type
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.
Nice! 👍
Just a minor thing, and then perhaps it's best to add some docs for this too?
@@ -379,5 +414,20 @@ export type TemplateWizardPageProps = { | |||
}; | |||
}; | |||
|
|||
// @alpha (undocumented) | |||
export const useFormDecorators: ({ |
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.
hmm, should this one really be exported?
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.
Hmm maybe not at the moment, you can provide your own TemplateWizardPage
and this would need to be a building block of it. Will remove it for now.
createApiFactory({ | ||
api: formDecoratorsApiRef, | ||
deps: {}, | ||
factory: () => DefaultScaffolderFormDecoratorsApi.create(), |
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.
Are you thinking we should be shipping any built-in decorators btw? Or in case that might be a security issue or such, having default ones be provided in the new system as extensions that are disabled by 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.
Potentially, maybe the ones for provider tokens for sure might be a good idea, but nothing concrete as yet. Just wanna see how this these things feel, and we go from there.
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh> Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh> Signed-off-by: blam <ben@blam.sh>
Signed-off-by: blam <ben@blam.sh>
1c62680
to
4c8acd2
Compare
Signed-off-by: blam <ben@blam.sh>
4c8acd2
to
e37287d
Compare
Thank you for contributing to Backstage! The changes in this pull request will be part of the |
This is a stab at implementing #16996 and being able to move some of the secret collection amongst other things outside of the react context.