⚙️ Executable Objects

First up: Executable Objects. Think of these as reusable references to executables on your system. Instead of hardcoding paths to interpreters or binaries across multiple services, you create an executable object once and reference it wherever you need it.

This is particularly useful when you have:

• Multiple Python versions installed and need consistency across services.
• Custom-built executables that aren’t in your system PATH.
• Specific tool versions that need to be pinned across your automation.

Creating an executable object is dead simple:

>_ torero create executable-object bash --exec-command /bin/bash

Or for a specific Python version:

>_ torero create executable-object py312 --exec-command 
/usr/bin/python3.12 --description "Python 3.12 interpreter"

Once created, you can reference these objects when creating any service type – Python scripts, Ansible playbooks, OpenTofu plans, or the new executable services.

???? Executable Services

Here’s where things get interesting. Executable Services let you run any executable file through torero’s service management system. Shell scripts, compiled binaries, custom tools – if it can run on your system, torero can manage it.

The workflow is straightforward: create an executable object pointing to your interpreter or binary, then create a service that uses it.

>_ torero create executable-object bash --exec-command /bin/bash

>_ torero create service executable backup-script \
  --executable-object bash \
  --repository scripts-repo \
  --filename backup.sh

One of the powerful features here is argument formatting. You can customize exactly how arguments are passed to your executable:

>_ torero create service executable env-setup \
  --executable-object bash \
  --repository scripts-repo \
  --filename setup.sh \
  --arg-format "{{.Key}} {{.Value}}"

Now when you run the service with –set NAME=myapp –set PORT=8080, torero passes them exactly as your script expects. No more wrestling with argument formats.

And yes, secrets work here too. You can inject sensitive values as environment variables, keeping credentials out of your scripts and command history:

>_ torero run service executable api-caller \
  --set endpoint=https://api.example.com/data \
  --set-secret name=api-token,type=env,target=API_TOKEN

???? Repository HTTP Basic Auth

Private repositories just got easier to work with. torero 1.6 adds support for HTTP Basic Authentication, so you can pull from private repos using HTTPS URLs without needing SSH key infrastructure.

Store your token securely:

>_ torero create secret github-token --value <your-github-token>

Then associate it with your repository:

>_ torero create repository my-private-repo \
  --url https://github.com/example/private-automations.git \
  --username <your-username> \
  --password-name github-token

This complements the existing SSH key support, giving you flexibility in how you authenticate with your Git providers. Use SSH when you have key infrastructure in place; use HTTP Basic Auth when tokens are more practical.