Tim Jacomb

Why do you want to do this? I don't think we want this in this plugin, and it's not a bug.

You have full control of how you start the agent. Just change your systemd service ExecStart to: ``` ExecStart=/usr/bin/java -cp /home/jenkins/inbound-agent/agent.jar hudson.remoting.jnlp.Main -headless -direct ${TUNNEL_ADDRESS} -workDir /home/jenkins/work -instanceIdentity ${INSTANCE_IDENTITY} @/home/${USER}/inbound-agent/agent-secret...

I'm not sure what the UI for permanent agents does in this case. For a tunnel to make sense I would have thought you need to use the tunnel to...

That sounds like a misconfigured service, if users are expected to access it on 1443 Jenkins should be configured for that. Port forwarding to access Jenkins is a very unusual...

> However, being able to configure this using the UI would improve the UX for users: same experience as a "permanent inbound agent" This was removed in Jenkins core in...

The configuration as code plugin is the recommended method to configure this plugin through code.. I would accept a pull request to expose it in groovy but no plans to...

Given no further interest closing this, please use the recommended approach the jenkins configuration as code plugin

> Same as [#422 (comment)](https://github.com/jenkinsci/azure-vm-agents-plugin/issues/422#issuecomment-1545158636): it would we a nice UX if the end user could set up the agent through the UI and have it preconfigured (I guess passing...

A minimal init script assuming Java is pre-installed to the VM would be (a trimmed down version of the example as the example installs Java, git and maven): ```bash #!/usr/bin/env...

Btw you can use SSH keys now to authenticate if you want to switch to that at the same time Wouldn’t be used by the controller but if you ever...