Adición de una extensión de tarea de canalizaciones personalizadas

Azure DevOps Services | Azure DevOps Server 2022: Azure DevOps Server 2019

En este artículo se explica cómo instalar extensiones en su organización para tareas de compilación o versión personalizadas en Azure DevOps. Para más información, consulte ¿Qué es Azure Pipelines?

Requisitos previos

• Una organización en Azure DevOps. Cree una organización.

• Un editor de texto. Para muchos tutoriales, se usa Visual Studio Code, que proporciona compatibilidad con Intellisense y depuración.

• La versión más reciente de Node.js.

• npmjs.com 4.0.2 o posterior. Instale la versión más reciente de este compilador de TypeScript.

• CLI multiplataforma para Azure DevOps (tfx-cli) para empaquetar las extensiones.

  • tfx-cli se puede instalar mediante npm, un componente de Node.js, al ejecutar npm i -g tfx-cli.

• SDK de extensión de Azure DevOps. Instale el paquete azure-devops-extension-sdk .

• Un home directorio para el proyecto. El home directorio de una extensión de tarea de compilación o versión debe tener la siguiente estructura después de completar los pasos descritos en este artículo:

  |--- README.md    
  |--- images                        
      |--- extension-icon.png  
  |--- buildandreleasetask            // where your task scripts are placed
  |--- vss-extension.json             // extension's manifest
  

"execution": {
   "Node20_1": {
     "target": "index.js"
   }
 }

1. Crear una tarea personalizada

Realice todas las partes de este procedimiento dentro de la carpeta buildandreleasetask dentro del directorio home.

Creación de scaffolding de tareas

1. Cree la estructura de carpetas para la tarea e instale las bibliotecas y dependencias necesarias.

2. Abra una ventana de comandos de PowerShell, vaya a la buildandreleasetask carpeta y ejecute el siguiente comando.

   npm init --yes
   

   npm init crea el package.json archivo . Se ha agregado el --yes parámetro para aceptar todas las opciones predeterminadas npm init .

   Sugerencia

   El agente no instala automáticamente los módulos necesarios porque espera que la carpeta de tareas incluya los módulos de nodo. Para mitigar, copie de node_modules a buildandreleasetask. A medida que la tarea aumenta, es fácil superar el límite de tamaño (50 MB) de un archivo VSIX. Antes de copiar la carpeta del nodo, es posible que quiera ejecutar npm install --production o npm prune --production, o bien puede escribir un script para compilar y empaquetar todo.

3. Agregue azure-pipelines-task-lib a la biblioteca.

   npm install azure-pipelines-task-lib --save
   

4. Asegúrese de que los términos de TypeScript están instalados para las dependencias externas.

   npm install @types/node --save-dev
   npm install @types/q --save-dev
   

5. Cree un .gitignore archivo y agregue node_modules a él. El proceso de compilación debe realizar un npm install y un typings install para que se compilen node_modules cada vez y no sea necesario que se protejan.

   echo node_modules > .gitignore
   

6. Instale Mocha como dependencia de desarrollo.

   npm install mocha --save-dev -g
   npm install sync-request --save-dev
   npm install @types/mocha --save-dev
   

7. Elija TypeScript versión 2.3.4 o 4.6.3.

   npm install typescript@4.6.3 -g --save-dev
   

   Nota:

   Asegúrese de que TypeScript está instalado globalmente con npm en el entorno de desarrollo, por lo que el tsc comando está disponible. Si omite este paso, TypeScript versión 2.3.4 se usa de forma predeterminada y todavía tiene que instalar el paquete globalmente para que el tsc comando esté disponible.

8. Cree tsconfig.json opciones del compilador. Este archivo garantiza que los archivos TypeScript se compilen en archivos JavaScript.

   tsc --init --target es2022
   

Crear la tarea

Ahora que se ha completado el andamiaje, puede crear su tarea personalizada.

1. Cree un task.json archivo en la buildandreleasetask carpeta . El task.json archivo describe la tarea de compilación o versión y es lo que usa el sistema de compilación o versión para representar las opciones de configuración al usuario y saber qué scripts se van a ejecutar en tiempo de compilación o lanzamiento.

