Promote if stable?

[clairernovotny]

My scenario is this -- I want to always promote packages to the Prerelease view so that it contains everything, but only promote stable packages to the Release view.

It would be nice to have an option in the task to only run if the package version is stable. That would enable me to put it in my "prod stage" and but only run if the package version is stable. I might release pre-releases to NuGet, so the stage alone isn't sufficient.

One way to do this that might work, without relying on NuGet libraries, is to try a Version.Parse() with a split of +. If it works, it's stable, since we're trying to exclude anything with a -foobar tag.

[renevanosnabrugge]

And what is your decision criteria for “stable” ?

Verstuurd vanaf mijn iPhone

Op 2 aug. 2019 om 14:22 heeft Oren Novotny notifications@github.com<mailto:notifications@github.com> het volgende geschreven:

My scenario is this -- I want to always promote packages to the Prerelease view so that it contains everything, but only promote stable packages to the Release view.

It would be nice to have an option in the task to only run if the package version is stable. That would enable me to put it in my "prod stage" and but only run if the package version is stable. I might release pre-releases to NuGet, so the stage alone isn't sufficient.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenevanosnabrugge%2Fvsts-promotepackage-task%2Fissues%2F31%3Femail_source%3Dnotifications%26email_token%3DABOH2WQ3QY4BO53PZOUI5ITQCQRGXA5CNFSM4II5IAO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDBQL5A&data=02%7C01%7C%7Cf3e53106a4294adf617308d71744085a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637003453273085796&sdata=dfR3CTCqMJRCGsRw9a1T2SnL5NSi%2BX8KWg2i7hOuXno%3D&reserved=0, or mute the threadhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABOH2WRA4JHQBO6WHACF6MLQCQRGXANCNFSM4II5IAOQ&data=02%7C01%7C%7Cf3e53106a4294adf617308d71744085a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637003453273095801&sdata=GSbsvwTf4P00Z6Z8nyyONQufynObhyIT%2FK73Kv%2FeE2M%3D&reserved=0.

[clairernovotny]

Stable is not having any prerelease tag in it, at least that's how it works on NuGet. Not sure if the same applies to other package types this tool supports?

[renevanosnabrugge]

You mean a semver tag? Or a real tag in the feed? In my opinion the release view is to overcome the Semver tag. Do not reversion the package but promote it to another view.

Verstuurd vanaf mijn iPhone

Op 2 aug. 2019 om 19:12 heeft Oren Novotny notifications@github.com<mailto:notifications@github.com> het volgende geschreven:

Stable is not having any prerelease tag in it, at least that's how it works on NuGet. Not sure if the same applies to other package types this tool supports?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenevanosnabrugge%2Fvsts-promotepackage-task%2Fissues%2F31%3Femail_source%3Dnotifications%26email_token%3DABOH2WTIGDBDCIAJOYQFWDTQCRTGBA5CNFSM4II5IAO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OKWUI%23issuecomment-517778257&data=02%7C01%7C%7C52de16dd6b954bd1c81b08d7176c886a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637003627217350082&sdata=6nhwN2aifq%2FqamHwM7rigz9Bq8uPKf2NZFcBoqS%2FBkI%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABOH2WVMXUYRHIISYJW5N5TQCRTGBANCNFSM4II5IAOQ&data=02%7C01%7C%7C52de16dd6b954bd1c81b08d7176c886a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637003627217360088&sdata=CI4jSyN785c2X5bqpSmA3nJBiXnL2AgvgFmH9Bo3hY4%3D&reserved=0.

[NightOwl888]

Seems like a trivial thing to do without changing the task. You can definitively check whether a version number is a prerelease by whether it has a - in it, which can be a condition whether or not to run the task.

# Always push to Prerelease
- task: rvo.vsts-promotepackage-task.vsts-promotepackage-task.rvo-vsts-promotepackage-task@2
  displayName: 'Promote package to Prerelease View'
  inputs:
    feed: '$(ArtifactFeedID)'
    releaseView: 'Prerelease'
    inputType: packageFiles
    packagesDirectory: '$(Build.ArtifactStagingDirectory)/$(NuGetArtifactName)'

