Support Coder deployments that need no cloud credentials

[Satyam-Captain]

What does this PR do?

build_coder raises ArgumentError unless auth.cloud is "openstack", so the Coder adapter cannot be used with Docker, Kubernetes, or any other Terraform target that needs no cloud authentication.

This adds a NoCredentials implementation of CredentialsInterface and accepts auth.cloud of "none" — or no auth block at all. A cluster config with no auth block previously raised NoMethodError, because config[:auth]["cloud"] was called on nil.

Unrecognised cloud types still raise, and the message now includes the offending value.

This follows on from #956 — @andrejcermak asked there what use case I was implementing, and this is it: running Coder workspaces as Docker containers rather than OpenStack VMs.

Why the credential parameters are still sent as empty strings

get_rich_parameters always sends the four application-credential parameters. It would be tidier to omit them when there are no credentials, but I tested this against Coder v2.36.0 and it isn't safe:

• omitting a declared parameter → 400 Unable to validate parameters, "Required parameter not provided; parameter value is null"
• supplying it with an empty string → workspace created successfully

So templates that declare these parameters need them present, and NoCredentials returns empty values rather than nothing.

Related issue

N/A

Testing

• Tests included

Adds three minitest cases to test/job/adapters/coder_test.rb: cloud: "none" builds the adapter, a config with no auth block builds the adapter, and an unrecognised cloud still raises with the value in the message.

Also tested on a live OnDemand 4.2.3 deployment against Coder v2.36.0 with a Docker-based template: workspaces are created and reachable both with auth.cloud: "none" and with the auth block omitted entirely.

Full suite passes locally — rake spec: 1102 examples, 0 failures; rake test: 20 runs, 0 failures.

Checklist

• Follows project code style and conventions
• Documentation provided (if new feature, adapter or behavior change)
• This is a large feature and was discussed in an issue first (if applicable)

Anything else?

The OpenStack path is unchanged — auth.cloud: "openstack" takes the same branch and constructs the same OpenStackCredentials object as before.

I'd be happy to document the auth.cloud options and the coder_output metadata keys (floating_ip, port) in ood-documentation if that would be useful — they don't appear to be documented anywhere currently.

[johrstrom]

@andrejcermak please advise.

I will say when reviewing this just a bit ago, that the classes CredentialsInterface and the subclasses likely should be under the OodCore::Job::Adapters::Coder namespace. You never know if someone else somewhere else already has that class name.

Secondly, I'm sure there is another way to do this that is more dynamic. I.e., instead of having a case statement for all possible options, you'd just try to load the class in question based the string configuration provided.

# just a small demonstration of loading a class from a string and instantiating that object.
klass = Object.const_get('OodCore::Job::Info')
info = klass.new(**{id: 'abc123', status: 'running'})

Of course we can keep things here, but you never know what will be needed in the wild and someone may need to implement something different.

[andrejcermak]

@johrstrom I am open to your suggestions on how to approach this in a better way as I am not really Ruby developer and you have way more experience in this field. What approach would you suggest?

I think this PR can be merged and you can create an issue on this improvement and assign it to me. I will have a look at it soon.

[andrejcermak]

@Satyam-Captain it would be great if you also created a PR in the documentation repo on this new approach and also the stuff you think is missing. I will have a look at it as well.

[Satyam-Captain]

Thanks both. I'll open a documentation PR covering the auth.cloud options and the coder_output metadata keys (floating_ip, port), plus the requirement that the address be reachable from the OnDemand host , that one caught me out when I was setting this up.

Happy to leave the dynamic credential loading to @andrejcermak as suggested.

[johrstrom]

OK - if we want to refactor to dynamic loading I think this class should be NoneCredentials that way a configuration of none will resolve to the class NoneCredentials. A bit odd for the class name, but I think a configuration value of credentials: 'none' is better UX for the admin than credentials: 'no'.