2. Copie el código siguiente y reemplace por la {{placeholders}} información de la tarea. El marcador de posición más importante es taskguidy debe ser único.

   {
    "$schema": "https://raw.githubusercontent.com/Microsoft/azure-pipelines-task-lib/master/tasks.schema.json",
    "id": "{{taskguid}}",
    "name": "{{taskname}}",
    "friendlyName": "{{taskfriendlyname}}",
    "description": "{{taskdescription}}",
    "helpMarkDown": "",
    "category": "Utility",
    "author": "{{taskauthor}}",
    "version": {
        "Major": 0,
        "Minor": 1,
        "Patch": 0
    },
    "instanceNameFormat": "Echo $(samplestring)",
    "inputs": [
        {
            "name": "samplestring",
            "type": "string",
            "label": "Sample String",
            "defaultValue": "",
            "required": true,
            "helpMarkDown": "A sample string"
        }
    ],
    "execution": {
        "Node20_1": {
            "target": "index.js"
        }
    }
    }
   

3. Cree un index.ts archivo con el código siguiente como referencia. Este código se ejecuta cuando se llama a la tarea.

   import tl = require('azure-pipelines-task-lib/task');
   
    async function run() {
        try {
            const inputString: string | undefined = tl.getInput('samplestring', true);
            if (inputString == 'bad') {
                tl.setResult(tl.TaskResult.Failed, 'Bad input was given');
                return;
            }
            console.log('Hello', inputString);
        }
        catch (err:any) {
            tl.setResult(tl.TaskResult.Failed, err.message);
        }
    }
   
    run();
   

4. Para compilar un archivo index.js desde index.ts, ejecute tsc desde la carpeta buildandreleasetask.

componentes de task.json

Consulte las descripciones siguientes de algunos de los componentes del task.json archivo.

(New-Guid).Guid

Ejecución de la tarea

Ejecute la tarea mediante node index.js desde PowerShell.

En el ejemplo siguiente, se produce un error en la tarea porque no se proporcionaron entradas (samplestring es una entrada necesaria).

 node index.js
 ##vso[task.debug]agent.workFolder=undefined
 ##vso[task.debug]loading inputs and endpoints
 ##vso[task.debug]loaded 0
 ##vso[task.debug]task result: Failed
 ##vso[task.issue type=error;]Input required: samplestring
 ##vso[task.complete result=Failed;]Input required: samplestring

Como corrección, establezca la samplestring entrada y vuelva a ejecutar la tarea.

$env:INPUT_SAMPLESTRING="Human"
node index.js
##vso[task.debug]agent.workFolder=undefined
##vso[task.debug]loading inputs and endpoints
##vso[task.debug]loading INPUT_SAMPLESTRING
##vso[task.debug]loaded 1
##vso[task.debug]Agent.ProxyUrl=undefined
##vso[task.debug]Agent.CAInfo=undefined
##vso[task.debug]Agent.ClientCert=undefined
##vso[task.debug]Agent.SkipCertValidation=undefined
##vso[task.debug]samplestring=Human
Hello Human

Esta vez, la tarea se realiza correctamente porque samplestring se proporcionó y genera correctamente Hello Human.

2. Prueba unitaria de los scripts de tareas

Realice pruebas unitarias para probar rápidamente el script de tareas y no las herramientas externas a las que llama. Pruebe todos los aspectos de las rutas de acceso de éxito y error.

1. Instale las herramientas de prueba. Usamos Mocha como controlador de prueba en este procedimiento.

   npm install mocha --save-dev -g
   npm install sync-request --save-dev
   npm install @types/mocha --save-dev
   

2. Cree una tests carpeta que contenga un _suite.ts archivo con el siguiente contenido:

   import * as path from 'path';
   import * as assert from 'assert';
   import * as ttm from 'azure-pipelines-task-lib/mock-test';
   
   describe('Sample task tests', function () {
   
       before( function() {
   
       });
   
       after(() => {
   
       });
   
       it('should succeed with simple inputs', function(done: Mocha.Done) {
           // Add success test here
       });
   
       it('it should fail if tool returns 1', function(done: Mocha.Done) {
           // Add failure test here
       });    
   });
   

   Sugerencia

   La carpeta de prueba debe encontrarse en la buildandreleasetask carpeta . Si recibe un error de solicitud de sincronización, puede solucionarlo agregando sync-request a la buildandreleasetask carpeta con el comando npm i --save-dev sync-request.

