Configuration Guide

Learn GINX configurations, make complex commands memorable

Ginx uses ginx.yaml (or ginx.yml, .ginx.yaml, .ginx.yml) in your project root:

scripts:
  # Your script definitions

plugins:
  # Plugin configuration

settings:
  # Global settings

Scripts Section

This section gives you flexibility to define scripts, mapping verbose scripts to your own script names using ginx, lets see an example

scripts:

  # Ginx uses object format - with metadata
  test:
    command: "pytest tests/ -v"
    description: "Run test suite"

Defining scripts with Environment Variables:

# Inside your scripts
scripts:

  # Ginx will register "deploy command", during runtime, ginx will load env to the command
  deploy:
    command: "deploy.sh $ENV $VERSION"
    description: "Deploy to environment"
    
    # Define env here:
    env:
      ENV: "staging"
      VERSION: "1.0.0"

Selecting a Working Directory:

Ginx allows you to select a working directory (a directory to run the command)

# Inside your scripts
scripts:

  # Ginx will register "frontend command", this command will run in ./frontend directory
  frontend:
    command: "npm run build"
    description: "Build frontend"
    
    # specify working directory
    cwd: "./frontend"

Using Ginx with Complex Commands

Since most of complex commands are not memorable, you can use Ginx to map it to a simple memorable command with no time, check example bellow:

scripts:
  # Shell operators work
  full-test: "pytest tests/ && flake8 src/ && mypy src/"
  description: "..."
  
  # Multi-step with dependencies
  release: "ginx test && ginx build && ginx publish"
  description: "..."
  
  # This is more clean, now in your command line you can use:
  # ginx full-test or ginx run full-test
  # ginx release or ginx run release

Settings Section

This section currently have ONE working setting, allows you add rules for executing commands in your project

settings:

  # Safety features
  dangerous_commands: false # If set to true Ginx will execute dangerous commands direct

See Ginx Dangerous Commands

Ginx Configuration Discovery

Ginx searches for config files in this order:

• ginx.yaml

• ginx.yml

• .ginx.yaml

• .ginx.yml

Searches current directory

Ginx Validation

Are you unsure with the configurations syntax, ginx is here for the rescue, Check your configuration:

ginx validate          # Check for errors

Best Practices

Do	Don't
Use descriptive script names (test-coverage not tc)	Use script names that conflict with built-in commands (list, version)
Add descriptions to complex scripts	Put sensitive data in the config file (use environment variables)
Group related scripts with prefixes (db-migrate, db-backup)	Make scripts too complex (break into multiple scripts)
Use environment variables for configurable values

That's it! Your ginx.yaml defines your entire project workflow.