-
Notifications
You must be signed in to change notification settings - Fork 23
Conversation
ashtat
commented
Jan 6, 2021
- Publishing phase will now push the plugin to the public UPM feed.
- Added "dry-run" support for testing to the UPM packaging script.
…nity into user/ashtat/NpmPublishTEst
@@ -1,3 +1,3 @@ | |||
registry=https://pkgs.dev.azure.com/aipmr/MixedReality-Unity-Packages/_packaging/Unity-packages/npm/registry/ | |||
registry=https://microsoft.pkgs.visualstudio.com/Analog/_packaging/MixedReality-UPM-Internal/npm/registry/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the name of the feed includes the word "Internal". Is this a staging feed before the package goes to an external feed? It's obvious that I don't know how all of this works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the packaging stage we publish to an internal feed, which can be then tested to make sure everything is good. Once the build is "approved" after the packaging phase, the publishing phase then pushes the plugin to both nuget and UPM public feeds. There are two separate .npmrc files that correspond to internal and public feeds, these are under "tools" subdir. These get placed (and renamed to ".npmrc") under the plugin hierarchy depending on which feed we need to publish to.
stage.stage_binaries() | ||
else: | ||
stage.stage_binaries(args.stage) | ||
if not args.tarball: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why you start with !tarball instead of checking for args=tarball? It's easier for me to think in the positive case instead of negating the comparator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the script takes the plugin folder into a tarball which then gets pushed to the feed or it can just pack it as a tarball to be pushed later. The initial idea was to push to the internal feed during the packaging stage and store the tarball as an artifact which can be then downloaded during the "publish" stage to be pushed to the public feed. Unfortunately pushing the tarball is cryptically failing on the CI build machine. Long winded way to say this wasn't super intentional. :)