3. Cree un success.ts archivo en el directorio de prueba con el siguiente contenido. Esta creación de archivos simula la ejecución de la tarea y simula todas las llamadas a métodos externos.

   import ma = require('azure-pipelines-task-lib/mock-answer');
   import tmrm = require('azure-pipelines-task-lib/mock-run');
   import path = require('path');
   
   let taskPath = path.join(__dirname, '..', 'index.js');
   let tmr: tmrm.TaskMockRunner = new tmrm.TaskMockRunner(taskPath);
   
   tmr.setInput('samplestring', 'human');
   
   tmr.run();
   

   La prueba de éxito valida que, con las entradas adecuadas, tiene éxito sin errores ni advertencias y devuelve la salida correcta.

4. Para ejecutar el ejecutor ficticio de la tarea, agregue el siguiente ejemplo de prueba de éxito al archivo _suite.ts.

        it('should succeed with simple inputs', function(done: Mocha.Done) {
        this.timeout(1000);
   
        let tp: string = path.join(__dirname, 'success.js');
        let tr: ttm.MockTestRunner = new ttm.MockTestRunner(tp);
   
        // tr.run(); //current, old function.
        tr.runAsync().then(() => {
            console.log(tr.succeeded);
            assert.equal(tr.succeeded, true, 'should have succeeded');
            assert.equal(tr.warningIssues.length, 0, "should have no warnings");
            assert.equal(tr.errorIssues.length, 0, "should have no errors");
            console.log(tr.stdout);
            assert.equal(tr.stdout.indexOf('Hello human') >= 0, true, "should display Hello human");
            done();
        }).catch((error) => {
            done(error); // Ensure the test case fails if there's an error
        });
    });
   

5. Cree un failure.ts archivo en el directorio de prueba como ejecutor ficticio de tareas con el siguiente contenido:

   import ma = require('azure-pipelines-task-lib/mock-answer');
   import tmrm = require('azure-pipelines-task-lib/mock-run');
   import path = require('path');
   
   let taskPath = path.join(__dirname, '..', 'index.js');
   let tmr: tmrm.TaskMockRunner = new tmrm.TaskMockRunner(taskPath);
   
   tmr.setInput('samplestring', 'bad');
   
   tmr.run();
   

   La prueba de fallo valida que, cuando la herramienta recibe una entrada incorrecta o incompleta, falle de la manera esperada con una salida útil.

6. Para ejecutar el ejecutor ficticio de la tarea, agregue el código siguiente al _suite.ts archivo.

   it('should fail if tool returns 1', function(done: Mocha.Done) {
       this.timeout(1000);
   
       const tp = path.join(__dirname, 'failure.js');
       const tr: ttm.MockTestRunner = new ttm.MockTestRunner(tp);
   
       tr.runAsync().then(() => {
           console.log(tr.succeeded);
           assert.equal(tr.succeeded, false, 'should have failed');
           assert.equal(tr.warningIssues.length, 0, 'should have no warnings');
           assert.equal(tr.errorIssues.length, 1, 'should have 1 error issue');
           assert.equal(tr.errorIssues[0], 'Bad input was given', 'error issue output');
           assert.equal(tr.stdout.indexOf('Hello bad'), -1, 'Should not display Hello bad');
           done();
       });
   });
   

7. Ejecute las pruebas.

   tsc
   mocha tests/_suite.js
   

   Ambas pruebas deben superarse. Si desea ejecutar las pruebas con una salida más detallada (lo que vería en la consola de compilación), establezca la variable de entorno: TASK_TEST_TRACE=1.

   $env:TASK_TEST_TRACE=1
   

3. Crear el archivo de manifiesto de extensión

