Add SSH authentication support to arcane-deploy action

[nsheaps]

Summary

This PR adds SSH authentication support to the arcane-deploy GitHub Action, allowing users to authenticate with Git repositories using SSH keys (such as GitHub deploy keys) instead of only HTTP tokens.

Key Changes

• New input parameters:

  • ssh-private-key: SSH private key for git authentication (required when auth-type=ssh)
  • ssh-host-key-verification: SSH host key verification mode with options accept_new (default), accept_all, or reject

• Updated authentication flow:

  • Extended ensure_repository() function to handle SSH credentials for both creating new repositories and updating existing ones
  • Added validation to require ssh-private-key when auth-type is set to ssh
  • Updated supported auth-type values from none, http to none, http, ssh

• Security improvements:

  • SSH private key is immediately masked in logs using ::add-mask:: to prevent accidental exposure

• Documentation updates:

  • Added SSH deploy key example to README
  • Updated input parameter documentation to reflect new SSH options
  • Updated action.yml with new input definitions and environment variable mappings

Implementation Details

• SSH credentials are passed to the Arcane API with the same update/create payload pattern as HTTP tokens
• The username is hardcoded to "git" for SSH authentication, which is standard for most Git hosting providers
• SSH host key verification is configurable to support different security requirements and deployment scenarios

https://claude.ai/code/session_019FKVbkxfTf8fyqdx7BzCFs

[nsheaps]

Review: Add SSH authentication support to arcane-deploy action

Overall: Looks solid for a first pass. The approach is correct — SSH creds are passed through the same Arcane API pattern as HTTP tokens.

Good

• SSH key is masked with ::add-mask:: — correct security practice
• Validation that ssh-private-key is required when auth-type=ssh mirrors the HTTP token validation
• ssh-host-key-verification defaults to accept_new which is sensible (like StrictHostKeyChecking=accept-new)
• Username hardcoded to "git" is correct for SSH git operations

Things to check / potential issues

1. Does the Arcane API field name match? The PR is passing SSH credentials through the API — were the exact field names Arcane expects verified? The backend service encrypts ssh_key and has ssh_host_key_verification, but the API might use different field names than the internal model. Worth confirming against the Arcane API schema or testing it.

2. Credential update on existing repos — The diff updates SSH creds on every deploy ("so they stay current"). For HTTP tokens that makes sense (they rotate/expire). For SSH deploy keys that don't expire, it's unnecessary but harmless — just extra API calls. Fine to leave.

3. accept_all for host key verification — This is effectively StrictHostKeyChecking=no. Might want a comment in the README noting this is insecure and should only be used for testing.

4. No repository-url changes? — The README example shows repository-url as an input for SSH, but SSH URLs use git@github.com:owner/repo.git format vs HTTPS. Does the action handle URL format differences, or does Arcane handle that internally based on auth type?

5. Multiline secret handling — SSH private keys are multiline. Does the ::add-mask:: and env var passing handle newlines correctly in GitHub Actions? This is a common gotcha. Worth testing with an actual deploy key.

Verdict

The bones are right. Recommend a quick integration test with an actual deploy key before merging — especially to validate points 1, 4, and 5.