-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Multiple Packages #25
Feature: Multiple Packages #25
Conversation
…e files using glob patterns, rather than explicitly specifying them. Reasoning: This task will most likely be run just after pushing package files, so the globs from that operation are much easier to obtain in the same context than specifying the package names explicitly.
…nd in the default group
Thanks for the prompt reply.
If you are referring to organization name, it is If you are referring to the account I log into Azure DevOps with, it is the same email address as in my git commit history. It will be great to be able to try it out installed so I can confirm backward compatibility and make any tweaks to the visual experience. |
I’l try to do iT asap
Verstuurd vanaf mijn iPhone
Op 26 jun. 2019 om 14:35 heeft Shad Storhaug <notifications@github.com<mailto:notifications@github.com>> het volgende geschreven:
Thanks for the prompt reply.
I can also push it and publish a private version to you only. Please send me your Azure DevOps Account name, and I can do that. Then you can use that task in your pipeline to test.
If you are referring to organization name, it is essco-stores. I don't currently have any live pipelines using this task, so pushing a new version should be okay.
If you are referring to the account I log into Azure DevOps with, it is the same email address as in my git commit history.
It will be great to be able to try it out installed so I can confirm backward compatibility and make any tweaks to the visual experience.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenevanosnabrugge%2Fvsts-promotepackage-task%2Fpull%2F25%3Femail_source%3Dnotifications%26email_token%3DABOH2WVRMNKS3OADVDDSWP3P4NPAJA5CNFSM4H3RAC3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYTL45Y%23issuecomment-505855607&data=02%7C01%7C%7C080545a59a964fe7fdf508d6fa32bf6f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636971493199507517&sdata=vXjskC1HC6O0SeLzCnwrXw9XybMOYY1isj5UniU3hos%3D&reserved=0>, or mute the thread<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABOH2WT6RAH66ZPBDTVFMC3P4NPAJANCNFSM4H3RAC3A&data=02%7C01%7C%7C080545a59a964fe7fdf508d6fa32bf6f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636971493199517534&sdata=5Q1YjNy64tJdOZfFl5Vs%2B%2Bzjqz34iTWNOYoA7U4bQ%2BE%3D&reserved=0>.
|
I built and shared the new version with you. Let me know if it works! |
Thanks. I am still trying out the task, but there is a bit of a snag with the visual experience for the version pick list. I haven't pushed the commit to GitHub yet, but I have changed the pick list for Either way, this poses a slight problem for the databinding for the
I can think of 4 different options for handling this:
If you know of any way to pull the first Let me know which option seems most natural to you. Personally, I am leaning toward option 2. |
…comma by default, so we also need to accept a comma delimiter.
Unfortunately, it isn't working on the Azure DevOps server. It is failing on the first REST call, I have added the original error messages and stack trace to the error that is being re-thrown in order to try to get more info about the nature of the error. For the time being, I have also removed the pick list from the version field (option 2). This commit can be reverted if you decide otherwise. Could you please package up a new DEV version and push it to me? Also, if you have time to look into this error, maybe you have more of a clue why it is happening than I. |
I do not support the server currently. So that is no problem. Will try to push a new dev version this weekend
Thanks
Verstuurd vanaf mijn iPhone
Op 28 jun. 2019 om 19:59 heeft Shad Storhaug <notifications@github.com<mailto:notifications@github.com>> het volgende geschreven:
Unfortunately, it isn't working on the Azure DevOps server. It is failing on the first REST call, Get-FeedId. I am not sure what the issue is because the original error message is not coming through the try/catch block. The error isn't happening when I run it locally using the $env:PAT variable - locally, it runs all the way through to the end.
I have added the original error messages and stack trace to the error that is being re-thrown in order to try to get more info about the nature of the error.
For the time being, I have also removed the pick list from the version field (option 2). This commit can be reverted if you decide otherwise.
Could you please package up a new DEV version and push it to me? Also, if you have time to look into this error, maybe you have more of a clue why it is happening than I.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenevanosnabrugge%2Fvsts-promotepackage-task%2Fpull%2F25%3Femail_source%3Dnotifications%26email_token%3DABOH2WXY52YTCA4XKAIZBOTP4ZGONA5CNFSM4H3RAC3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2YSGI%23issuecomment-506824985&data=02%7C01%7C%7Cabd3291909f44244dd5508d6fbf24e07%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636973415434251470&sdata=%2BP96MCm0p%2BuGqK4JKyBlRqlVsct7SzUwi4Xyop%2F%2Fxew%3D&reserved=0>, or mute the thread<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABOH2WSGRYCOW7ERYN3I4ETP4ZGONANCNFSM4H3RAC3A&data=02%7C01%7C%7Cabd3291909f44244dd5508d6fbf24e07%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636973415434261475&sdata=fS40IHAr%2F9YeDOACu4GjsAwMwIyjLR0vwd6keke5B3A%3D&reserved=0>.
|
Oops, I guess that was confusing. I meant it isn't working on the Azure DevOps account you sent it to (the cloud service, not a standalone server). |
…s to retrieving the data from the metadata within the packages (NuGet and npm only).
…ng and help markdown for the package inputs
…minate variable scoping issues.
…he regex style matching and parsing in favor of a real Uri object.
…etween package names
UpdateI took it upon myself to make some local builds and debug them to work out what the issue was. It was due to the fact that the flow of the script expected the calls in a specific order in order to maintain the scope of the variables. Moving that one method call broke that order, which was what caused it to fail. Function CallsSince that is quite confusing to contributors, I ended up adding function parameters to explicitly define what dependencies are required by each function. I wrapped the base URLs and headers into a custom PS object called TestingAlso, since that broke the ability to test, I updated the tests so they use the functionality built into the VstsTaskSdk to pass in values. Package "Parsing"I discovered that the package names don't always reflect the true version of the package. SemVer 2 allows passing metadata, which is recorded in the metadata, but not reflected on the name of the file. So, I changed the approach to extract the metadata from the packages rather than using a regular expression on the file name, which will ensure the name and version always matches what is in the feed. Backward CompatibilityI have confirmed in one YAML configuration test that passing in the values using the original names still works. So, technically there is no reason to bump the major version, but this is definitely at least a minor version update. Feed SupportI noticed that what is stated in the main part of the README has some updates in the release notes and made some attempts to add support for more package types using metadata. But, in the end the new functionality still only supports NuGet and NPM. Universal PackagesUsing the portal, there is no way to download these that I could find. Using the command line tools, only the package contents are downloaded. So, it appears the metadata for the packages only exists on the server. There would be no reasonable way to support a metadata approach for these, the original "name and version" way seems to be the only option here. ConclusionI have run a few tests using a private copy of this on Azure Pipelines and everything seems to be working well. I know you don't have a lot of time to dedicate to this, so I updated the screenshots so all you really need to do is bump the version, confirm it functions, and release it. Let me know if anything needs to be addressed before releasing it. |
I shared a private preview with you again.. Can you test? For me it seems to work |
Confirmed it is working on my end with NuGet glob patterns. Looks good! |
Published version 1.4.2 Thanks for all your hard work ! |
The "definition" field was renamed to "packageIds" to make it more clear. There is an "alias" in the configuration and I put in "definition" for backward compatibility. I tested it using YAML format and it seemed to be backward compatible in that case. Apparently, the GUI is a different story. If you re-select your package from the dropdown, you should be able to get it working again, it just needs to map the value to the new name. If all else fails, I suggest adding a new task, copying all of your old settings over from the current task, and removing the current task. Sorry, this is my first time messing around with an Azure DevOps task and the docs are pretty scarce on how updates work. |
After giving this a little thought, I suggest that you do this:
That should prevent others from having issues with backward compatibility, and will give people a way to roll back if they need to. Currently there is nothing in the control panel that gives you that option, you are stuck on the last major version that was released. Since you have not bumped to 2.x yet, there is only one option. |
@NightOwl888 @renevanosnabrugge Thanks for the quick responses! |
published a new major version and reverted changes in the 1.x version |
This is exactly what i needed for compatibility. My existing definitions are now using 1.x which is working like a charm again. I too am able to manually switch between 1.x and 2.x now. A very big thanks to the both of you for the quick solution! |
We could run the extension on-premise and added pull request #37. Maybe this could be the reason why you had authentication problems. |
This PR includes 2 new features:
#18 - Promotion of multiple packages in one go (by specifying the package ids separated by semicolons)
Makes it possible to use a Powershell task to get package ids from whatever format they may be in to a simple list like
PackageA;PackageB;PackageC
. This seems like a better option than hard wiring some wildcard logic into this task and opens up a range of use cases that go beyond the scope of #18.Promotion of multiple packages and versions by specifying package file paths (and/or glob patterns)
This feature is one that I will personally use - to re-use the same blobs I just used to push the packages to the feed in order to promote those same packages to a new view.
There will be an option button on the UI which will make the current
Package
andPackage version
fields invisible, while making thePackages source folder
andPackage contents
fields visible.Reasoning for this Feature:
This task is almost always going to follow a task that pushes packages to a package feed. The file names (or globs) of those packages will likely already be in the context of the pipeline. The file naming conventions of packages for both NPM and NuGet always follow known conventions, and contain exactly the information that is needed (package id and version) that can be used for promotion. It seems like an extra unnecessary step to specify the package id - when using globs in the build/release pipeline, the package ids won't exist anywhere in the pipeline except on the file names of the actual packages.
This feature also enables a use case where the packages being promoted don't all have the same version number.
Testing
I had a bit of trouble trying to work out how testing is supposed to be done here, but since I didn't change anything after the
Run
method, I was able to test the logic that was added by commenting everything except forWrite-Host
in theSet-PackageQuality
function and also commenting the call toInitialize-Request
(which contains all but the last line of the formerRun
method).In a nutshell, the only real change to the former logic was to separate
Initialize-Request
fromSet-PackageQuality
so the initalization could be run only once, while callingSet-PackageQuality
multiple times. You had these pretty well separated already, so this was just moving one function call. Although I wasn't able to run all of the code, I am pretty sure the code will function as is.Here is the script I used to debug:
If you don't have time to test this yourself, I could do it if you could provide some guidance on how you are testing this task.
It might be helpful if you create a quick wiki page explaining what testing input values are required and some possible dummy values if a real value isn't necessarily needed. The
@runlocal
argument is a bit confusing, since it effectively runs nothing when set to$true
, but without this set a PAT cannot be overridden using an environment variable.Dependencies
Do note that the biggest change here was upgrading the VstsTaskSdk to the latest version. The upgrade was not necessarily needed, but the former pull of the SDK didn't have the binary
.dll
files, and without them the blob functionality doesn't work. I didn't test these changes with the former SDK version, but I know for sure that Minimatch.dll is required. If you want to revert/exclude the SDK commit, it probably won't be a problem as long as you grab that.dll
and check carefully for other missing dependencies.Backward Compatibility
These features should be backward compatible (untested), but since this is more than a patch I would still recommend bumping the version to 2.x to prevent breaking anyone's builds.
Feed Support
Since you have already stated that only NPM and NuGet feeds are supported, those are the only package types the
Get-PackageNameAndVersion
function supports. However, for maintainability separate regexes were used for each package type, so support for other package types can be added simply by adding the new regex to a new variable and changing this line to add the new variable to the array. The only condition is that named capturing groupsname
andversion
must be included in the regex.Maybe in some future version the regex could be specified as a parameter, but since the conventions that the packaging tools use are standardized, this should not really be necessary.