We have an Azure Entreprise Agreement with a main subscription to which a VSTS account is bound. We have setup the Package Management extension in order to host some usefull packages for diferent projects. For each customer, we create a subscription in this EA and a VSTS account bound to it. We build our customer projects on the Hosted build agent of the latter subscription.
But when it's time for the build process to restore NuGet packages (using Nuget Installer task) that are stored on the main package feed, it looks like that the build service cannot access this feed (probably because it's not part of the same subscription).
Is there a way to allow an external build service in the main feed permissions, or even use an api key in the NuGet Installer task of the customer build definition, in order to be able to restore packages from the main feed ?
EDIT: i tryed to use a specific nuget.config with either the apiKey (with the same api key that is locally set on my dev machine) or the packageSourceCredentials tag. None of the 2 let the build agent restore the packages.
EDIT: build agent screenshot (COETools.Testing comes from custom feed on another subscription)
EDIT: nuget.config
EDIT: I changed the build task to use the default agent supplied nuget.exe (i was previously using one in source control) and i managed to have the packages from nuget official feed to be restored. But i'm still unable to have the one from custom feed to restore.
OK, i had it to work, but i don't like the way i did it because i had to use my personal access token in the packageSourceCredentials tag.
Here is the nuget.config i used:
A better way to do it would be to use the API key (as the one that is generated in the dev local machine nuget.config instead of the personal access token.
Related
i am trying to publish artifact from my local host to azure devops as universal package. I downloaded newest azure CLI (2.3.1) installed newest azure devops (0.18.0). After that i logged in using az login and also created my own personal access token and logged in with az devops login command. There were no errors so i assume that i logged in, i also did it with debug enabled and everything went fine.
After that i tried to publish my universal package into artifacts in my project but i got message
Failed to update Universal Packages tooling. Operation returned a 302
status code.
Error screen
In debug mode i've got
failed while trying to get token for tenant {tenant_id}
Later on there was also a retry with PAT but again 302 status from OPTIONS request.
I also tried to do other actions on my account using cli and everything was ok. I removed user from my team and it went smoothly.
Can i ask for help with this issue, if there is other option to publish this package it would be great.
The operation of Package publish from Azure cli need the support of artifacttool, so we combine these 2 operation together. When you run the command of az artifacts universal publish, it will firstly install/update the artifact tool to latest, so that it could make sure the publish action can be smoothly.
Now, the issue you faced is during the artifact tool updating. Not sure what happened on your side since it all work fine for me at present. I did universal package publish very successfully just now.
Work around:
Since you stuck at artifact tool updating, just avoid that. You can do package publish by using Azure devops task.
Just go pipeline, add Universal packages task and then configure it with below arguments:
Then, run this pipeline with self-agent(must). Because your are trying to publish the local files to Azure Universal package, only self-host agent can have ability to access local folder.
I'd like to execute a command line app that I created as part of my CI builds.
The command line app is not related to the repository on which the build is running. (Basically, its a tool that is supposed to send some project related metadata to a company web application to gather some metrics).
It seems I can execute it using a Command Line task, as explained here:
How to execute exe in VSTS Release pipeline empty process
The question is, however - how do I upload my custom tool into Azure Devops?
I know it's possible to create custom tasks (https://learn.microsoft.com/en-us/azure/devops/extend/develop/add-build-task?view=azure-devops) , but it seems quite a lot of effort to create, especially given that I have a console tool that is doing what I need.
I do this by including a seperate deployment folder in the git repo with my source code. This folder contains all the extra stuff (exe's) that I need to call to deploy.
You could if you wanted keep these artifacts in a different repo and/or different artifact if you wish as you can get any number of different artifacts
Then I include the deployment folder when publishing artifacts. In your build step you pull down the artifacts and it includes your EXE.
You're meant to be able to use things like NPM to install helper libraries on the fly but none of my required libraries were ever supported.
You can also use a self hosted agent which is your own host (Often an Azure VM). You install everything you need on there then you install a DevOps self hosted agent which lets build pipelines use it.
Create a build of your exe
Upload your exe to blob storage.
Create a SAS token to access your blob.
In your build create a task with a PowerShell script. In the PS script download your exe (unzip), and copy it to Build.StagingDirectory/"yourToolFolder". Then in your PS script run it. You probably want to pass it arguments like the location of the repo on the build agent.
A way to achieve this involve create a deployment group and add a server to the group where you have access and privileges to upload your console. it could be onprem or cloud depends in your requirements.
What I want to accomplish:
I want to deploy an Azure Cloud Service via Release Management. I managed to get this working by following the steps outlined in this post. In the post the Azure publishsettings file is added to the project and used in Release Management to deploy the Azure package to a Cloud Service. So far so good.
What is the issue:
The Azure publishsettings file will also contain information about the production environment. I don't want that information to be available to all the developers and therefor I would like to have a more secure alternative.
What did I try:
I created a custom action which takes 3 arguments: subscription id, subscription name and certificate key. This way the Azure information stays in Release Management and can be passed to a script. This didn't work because the action is not shown in the Release Template Toolbox.
What is my question:
What is the best way to pass Azure credentials to a deployment script via Release Management on a secure manner?
We have a solution for Build today that will work for RM in the future.
Publish Settings file is an important one with which anybody can get access to certain activities. And once how ever the way you pass on the publish settings file, it can be misused (if tried).
So along with the publish settings file, you need to add a bit of process to the deployment like -
Inactive or remove the management certificate which will in turn invalidate the given publish settings and anyone should request for a new set of publish settings file before they actually start any release procedures.
Even though it adds a rough edge to your smooth flow of deployment process, as it is a live or production system, it is always better to tight the process and make it idiot proof.
I'm using NancyFX and I added it to my solution via Nuget.
When I publish the solution to Azure, the solution is compiled and the nancy dlls goes to Azure without problem.
I am also a Bitbucket user, so I give a try to the continuos deployment, but the problem arises because no Nancy.dll is on the server.
Do I need to push the bin dlls to bitbucket?
Can Azure use the Nuget package information to download the external refs?
When setting up an Azure Web / Worker Role for the first time I need to 'Package' the project and upload it via the Azure portal. After doing this I can 'Publish' the application from Visual Studio.
Under which circumstances do I need to 'Package' the project again and update it via the Azure portal?
In other words - which changes require the project to be re-packaged?
Note: I need to 'Package' the project in order to upload it via the Azure portal. When I create a Compute Role in Azure, I must upload a package in order to be make the Compute Role operational.
From Azure portal:
You have nothing deployed to the production environment.
UPLOAD A NEW PRODUCTION DEPLOYMENT.
The Cloud Service package contains the role definitions, configuration settings, runtime bits, and other static content bundled with your app. Visual Studio (or PowerShell) creates an encrypted package (actually a zip file that you can look into, when building for emulator) for upload to the named slot you created via the portal.
In the future, there are certain things you can do without rebuilding the package, such as changing instance count and other configuration settings. Also: If you move your static content (such as your CSS, images, etc.) to blob storage, you can then update those directly without ever needing to recreate / redeploy the package (you may need to send some type of signal to your running app, to reload some resources, but that's going to be app-specific). If you have specific exe's or MSI's that get installed as part of your startup scripts, you can move these to blob storage as well, since they can easily be downloaded as your role startup code executes (and this cuts down on package size).
If you change anything defined exclusively in the service definition file (e.g. if you add a role or change a role size), you will have to repackage/redeploy (but you can deploy as an update, which won't take your service down [assuming you have 2 or more instances] or replace your assigned IP address).
I don't think you must package your project at the first time. You can publish your azure project for the first time. I'm not sure what prevent from your publishing. Could you explain a bit more.
I fact, the publish is very similar as package. Visual studio just packaged the project and uploaded them to azure on behalf of you.