Considering a func environment command
#1676
Replies: 4 comments 2 replies
-
|
what are the |
Beta Was this translation helpful? Give feedback.
-
|
I like it. This could be really useful and you said the info is available already just scattered. I am also against putting docker daemon info. I see your point about could be useful. But, then how deep do we have to go? I would introduce it like this at the moment, |
Beta Was this translation helpful? Give feedback.
-
|
Seems like this could be quite helpful for integrations: a quick snapshot of the entire system; taking the place of parsing individual command outputs. It also means that any integrations are less likely to break on our way to a stable release, since we will probably continue to alter the default output of several commands slightly over time. |
Beta Was this translation helpful? Give feedback.
-
|
Now that this feature is implemented, closing the related discussion 👍🏻 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I was going through some old issues and came across this one #954. That request may be a bit more specific than we want, but I think it concerns a general need for metadata which might be useful in automated or integrated environments - pipelines and IDEs, for example.
Should we consider a
func environmentcommand, capable of providing machine readable information about whatfuncis capable of in the current execution environment, whether that is the developer's laptop, running in a cluster pipeline, or from the API. We already have the languages , templates and repository subcommands which provide this information piece-meal.Wouldn’t it be nice to have something like this?
{ "environment": { "version": "1.10.3", "build": "dbcf68fc-20230411T172635Z", "spec-version": "0.35.0", "socat-image": "quay.io/boson/alpine-socat:1.7.4.3-r1-non-root", "tar-image ": "alpine-socat:1.7.4.3-r1-non-root", "languages": [ "go", "node", "nodejs", "python", "quarkus", "rust", "springboot", "typescript" ], "templates": { "go": [ "cloudevents", "http", "functastic/improve" ], "node": [ "cloudevents", "http", "dapr/configuration", "dapr/invocation", "dapr/pubsub", "dapr/secrets" ], "nodejs": [ "functastic/metacontroller" ], "python": [ "cloudevents", "flask", "http", "wsgi" ], "quarkus": [ "cloudevents", "http" ], "rust": [ "cloudevents", "http" ], "springboot": [ "cloudevents", "http", "functastic/uppercase" ], "typescript": [ "cloudevents", "http" ] }, "defaults": { "comment": "This section would probably be empty in a pipeline execution context", "language": "python", "confirm": false, "remote": true, "namespace": "default", "registry": "quay.io/lanceball", "build": { "builder": "pack", "pvc-size": "256Mi" } } } }I am leaning against having docker daemon information in this output. That just feels wrong in a way, since the daemon is not really a part of
func. But I'm not sure. It could be useful information in debugging user problems... maybe with a--verboseflag.Happy to hear any feedback on this idea.
Beta Was this translation helpful? Give feedback.
All reactions