-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add wasm spec factory #14458
base: develop
Are you sure you want to change the base?
Add wasm spec factory #14458
Conversation
I see you updated files related to
|
b581fa6
to
99206f6
Compare
d2b7b4c
to
a6ee8f6
Compare
a6ee8f6
to
7ac404a
Compare
7ac404a
to
3be5957
Compare
"github.com/smartcontractkit/chainlink/v2/core/logger" | ||
) | ||
|
||
type WasmFileSpecFactory struct{} |
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.
For visibility to reviewers:
In a side-channel discussion with Cedric, he mentioned that he thinks this should support URLs as well.
I commented that I thought by the time the workflow runs, it would have already ensured that the file is on the box locally. I was thinking that if it needs to use HTTP to fetch the file, that could be done just once. The HTTP invoker could have a deterministic location to save the workflow file. It could then check if the file exists and download it if it doesn’t. Once the file is on disk, it would invoke the WASM file spec.
I’m open to hearing what others think as well.
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.
One other potential use case, if we end up having any pre-build WASMs that users can run by providing their own config, we could leave them in fixed locations
@@ -1210,7 +1210,7 @@ func (s *service) generateJob(ctx context.Context, spec string) (*job.Job, error | |||
case job.FluxMonitor: | |||
js, err = fluxmonitorv2.ValidatedFluxMonitorSpec(s.jobCfg, spec) | |||
case job.Workflow: | |||
js, err = workflows.ValidatedWorkflowJobSpec(ctx, spec) | |||
js, err = workflows.ValidatedWorkflowJobSpec(ctx, s.lggr, spec) |
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 do we need a logger for validation? Typically we want to either log something, (x)or return an error to be logged - not both.
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 needed it to call into the WASM creation.
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 would rather change the WASM runner to not need it if we're not going to use it.
c1480a7
to
a0cd4bd
Compare
Quality Gate passedIssues Measures |
func (w *WorkflowSpec) Validate(ctx context.Context, logger logger.Logger) error { | ||
s, err := w.SDKSpec(ctx, logger) |
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.
This still seems to be conflating things. We are evidently not constructing something with a logger in order to run it. We are just accessing the Owner
and Name
fields? Is there a different path where s
actually does something interesting? Could we separate that logic from this case where only some minimal metadata is used? (or just pass a NullLogger?)
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.
The workflow binary (if it's WASM) will get run both ways. I can pass the null logger if you want here.
No description provided.