El manifiesto de extensión contiene toda la información sobre la extensión. Incluye vínculos a los archivos, incluidas las carpetas de tareas y las carpetas de imágenes. Asegúrese de que ha creado una carpeta images con extension-icon.png. El ejemplo siguiente es un manifiesto de extensión que contiene la tarea de compilación o versión.

Copie el siguiente código .json y guárdelo como vss-extension.json archivo en el home directorio.

No cree este archivo en la carpeta buildandreleasetask.

{
    "manifestVersion": 1,
    "id": "build-release-task",
    "name": "Fabrikam Build and Release Tools",
    "version": "0.0.1",
    "publisher": "fabrikam",
    "targets": [
        {
            "id": "Microsoft.VisualStudio.Services"
        }
    ],    
    "description": "Tools for building/releasing with Fabrikam. Includes one build/release task.",
    "categories": [
        "Azure Pipelines"
    ],
    "icons": {
        "default": "images/extension-icon.png"        
    },
    "files": [
        {
            "path": "buildandreleasetask"
        }
    ],
    "contributions": [
        {
            "id": "custom-build-release-task",
            "type": "ms.vss-distributed-task.task",
            "targets": [
                "ms.vss-distributed-task.tasks"
            ],
            "properties": {
                "name": "buildandreleasetask"
            }
        }
    ]
}

Contribuciones

Archivos

Para obtener más información sobre el archivo de manifiesto de extensión, como sus propiedades y las funciones que realizan, consulte la referencia del manifiesto de extensión.

4. Empaquetar la extensión

Empaquete todos los archivos juntos para obtener la extensión en Visual Studio Marketplace. Todas las extensiones se empaquetan como archivos .vsix compatibles con VSIX 2.0. Microsoft proporciona una interfaz de línea de comandos (CLI) multiplataforma para empaquetar la extensión.

Una vez que tenga tfx-cli, vaya al directorio principal de la extensión y ejecute el siguiente comando:

tfx extension create --manifest-globs vss-extension.json

Una vez que la extensión empaquetada esté en un archivo .vsix, estará listo para publicar la extensión en Marketplace.

5. Publicar la extensión

Para publicar la extensión, cree primero el publicador, cargue la extensión y, por último, compártala.

Creación del publicador

Todas las extensiones, incluidas las extensiones de Microsoft, se identifican como proporcionadas por un publicador. Si aún no es miembro de un publicador existente, cree uno.

1. Inicie sesión en el Portal de publicación de Visual Studio Marketplace.

2. Si aún no es miembro de un publicador existente, se le pedirá que cree un publicador. Si no se le pide que cree un publicador, desplácese hacia abajo hasta la parte inferior de la página y seleccione Publicar extensiones en Sitios relacionados.

   • Especifique un identificador para el publicador, por ejemplo: mycompany-myteam.
     • Este identificador se usa como valor para el atributo en el publisher archivo de manifiesto de las extensiones.
   • Especifique un nombre para mostrar para el publicador, por ejemplo: My Team.

3. Revise el Contrato de publicador de Marketplace y seleccione Crear.

Se define el publicador. En una versión futura, puede conceder permisos para ver y administrar las extensiones del publicador. Es más fácil y seguro publicar extensiones en un publicador común, sin necesidad de compartir un conjunto de credenciales entre los usuarios.

Carga de la extensión

Busque el botón Cargar nueva extensión , vaya al archivo .vsix empaquetado y seleccione Cargar.

También puede cargar su extensión a través de la interfaz de línea de comandos (CLI) utilizando el comando tfx extension publish en lugar de tfx extension create para empaquetar y publicar su extensión en un solo paso. Opcionalmente, puede usar --share-with para compartir la extensión con una o varias cuentas después de publicarla.

tfx extension publish --manifest-globs your-manifest.json --share-with yourOrganization

Compartir la extensión

Ahora que cargó la extensión, está en Marketplace, pero nadie puede verlo. Compártelo con su organización para poder instalarlo y probarlo.

Seleccione la extensión con el botón derecho y seleccione Compartir y escriba la información de la organización. También puede compartirlo con otras cuentas a las que quiera tener acceso a la extensión.

Después de compartir la extensión en Marketplace, cualquier persona que quiera usarla debe instalarla.

6. Creación de una canalización de compilación y versión para publicar la extensión en Marketplace

