web-dev-qa-db-fra.com

Schéma de gestion des versions de package Azure Pipeline Nuget, comment obtenir «1.0. $ (Rev: r)»

Je configure une génération Azure Pipelines qui doit empaqueter une bibliothèque de classes C # .NET dans un package NuGet.

Dans cette documentation , il répertorie quelques façons différentes de générer automatiquement des chaînes SemVer. En particulier, je veux implémenter celui-ci:

$(Major).$(Minor).$(rev:.r), où Major et Minor sont deux variables définies dans le pipeline de génération. Ce format incrémentera automatiquement le numéro de build et la version du package avec un nouveau numéro de patch. Il gardera les versions majeures et mineures constantes jusqu'à ce que vous les changiez manuellement dans le pipeline de génération.

Mais c'est tout ce qu'ils en disent, aucun exemple n'est fourni. Un lien pour en savoir plus vous amène à cette documentation , où il dit ceci:

Pour byBuildNumber, la version sera définie sur le numéro de build, assurez-vous que votre numéro de build est un bon SemVer, par ex. 1.0.$(Rev:r). Si vous sélectionnez byBuildNumber, la tâche extraira une version en pointillés, 1.2.3.4 Et l'utilisera uniquement, en supprimant toute étiquette. Pour utiliser le numéro de build tel quel, vous devez utiliser byEnvVar comme décrit ci-dessus et définir la variable d'environnement sur BUILD_BUILDNUMBER.

Encore une fois, aucun exemple n'est fourni. On dirait que je veux utiliser versioningScheme: byBuildNumber, Mais je ne sais pas trop comment définir le numéro de build, je pense qu'il le tire de la variable d'environnement BUILD_BUILDNUMBER, Mais je ne trouve pas un moyen de définir des variables d'environnement, uniquement des variables de script. De plus, suis-je supposé simplement définir cela sur 1.0.$(Rev:r), ou sur $(Major).$(Minor).$(rev:.r)? J'ai peur que cela ne fasse que l'interpréter littéralement.

La recherche de la chaîne littérale "versioningScheme: byBuildNumber" renvoie un seul résultat ... Quelqu'un at-il un Azure-pipelines.yml Avec ce schéma de version?

continuous-integrationazure-devopsnugetazure-pipelinessemantic-versioning
11
aurath

byBuildNumber utilise le numéro de build que vous définissez dans votre YAML avec le champ name.

Ex: name: $(Build.DefinitionName)-$(date:yyyyMMdd)$(rev:.r)

Donc, si vous définissez votre format de construction sur name: 1.0.$(rev:.r), cela devrait fonctionner comme vous vous y attendez.

5
Daniel Mann

Exemple de travail YAML pour l'empaquetage/versioning utilisant byBuildNumber

REMARQUE le deuxième paramètre de counter - c'est une valeur de départ, vraiment utile lors de la migration de builds à partir d'autres systèmes de build comme TeamCity; Il vous permet de définir explicitement la prochaine version de build lors de la migration. Après la migration et la génération initiale dans Azure DevOps, la valeur de départ peut être redéfinie sur zéro ou sur la valeur de départ (comme 100) que vous préférez chaque fois que majorMinorVersion est modifié:

référence: contre-expression

name: $(majorMinorVersion).$(semanticVersion) # $(rev:r) # NOTE: rev resets when the default retention period expires

pool: 
  vmImage: 'vs2017-win2016' 

# pipeline variables
variables:
  majorMinorVersion: 1.0
  # semanticVersion counter is automatically incremented by one in each execution of pipeline
  # second parameter is seed value to reset to every time the referenced majorMinorVersion is changed
  semanticVersion: $[counter(variables['majorMinorVersion'], 0)]
  projectName: 'MyProjectName'
  buildConfiguration: 'Release'

# Only run against master
trigger:
- master

# Build
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    projects: '**/*.csproj'
    arguments: '--configuration $(BuildConfiguration)'

# Package
- task: DotNetCoreCLI@2
  displayName: 'NuGet pack'
  inputs:
    command: 'pack'
    configuration: $(BuildConfiguration)
    packagesToPack: '**/$(ProjectName)*.csproj'
    packDirectory: '$(build.artifactStagingDirectory)'
    versioningScheme: byBuildNumber # https://docs.Microsoft.com/en-us/Azure/devops/pipelines/tasks/build/dotnet-core-cli?view=Azure-devops#yaml-snippet

# Publish
- task: DotNetCoreCLI@2
  displayName: 'Publish'
  inputs:
    command: 'Push'
    nuGetFeedType: 'internal'
    packagesToPush: '$(build.artifactStagingDirectory)/$(ProjectName)*.nupkg'
    publishVstsFeed: 'MyPackageFeedName'
15
Emil

Schéma de gestion des versions de package Azure Pipeline Nuget, Comment obtenir "1.0. $ (Rev: r)"

Cela devrait être un problème dans la documentation. J'ai reproduit ce problème lorsque j'ai défini $(Major).$(Minor).$(rev:.r) au format de numéro de build dans les options du pipeline de build:

enter image description here

Cependant , j'ai soudainement remarqué que le numéro de build n'est pas correct avec ce format après de nombreux tests de build:

enter image description here

Il y a deux points . Entre 0 et 2 (Ouvrir l'image ci-dessus dans un nouvel onglet). C'est évidemment très étrange. J'ai donc changé le format du numéro de build en:

$(Major).$(Minor)$(rev:.r)

Ou

$(Major).$(Minor).$(rev:r)

Maintenant, tout fonctionne bien.

Comme test, je viens de définir le format du numéro de build sur $(rev:.r), et le numéro de build est . X . Ainsi, nous pourrions confirmer que la valeur de $(rev:.r) y compris le . Par défaut.

Remarque: Puisque où Major et Minor sont deux variables définies dans le pipeline de génération, nous devons donc les définir manuellement dans les variables.

J'espère que cela t'aides.

2
Leo Liu-MSFT

J'ai eu le même problème et je vais maintenant clarifier les choses.

Premièrement, quelle est la définition de Numéro de build ?

Par le document officiel de schéma Azure Pipeline YAML , il est

name: string  # build numbering format
resources:
  containers: [ containerResource ]
  repositories: [ repositoryResource ]
variables: { string: string } | [ variable | templateReference ]
trigger: trigger
pr: pr
stages: [ stage | templateReference ]

Regardez la première ligne:

name: string  # build numbering format

Oui c'est ça!

Vous pouvez donc le définir comme

name: 1.0.$(Rev:r)

si vous préférez Versioning sémantique . ensuite

Deuxièmement, quelle est la signification de versioningScheme: 'byBuildNumber' dans la tâche NuGetCommand @ 2?

C'est vraiment simple: utilisez simplement le format défini par name!

Enfin et surtout

Le document officiel sur Package Versioning et Pack NuGet packages ne précise pas ce qu'est vraiment un numéro de build et comment le définir. C'est vraiment trompeur. Et je suis si triste en tant qu'employé MS que je devais recourir à des ressources externes pour clarifier tout cela.

0
Robert