Hey. I would suggest to stick with Kubernetes specification because some people may want to do the following

kubectl get -oyaml job curl > job.yaml
run-job -f job.yaml

To do so seamlessly, it requires to be fully compatible with K8S spec.

Hi @Jasstkn

This specifically will not work as expected, because the YAML format is different and much simpler:

kubectl get -oyaml job curl > job.yaml
run-job -f job.yaml

But they could do kubectl get -o yaml then copy/paste in the "env" section.

Would you like to add support for environment variables using the env format from the above?

Hi @Jasstkn

This specifically will not work as expected, because the YAML format is different and much simpler:

kubectl get -oyaml job curl > job.yaml
run-job -f job.yaml

But they could do kubectl get -o yaml then copy/paste in the "env" section.

Would you like to add support for environment variables using the env format from the above?

Ah, yes, you're right! Yep, I would like to implement this feature as well.

Would be great to have support for this & envFrom. One of my use cases for run-job would be to run Flyway for SQL database migrations, and it would be nice to use envFrom to read from an existing secret.

@clrxbl what data do you need for your envFrom use-cases?

If it's for secrets, we would also need to add secret support.

In OpenFaaS we do this by convention. Specify a list of secret names with secrets: and then the data is mounted in a projected volume under /var/openfaas/secrets/NAME/

That makes them quite convenient to read in bash / code.

@clrxbl what data do you need for your envFrom use-cases?

I simply use envFrom to read from a single Secret containing environment variables for e.g. database authentication.

Secret support seems reasonable for connecting to databases/APIs etc.

faas-cli list/describe etc instance also require faas-cli login first.

@clrxbl hello. We are in the discussion of what is the best way to implement this feature. Could you tell me what you feel is more convenient for you: the same approach as in the Kubernetes Job manifest or a more compact way with just a bare minimum and all parsing done under the hood?

FYI @alexellis

@clrxbl hello. We are in the discussion of what is the best way to implement this feature. Could you tell me what you feel is more convenient for you: the same approach as in the Kubernetes Job manifest or a more compact way with just a bare minimum and all parsing done under the hood?

FYI @alexellis

It would be great to have it use the same approach as in the Kubernetes Job manifest as it allows you to refer to environment variables located in secrets.

@clrxbl hello. We are in the discussion of what is the best way to implement this feature. Could you tell me what you feel is more convenient for you: the same approach as in the Kubernetes Job manifest or a more compact way with just a bare minimum and all parsing done under the hood?
FYI @alexellis

It would be great to have it use the same approach as in the Kubernetes Job manifest as it allows you to refer to environment variables located in secrets.

You can take a look how I implemented it in the PR: #7 and also our discussion with @alexellis about possible improvements there: #7 (comment). I'm not sure which one is better.

@clrxbl hello. We are in the discussion of what is the best way to implement this feature. Could you tell me what you feel is more convenient for you: the same approach as in the Kubernetes Job manifest or a more compact way with just a bare minimum and all parsing done under the hood?
FYI @alexellis

It would be great to have it use the same approach as in the Kubernetes Job manifest as it allows you to refer to environment variables located in secrets.

You can take a look how I implemented it in the PR: #7 and also our discussion with @alexellis about possible improvements there: #7 (comment). I'm not sure which one is better.

Looking at #7
IMO, it would be better to stick to how Kubernetes' formatting does it currently with env & envFrom.

Could you give an example of how you think the YAML would look?

Could you give an example of how you think the YAML would look?

name: checker
image: ghcr.io/openfaas/config-checker:latest
namespace: openfaas
sa: openfaas-checker
env:
  - name: "KEY"
    value: "value"
envFrom:
  - secretRef:
      name: "secret-name"

@alexellis hey. what do you think about the example above?