Para mantener la tarea personalizada en Marketplace, cree una canalización de compilación y versión en Azure DevOps.

Requisitos previos para publicar

• Un proyecto de Azure DevOps. Cree un proyecto.

• Extensión de Tareas de extensión de Azure DevOps. Instálelo de forma gratuita en su organización.

• Grupo de variables de biblioteca de canalizaciones. Cree un grupo de variables de biblioteca de canalización para contener las variables usadas por la canalización. Para obtener más información, vea Agregar y usar grupos de variables. Puede crear grupos de variables desde la pestaña Biblioteca de Azure DevOps o a través de la CLI. Use las variables de este grupo en la canalización. Además, declare las siguientes variables en el grupo de variables:

  • publisherId: identificador del publicador de Marketplace
  • extensionId: Id. de la extensión, como se declara en el archivo vss-extension.json.
  • extensionName: nombre de la extensión, tal como se declara en el archivo vss-extension.json
  • artifactName: nombre del artefacto que se va a crear para el archivo VSIX.

• Conexión de servicio. Cree una nueva conexión de servicio de Marketplace y conceda permisos de acceso para todas las canalizaciones.

• Canalización YAML. Use el ejemplo siguiente para crear una nueva canalización con YAML. Para más información, consulte Creación de la primera canalización y el esquema YAML.

      trigger: 
      - main
      pool:
        vmImage: "ubuntu-latest"
      variables:
        - group: variable-group # Rename to whatever you named your variable group in the prerequisite stage of step 6
      stages:
        - stage: Run_and_publish_unit_tests
          jobs:
            - job:
              steps:
                - task: TfxInstaller@4
                  inputs:
                    version: "v0.x"
                - task: Npm@1
                  inputs:
                    command: 'install'
                    workingDir: '/TaskDirectory' # Update to the name of the directory of your task
                - task: Bash@3
                  displayName: Compile Javascript
                  inputs:
                    targetType: "inline"
                    script: |
                      cd TaskDirectory # Update to the name of the directory of your task
                      tsc
                - task: Npm@1
                  inputs:
                    command: 'custom'
                    workingDir: '/TestsDirectory' # Update to the name of the directory of your task's tests
                    customCommand: 'testScript' # See the definition in the explanation section below - it may be called test
                - task: PublishTestResults@2
                  inputs:
                    testResultsFormat: 'JUnit'
                    testResultsFiles: '**/ResultsFile.xml'
        - stage: Package_extension_and_publish_build_artifacts
          jobs:
            - job:
              steps:
                - task: TfxInstaller@4
                  inputs:
                    version: "0.x"
                - task: Npm@1
                  inputs:
                    command: 'install'
                    workingDir: '/TaskDirectory' # Update to the name of the directory of your task
                - task: Bash@3
                  displayName: Compile Javascript
                  inputs:
                    targetType: "inline"
                    script: |
                      cd TaskDirectory # Update to the name of the directory of your task
                      tsc
                - task: QueryAzureDevOpsExtensionVersion@4
                  name: QueryVersion
                  inputs:
                    connectTo: 'VsTeam'
                    connectedServiceName: 'ServiceConnection' # Change to whatever you named the service connection
                    publisherId: '$(PublisherID)'
                    extensionId: '$(ExtensionID)'
                    versionAction: 'Patch'
                - task: PackageAzureDevOpsExtension@4
                  inputs:
                    rootFolder: '$(System.DefaultWorkingDirectory)'
                    publisherId: '$(PublisherID)'
                    extensionId: '$(ExtensionID)'
                    extensionName: '$(ExtensionName)'
                    extensionVersion: '$(QueryVersion.Extension.Version)'
                    updateTasksVersion: true
                    updateTasksVersionType: 'patch'
                    extensionVisibility: 'private' # Change to public if you're publishing to the marketplace
                    extensionPricing: 'free'
                - task: CopyFiles@2
                  displayName: "Copy Files to: $(Build.ArtifactStagingDirectory)"
                  inputs:
                    Contents: "**/*.vsix"
                    TargetFolder: "$(Build.ArtifactStagingDirectory)"
                - task: PublishBuildArtifacts@1
                  inputs:
                    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
                    ArtifactName: '$(ArtifactName)'
                    publishLocation: 'Container'
        - stage: Download_build_artifacts_and_publish_the_extension
          jobs:
            - job:
              steps:
                - task: TfxInstaller@4
                  inputs:
                    version: "v0.x"
                - task: DownloadBuildArtifacts@0
                  inputs:
                    buildType: "current"
                    downloadType: "single"
                    artifactName: "$(ArtifactName)"
                    downloadPath: "$(System.DefaultWorkingDirectory)"
                - task: PublishAzureDevOpsExtension@4
                  inputs:
                    connectTo: 'VsTeam'
                    connectedServiceName: 'ServiceConnection' # Change to whatever you named the service connection
                    fileType: 'vsix'
                    vsixFile: '$(PublisherID).$(ExtensionName)/$(PublisherID)..vsix'
                    publisherId: '$(PublisherID)'
                    extensionId: '$(ExtensionID)'
                    extensionName: '$(ExtensionName)'
                    updateTasksVersion: false
                    extensionVisibility: 'private' # Change to public if you're publishing to the marketplace
                    extensionPricing: 'free'
  