# Only push to Release if we are stable
- task: rvo.vsts-promotepackage-task.vsts-promotepackage-task.rvo-vsts-promotepackage-task@2
  displayName: 'Promote package to Release View'
  condition: and(succeeded(), not(contains(variables['Build.BuildNumber'], '-')))
  inputs:
    feed: '$(ArtifactFeedID)'
    releaseView: 'Release'
    inputType: packageFiles
    packagesDirectory: '$(Build.ArtifactStagingDirectory)/$(NuGetArtifactName)'

[clairernovotny]

@NightOwl888 The build number isn't necessarily in the Release Management step.

[NightOwl888]

@onovotny

I see. That is one thing I find annoying about Azure Pipelines coming from TeamCity, where the variables flow all the way through all of the tasks.

A workaround I came up with for version numbers is to write them to a text file from the build stage, and make the file either a pipeline or release artifact. Then any other stage (or agent) can download the artifact and rehydrate the variables with a powershell task.

- powershell: |
    $version = Get-Content '$(Build.ArtifactStagingDirectory)/$(VersionArtifactName)/$(PackageVersionFileName)' -Raw
    Write-Host "##vso[task.setvariable variable=PackageVersion;]$version"
    Write-Host "##vso[task.setvariable variable=Build.BuildNumber;]$version"
  displayName: 'Rehydrate Version Variables'

[clairernovotny]

@renevanosnabrugge I mean just that. Unfortunately, Artifacts doesn't have a rule where I can say "stable packages should be in the release view". I'd love it but that's what I'm trying to do with this. I don't need it to rename/reversion, just be able to evaluate if it is stable or not so that it can either promote or not.

[renevanosnabrugge]

The idea of this package initially was to have a release pipeline for a package. Every stage to a view. Once stable , the package promotes to the production view.

Verstuurd vanaf mijn iPhone

Op 2 aug. 2019 om 21:57 heeft Oren Novotny notifications@github.com<mailto:notifications@github.com> het volgende geschreven:

@renevanosnabruggehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenevanosnabrugge&data=02%7C01%7C%7Cfea338739b3346a771ad08d71783af0e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637003726646541175&sdata=9Wq6r7bI5yZpldaF3CR9PPsusPOK0ZfZjCwuOEfyW0M%3D&reserved=0 I mean just that. Unfortunately, Artifacts doesn't have a rule where I can say "stable packages should be in the release view". I'd love it but that's what I'm trying to do with this. I don't need it to rename/reversion, just be able to evaluate if it is stable or not so that it can either promote or not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenevanosnabrugge%2Fvsts-promotepackage-task%2Fissues%2F31%3Femail_source%3Dnotifications%26email_token%3DABOH2WV2HDETOWG4IAAJLBTQCSGTPA5CNFSM4II5IAO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OWMDQ%23issuecomment-517826062&data=02%7C01%7C%7Cfea338739b3346a771ad08d71783af0e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637003726646551186&sdata=WV2gU1bpRQTVMSDyeOjrJYRXGqEXYp9gG4VBXTFzGyQ%3D&reserved=0, or mute the threadhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABOH2WUUOG3HW6OYHNPHST3QCSGTPANCNFSM4II5IAOQ&data=02%7C01%7C%7Cfea338739b3346a771ad08d71783af0e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637003726646561191&sdata=KALTGkWz9koVsH8RaYwFs5sWwGoTLv04v8Uuc7Y%2F0b4%3D&reserved=0.

[clairernovotny]

That's what I want, but prerelease packages can go to production too, just not in the view.

Concretely, take Rx.NET. I have CI builds and every package goes to the Prerelease feed via one stage. Next, I have a manual approval on a production stage that deploys to NuGet. Specific prerelease packages may make it there, like "-preview01", "-preview02", etc. But those shouldn't go to the Release feed as it's still a prerelease package.