Add automatic push to ADO step when signing#1061
Conversation
|
back to draft mode to review some issues |
|
I have confirmed this works, so back to "ready for review" |
bachuv
left a comment
bachuv
left a comment
There was a problem hiding this comment.
Thanks for adding this step in the pipeline!
| feedsToUse: config | ||
| packagesToPush: '$(build.artifactStagingDirectory)/*.nupkg' | ||
| publishVstsFeed: '734e7913-2fab-4624-a174-bc57fe96f95d/d55248c1-5b53-411f-bfe7-73efc9e540d1' | ||
| allowPackageConflicts: true |
There was a problem hiding this comment.
What does this mean? Why are we allowing package conflicts?
|
My personal opinion is that I don't like pushing to nuget feeds as part of a build. I feel the act of releasing, even internally, should be a conscious decision beyond queueing a build. This is primarily because of how permanent nuget releases are. Once a version is published the most you can do is unpublish/delete it. You cannot reuse that version number. Having builds auto pushing to an internal feed may lead to accidentally pushing packages that are not quite ready and locking out that version number from a good package. In that vein, is there anything wrong with manually queueing a release from a build? If so, can we address those issues via improving the release def itself? |
3 participants
Another step in the effort to minimize our release burden. This PR makes it so that every time a package is signed, it is also pushed to ADO. In most scenarios, if we sign a package, we want to share them with another user, in which case ADO is the preferred mechanism. This prevents us from having to manually kick off the "release to ADO" feed, it will run automatically instead.