Para obtener más información, consulte Especificación de eventos que desencadenan canalizaciones.

Etapas de canalización

La siguiente sección le ayuda a comprender cómo funcionan las fases de canalización.

Fase 1: Ejecución y publicación de pruebas unitarias

Esta fase ejecuta pruebas unitarias y publica resultados de pruebas en Azure DevOps.

Para ejecutar pruebas unitarias, agregue un script personalizado al package.json archivo como en el ejemplo siguiente.

"scripts": {
    "testScript": "mocha ./TestFile --reporter xunit --reporter-option output=ResultsFile.xml"
},

1. Agregue Use Node CLI for Azure DevOps (tfx-cli) para instalar tfx-cli en el agente de compilación.

2. Agregue la tarea npm con el comando install y apunte a la carpeta con el archivo package.json.

3. Agregue la Bash tarea para compilar TypeScript en JavaScript.

4. Agregue la npm tarea con el custom comando , seleccione como destino la carpeta que contiene las pruebas unitarias y escriba testScript como comando . Use las siguientes entradas:

   • Mandar: custom
   • Carpeta de trabajo que contiene package.json: /TestsDirectory
   • Comandos y argumentos: testScript

5. Agregue la tarea Publicar resultados de pruebas . Si está usando el informador XUnit de Mocha, asegúrese de que el formato de resultado sea JUnit y no XUnit. Establezca la carpeta de búsqueda en el directorio raíz. Use las siguientes entradas:

   • Formato de resultado de la prueba: JUnit
   • Archivos de resultados de pruebas: **/ResultsFile.xml
   • Carpeta de búsqueda: $(System.DefaultWorkingDirectory)

   Una vez publicados los resultados de la prueba, la salida de la pestaña pruebas debe tener un aspecto similar al del ejemplo siguiente.

   

Fase 2: Empaquetar la extensión y publicar artefactos de compilación

1. Agregue Use Node CLI for Azure DevOps (tfx-cli) para instalar tfx-cli en el agente de compilación.

2. Agregue la tarea npm con el comando install y apunte a la carpeta con el archivo package.json.

3. Agregue la Bash tarea para compilar TypeScript en JavaScript.

4. Para consultar la versión existente, agregue la tarea Versión de extensión de consulta mediante las siguientes entradas:

   • Conexión a: Visual Studio Marketplace
   • Visual Studio Marketplace (conexión de servicio): conexión de servicio
   • Id. de publicador: identificador del publicador de Visual Studio Marketplace
   • Id. de extensión: Id. de la extensión en el archivo vss-extension.json
   • Aumento de la versión: Revisión
   • Variable de salida: Task.Extension.Version

