Archivo de proyecto (.warproj / .warpcfg)

Ver también la guía: Proyecto.

.warproj — @Project

@Generator (anidada en @Project)

@Paths (anidada en @Generator)

.warpcfg — @GeneratorConfig

Las claves de nivel superior (Date Format, Print Mode, Commitment, etc.), @Screen/@FunctionKeys y los formatos de fecha/hora/timestamp son únicos a nivel de proyecto: no se repiten por perfil.

@Profile (anidada en @GeneratorConfig)

Un .warpcfg declara uno o más perfiles de despliegue (típicamente Dev, UAT, Prod, aunque el nombre es libre) dentro de @GeneratorConfig. Cada @Profile "Nombre" agrupa su propia @Connection, @Deployment y @License — así un mismo proyecto puede apuntar a servidores/bibliotecas/licencias distintos según el ambiente, sin tener que mantener varios .warpcfg.

@GeneratorConfig {
    @Profile "Dev" {
        @Connection { ... }
        @Deployment { ... }
    }
    @Profile "Prod" {
        @Connection { ... }
        @Deployment { ... }
        @License { ... }
    }
}

Es obligatorio declarar al menos un @Profile: @Connection/@Deployment/@License sueltos directamente dentro de @GeneratorConfig (sin envolverlos en @Profile) ya no son válidos (error E00290). Un @GeneratorConfig sin ningún @Profile da error E00291.

Cómo se elige el perfil activo para generate/build/reverse/license-status (la acción validate ignora los perfiles):

1. El flag --profile <Nombre> del CLI, sin distinguir mayúsculas.
2. Si se omite, Default Profile de @Project (sección .warproj — @Project más arriba).
3. Si tampoco hay Default Profile pero el .warpcfg sólo declara un @Profile, se usa ese.
4. Si nada de lo anterior aplica y hay varios perfiles declarados, el compilador falla con error E00293, listando los perfiles disponibles.

Pedir un perfil que no existe (--profile o Default Profile) falla con error E00292, también con la lista de perfiles disponibles.

@Screen (anidada en @GeneratorConfig)

@FunctionKeys (anidada en @Screen)

Una entrada F<n> : "Etiqueta" por línea (n de 1 a 24, p.ej. F3 : "Salir"). Se ata a un evento propio con Event 'Nombre' <n> ... EndEvent en el @Source de un Screen.

@Connection (anidada en @Profile)

Cómo llegar al IBM i:

ssh/sftp/ftp usan clientes nativos: no hace falta tener instalado ningún cliente ssh/scp/sftp/ftp en la máquina donde corre el compilador.

Ejemplos por protocolo y método de autenticación

SSH o SFTP con llave (ssh/sftp son equivalentes: el cliente nativo usa el mismo transporte para ambos):

@Connection {
    Host        : MIHOST
    User        : MIUSUARIO
    Auth Method : key
    Key File    : ~/.ssh/id_ed25519_ibmi
    Protocol    : ssh
    Port        : 22
    Timeout     : 30
}

SSH o SFTP con contraseña — la contraseña no se escribe en el .warpcfg; se lee de la variable de entorno WARPGATE_PASSWORD, que debe existir antes de abrir VSCode (o la terminal desde la que se corra el compilador):

@Connection {
    Host        : MIHOST
    User        : MIUSUARIO
    Auth Method : password
    Protocol    : sftp
    Port        : 22
    Timeout     : 30
}

FTP con contraseña — FTP no tiene concepto de autenticación por llave (Auth Method: key con Protocol: ftp es un error de validación), así que sólo admite password/interactive, ambos leídos de la misma variable WARPGATE_PASSWORD:

@Connection {
    Host        : MIHOST
    User        : MIUSUARIO
    Auth Method : password
    Protocol    : ftp
    Port        : 21
    Timeout     : 30
}

Generar el archivo de Key File

Para Auth Method: key hace falta un par de llaves SSH: una privada (la que apunta Key File) y una pública, que debe quedar autorizada en el perfil de usuario del IBM i.

1. Generar el par de llaves (en la máquina donde corre el compilador/VSCode, no en el IBM i):

   ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_ibmi -N ""
   

   Esto crea id_ed25519_ibmi (privada — la ruta que va en Key File) y id_ed25519_ibmi.pub (pública). -N "" deja la llave sin passphrase, requisito para Auth Method: key.
2. Copiar el contenido de id_ed25519_ibmi.pub (una sola línea) al final del archivo .ssh/authorized_keys dentro del directorio home IFS del usuario del IBM i (p.ej. /home/MIUSUARIO/.ssh/authorized_keys) — crear el archivo y el directorio si no existen. El demonio SSH del IBM i (SSHD, del producto 5733-SC1) tiene que estar activo y configurado para aceptar autenticación por llave.
3. Verificar que Key File en @Connection apunte a la ruta de la llave privada en la máquina local (no la .pub), y que Auth Method sea key.

@Deployment (anidada en @Profile)

Dónde/cómo desplegar y compilar en el IBM i:

@License (anidada en @Profile)

Bloque opcional con la configuración de licenciamiento, propio de cada perfil — así Dev/UAT/Prod pueden consumir licencias o servicios de licenciamiento distintos. Las claves no distinguen mayúsculas. Ver la guía Licenciamiento.

@License {
    Host        : "servidor01.dominio.local"
    Port        : 7443
    Fingerprint : "3f2a9c41d87b05e6a1c4f0937be2d5688a1f4c0d29e7b3a65c8d1f0e4b7a9c23"
}

Ejemplo completo

Ver Proyecto: .warproj y .warpcfg para un ejemplo completo con ambos archivos.