5. Para empaquetar las extensiones basadas en JSON de manifiesto, agregue la tarea Package Extension mediante las siguientes entradas:

   • Carpeta manifiestos raíz: apunta al directorio raíz que contiene el archivo de manifiesto. Por ejemplo, $(System.DefaultWorkingDirectory) es el directorio raíz.
   • Archivo de manifiesto: vss-extension.json
   • Id. de publicador: identificador del publicador de Visual Studio Marketplace
   • Id. de extensión: Id. de la extensión en el archivo vss-extension.json
   • Nombre de la extensión: nombre de la extensión en el archivo vss-extension.json
   • Versión de la extensión: $(Task.Extension.Version)
   • Invalidar la versión de tareas: activada (true)
   • Tipo de invalidación: Reemplazar solo revisión (1.0.r)
   • Visibilidad de la extensión: si la extensión todavía está en desarrollo, establezca el valor en privado. Para liberar la extensión al público, establezca el valor en público.

6. Para copiar en archivos publicados, agregue la tarea Copiar archivos mediante las siguientes entradas:

   • Contenido: todos los archivos que se van a copiar para publicarlos como un artefacto
   • Carpeta de destino: la carpeta en la que se copian los archivos.
     • Por ejemplo: $(Build.ArtifactStagingDirectory)

7. Agregue Publicar artefactos de compilación para publicar los artefactos y usarlos en otros trabajos o canalizaciones. Use las siguientes entradas:

   • Ruta de acceso para publicar: ruta de acceso a la carpeta que contiene los archivos que se están publicando.
     • Por ejemplo: $(Build.ArtifactStagingDirectory)
   • Nombre del artefacto: nombre proporcionado al artefacto
   • Ubicación de publicación de artefactos: elija Azure Pipelines para utilizar el artefacto en trabajos futuros.

Fase 3: Descarga de artefactos de compilación y publicación de la extensión

1. Para instalar tfx-cli en el agente de compilación, agregue Use Node CLI for Azure DevOps (tfx-cli) (Uso de la CLI de Node para Azure DevOps [tfx-cli]).

2. Para descargar los artefactos en un nuevo trabajo, agregue la tarea Descargar artefactos de compilación mediante las siguientes entradas:

   • Descargar artefactos generados por: si va a descargar el artefacto en un nuevo trabajo desde la misma canalización, seleccione Compilación actual. Si va a descargar en una nueva canalización, seleccione Compilación específica.
   • Tipo de descarga: elija Artefacto específico para descargar todos los archivos que se publicaron.
   • Nombre del artefacto: el nombre del artefacto publicado
   • Directorio de destino: la carpeta donde se deben descargar los archivos.

3. Para obtener la tarea Publicar extensión , use las siguientes entradas:

   • Conexión a: Visual Studio Marketplace
   • Conexión de Visual Studio Marketplace: ServiceConnection
   • Tipo de archivo de entrada: archivo VSIX
   • Archivo VSIX: /Publisher.*.vsix
   • Id. de publicador: identificador del publicador de Visual Studio Marketplace
   • Id. de extensión: Id. de la extensión en el archivo vss-extension.json
   • Nombre de la extensión: nombre de la extensión en el archivo vss-extension.json
   • Visibilidad de la extensión: privada o pública

Opcional: Instalar y probar la extensión

Instale una extensión que se comparta con usted en unos pocos pasos:

1. En el panel de control de la organización (https://dev.azure.com/{organization}/_admin), vaya a la página de administración de la colección de proyectos.
2. En la pestaña Extensiones , busque la extensión en el grupo Extensiones compartidas conmigo y seleccione el vínculo de extensión.
3. Instale la extensión.

Si no puede ver la pestaña Extensiones , asegúrese de que está en el panel de control (la página de administración en el nivel de colección de proyectos, https://dev.azure.com/{organization}/_admin) y no en la página de administración de un proyecto.

Si no ve la pestaña Extensiones , las extensiones no están habilitadas para su organización. Puede obtener acceso anticipado a la característica de extensiones mediante la unión al Programa de partners de Visual Studio.

Para empaquetar y publicar extensiones de Azure DevOps en Visual Studio Marketplace, puede descargar Tareas de extensión de Azure DevOps.

Preguntas más frecuentes

Consulte las siguientes preguntas más frecuentes sobre cómo agregar tareas personalizadas de compilación o versión en extensiones para Azure DevOps.

P: ¿Cómo puedo restringir el uso de comandos de Azure Pipelines para la tarea?

Puede restringir el uso y las variables de comandos de Azure Pipelines, que se establecen por tarea. Esta acción podría ser útil para evitar el acceso sin restricciones a variables o comandos de vso por parte de los scripts personalizados cuando ejecutan tareas. Se recomienda configurarlo para nuevas tareas. Para aplicarlo, es posible que tenga que agregar la siguiente instrucción al archivo task.json:

"restrictions": {
  "commands": {
    "mode": "restricted"
  },
  "settableVariables": {
    "allowed": ["variable1", "test*"]
  }
}

Si se especifica el valor de restricted para mode, solo puede ejecutar los comandos siguientes mediante esta tarea:

• logdetail
• logissue
• complete
• setprogress
• setsecret
• setvariable
• debug
• settaskvariable
• prependpath
• publish

Las settableVariables restricciones permiten pasar una lista de variables permitidas, que se establecen mediante setvariable comandos o prependpath . También permite expresiones regulares básicas. Por ejemplo, si la lista de permitidos era: ['abc', 'test*'], estableciendo abc, testo test1 como variables con cualquier valor o pendientes en la ruta de acceso se realizaría correctamente, pero si intenta establecer un proxy de variable, advertiría. La lista vacía significa que ninguna variable cambia por tarea.

Si se omite la settableVariables clave o commands , no se aplica la restricción pertinente.

La característica de restricción está disponible en la versión del agente 2.182.1.

P: ¿Cómo se controla la señal de cancelación por una tarea?

El agente de canalización envía las señales SIGINT y SIGTERM al proceso secundario correspondiente. No hay medios explícitos en la biblioteca de tareas para procesar. Para obtener más información, consulte Cancelación de trabajos del agente.

P: ¿Cómo puedo quitar la tarea de la colección de proyectos?

No se admite la eliminación automática de tareas. La eliminación automática no es segura y interrumpe las canalizaciones existentes que ya usan estas tareas. Sin embargo, puede marcar las tareas como en desuso. Para ello, aumente la versión de la tarea y marque la tarea como en desuso.

P: ¿Cómo puedo actualizar mi tarea personalizada al nodo más reciente?

Se recomienda actualizar a la versión más reciente del nodo. Para obtener información de ejemplo, consulte Actualización de tareas a Node 20.

Los agentes hospedados de Microsoft y varias versiones de Azure DevOps Server tienen ciclos de vida diferentes, lo que conduce a que se instalen diferentes versiones del ejecutor de Node en función de dónde se ejecute una tarea. Para garantizar la compatibilidad entre agentes con diferentes versiones del ejecutor de Node, el task.json archivo puede incluir varias secciones de ejecución. En el ejemplo siguiente, los agentes de Azure Pipeline con el ejecutor de Node 20 lo usan de forma predeterminada, mientras que los agentes sin él vuelven a la implementación de Node 10.

"execution": {
  "Node10": {
    "target": "bash.js",
    "argumentFormat": ""
  },
  "Node20_1": {
    "target": "bash.js",
    "argumentFormat": ""
  }
}

Para actualizar las tareas:

• Para asegurarse de que el código se comporta según lo previsto, pruebe las tareas en las distintas versiones del ejecutor de Node.

• En la sección ejecución de la tarea, actualice de Node o Node10 a Node16 o Node20.

• Para admitir versiones anteriores del servidor, debe dejar el Node/Node10 destino. Es posible que las versiones anteriores de Azure DevOps Server no tengan incluida la versión más reciente del ejecutor de Node.

• Puede elegir compartir el punto de entrada definido en el destino o tener destinos optimizados para la versión de Node usada.

  "execution": {
     "Node10": {
       "target": "bash10.js",
       "argumentFormat": ""
     },
     "Node16": {
       "target": "bash16.js",
       "argumentFormat": ""
     },
     "Node20_1": {
       "target": "bash20.js",
       "argumentFormat": ""
     }
  }
  

Contenido relacionado

• Referencia del manifiesto de extensión
• Integración de tareas personalizadas de canalización de compilación con extensiones
• Ejemplos de tareas de compilación y versión