I'm using the AWS deploy lambda task within Azure DevOps. Within the lambda function that gets deployed, it's setup to pull a package from an artifact feed within the same Azure DevOps repo/installation.
If I run NuGet restore in a previous step to the deploy then the package can be accessed fine however when it then hits the AWS Lambda .NET Core Deployment step it gets a 401 when trying to read from the same feed.
Does anyone know how I could configure the lambda release step to successfully read from a custom feed?
The specific error is:
Response status code does not indicate success: 401
I am having the same issue but hopefully I can offer a bit of a new angle on it.
Rather than using the AWS deploy lambda run we are packaging our lambdas and pushing them to S3 to allow CloudFormation to deploy them. This uses the AWS dotnet toolkit to construct the deployment package (which is what aws deploy lambda is doing in the background). The powershell step that performs this then looks like:
dotnet lambda package
The resultant package will then typically be generated inside of the bin/release folder beneath your project.
What this then lets you do is add the parameters --msbuild-parameters "--no-restore" to the packaging process which will not trigger the automatic restore step. Inside of Azure DevOps Build Pipelines you can set a build step before it to restore for all solutions or csproj files which will authenticate against your feed automatically. We also set the version number of the asssemblies and I wanted to get rid of an annoying warning so our current version of this call looks like:
dotnet lambda package ("/p:Version=" + $VersionNumber) "/p:PreserveCompilationContext=false" --msbuild-parameters "--no-restore"
The problem that I am now running into is that passing in the msbuild-parameters seems to set the framework to target red hat linux (rhel.7.2-x64) resulting in the following error:
publish: C:\Program Files\dotnet\sdk\2.1.500\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198,5): error NETSDK1047: Assets file 'C:\Agent\_work\1\s\Kiosk.Microservice.User.Lambda.Command\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0/rhel.7.2-x64'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project. You may also need to include 'rhel.7.2-x64' in your project's RuntimeIdentifiers. [C:\Agent\_work\1\s\Kiosk.Microservice.User.Lambda.Command\Kiosk.Microservice.User.Lambda.Command.csproj]
I very explicitly want it to build for dotnetcore2.0 so I don't actually want to build for red hat linux.
This is where I am currently stuck as if I don't use the flag to stop the unauthenticated nuget restore step, I get the unauthorized error and I can't seem to pass dotnet.exe my feed credentials. If I do use the flag it builds for red hat Linux for no coherent reason. Hopefully this gets you at least a little farther!
Update: I now have my stuff working. I went and found the dotnet cli wrapper that dotnet lambda publish is actually using in the git repository for the toolset and duplicated its steps without the middleman. Because the msbuild-parameters flag was no longer used it didn't try to build it in red hat linux. I did also have to create the zip file afterwards as well but that is fairly trivial. The following is the powershell that is generating the new packages without the aws dotnet toolset:
# Run the build that will generate the proper files
dotnet publish --no-restore -f netcoreapp2.0 -c Release
# Create the path to the zip file
$PathToZip = $PathToCSProj + "\bin\Release\netcoreapp2.0\publish"
# Create the zip file
Compress-Archive -Path $PathToZip -DestinationPath ($PathToZip + $csproj[0].Name.trim(".csproj") + ".zip")
I hope this helps!
Related
I have a PowerShell script to push a package to AzureDevOps.
I want to run it, automatically, every time that I Check In the code to AzureDevOps in Visual Studio.
Is this possible? How can I do this?
If you are pushing package to git in Azure DevOps you can create build pipeline that will execute this package, and this build pipeline will have trigger to run after each commit.
IF you are pushing packages to Azure DevOps Artifacts then you have option to use Azure DevOps RestApi or Power Shell Module for Azure DevOps and trigger specific build.
I have created Xamarin.UITest that can run locally on my desktop. My goal is to execute these test as a part of a post-build script to run UITest after the app has built as mentioned in this article below:
https://tomsoderling.github.io/AppCenter-Automated-UI-tests-on-build/
Below is my script
appcenter test run uitest --app "MY-APP" --devices 168683d9 --app-path $APPCENTER_OUTPUT_DIRECTORY/MyApp.Mobile.Droid.apk --test-series "myapp-mobile-test" --locale "en_US" --build-dir $APPCENTER_SOURCE_DIRECTORY/MyApp.Mobile.UITests/bin/Release --token MY-TOKEN --uitest-tools-dir $APPCENTER_SOURCE_DIRECTORY/packages/Xamarin.UITest.*/tools
When the script above is apart of my appcenter post build script, I get the following error:
Error: Cannot find test-cloud.exe, the path specified by "--uitest-tools-dir" was not found.
Please check that "/Users/vsts/agent/2.141.1/work/1/s/packages/Xamarin.UITest.2.2.6/tools" is a valid directory and contains test-cloud.exe.
Minimum required version is "2.2.0".
I think a lot of people are having trouble dealing with this actually and I know it has something to do with --uitest-tools-dir OR --build-dir variables.
Keep in mind this I am first trying to do this with Xamarin.Android, if successful I will try the Xamarin.iOS
One clue i do see is when Tom says "I had to chose to build the app solution file in my App Center CI build - not simply the iOS project like I normally would" in the noted article, but I am not quite sure how to do that or if is connected to why AppCenter cannot locate my test-cloud.exe I will also say that test-cloud.exe somehow comes from the Xamarin.UITest nuget, but I do not see any test-cloud.exe file in my Xamarin.Forms project.
This answer works, but it's pretty fragile.
The test-cloud.exe can't be located at packages/Xamarin.UITest.2.X.X/tools in projects that uses the old project structure (projects that use packages.config). For new projects (new .csproj formats), there is no such file in the path of the project. The only way I found to make it work on AppCenter is to use it from the NuGet package cache (/Users/vsts/.nuget/packages/xamarin.uitest/2.X.X)
Kudos to AppCenter Agents for helping me to resolve this. 2 things were required as indicated below:
Agent Anvesh says
Hi there, Thanks for the details, So seems like you are using a nuget as a PackageReference in your project(this means that there will be no package folder in your project, packages will be there at user profile).
So when you are trying to run the test as part of the app center build. Then in the shell script used the --uitest-tools-dir value as below
/Users/vsts/.nuget/packages/xamarin.uitest/2.2.6/lib/tools
So I modified my above script to add the below:
--uitest-tools-dir /Users/vsts/.nuget/packages/xamarin.uitest/2.2.6/tools \
Agent Shawn says
So I added the below
msbuild $APPCENTER_SOURCE_DIRECTORY/MyApp.Mobile.UITestProject.csproj
I am doing the following steps:
dotnet restore
dotnet publish
octopusDeploy: Push packages
The second step creates a 'published-app' folder and the third step is meant to take that and create a .zip file and send it to the Octopus server.
The third step is connecting to the Octopus server but gives the error:
Running command: octo.exe push --server http://server.com/ --apikey SECRET
Pushing packages to Octopus server
Please specify a package to push
I am following this https://stackoverflow.com/a/38927027 so my third step has:
%teamcity.build.workingDir%/published-app/**/* => App.zip
Any ideas why the zip file is not being created?
Not sure if you ever got this working for yourself, however just in case it helps anyone we recently came across the same issue deploying an AspNetCore 2.0 web application running on net471 being built by TeamCity 2017.1.4 (build 47070).
After some tinkering I noticed that the "OctopusDeploy: Create and Push Packages" build step ran at our git checkout root directory, so I ending up having to use the following values for the "Package path patterns"
%ProjectDirectory%/published-app/**/* => %ProjectName%.%GitVersion.NuGetVersion%.zip
NB: %ProjectDirectory%, %ProjectName% and %GitVersion.NuGetVersion% are build parameters we have manually defined elsewhere in the build process that TeamCity can replace. %ProjectDirectory% is simply the application's source directory relative to the root of the git checkout i.e. WebApplication1 so the full path would be <full checkout path>/WebApplication1
Another gotcha that we experienced was that at the time of writing the combination of TeamCity and octo.exe (from Octopus.TeamCity v4.15.10) didn't like creating nupkg files, so make sure you try to produce a ".zip" file. In the error instances we would receive the following error:
Error from Octo.exe: Cannot run program "C:\BuildAgent\temp\buildTmp\octo-temp\3.0\octo.exe" (in directory "C:\BuildAgent\work\4e62985fa616fa1f"): CreateProcess error=206, The filename or extension is too long
I am trying to run a PostDeploy.ps1 script using an Azure deployment. The nuget package has the PostDeploy.ps1 file in it, but the script is never run.
Why might this be? The only line in the script is currently:
Write-Host "Test Custom Deployment Script"
This text never appears in the log.
Have you checked this location C:\Octopus\Applications.Tentacle\Packages to verify that the latest package has been downloaded?
I had an issue using Octopus and Teamcity where the artifacts view stated that the PostDeploy.ps1 had been added to the nuget package, but when I checked that location it wasn't there.
Octopus can cache the packages so check your timestamps and version numbers to ensure that the most up to date version of the package is being used. Could it be that an earlier version of PostDeploy.ps1 didnt have the
Write-Host "Test Custom Deployment Script"
line in it and that is the one that octopus is using during deployment?
I have a .Net 4.5 project that I am deploying with teamcity and Octopus Deploy which includes a PreDeploy.ps1, a Deploy.ps1 and a PostDeploy.ps1.
The build action on all three is Content. I have tried Copy To Output Directory set to do not copy and copy always.
I can see that when TeamCity creates the nuget packages, that all three powershell scripts are included in the artifacts view. However, following the deployment, only the Deploy and PostDeploy scripts are in the octopus directory on the tentacle machine.
Am I missing something here?
Octopus caches the downloaded packages, so perhaps you didn't bump the version number to force a fresh download? Alternatively you could check the "Re-download packages from the NuGet server" when deploying a release.
If PreDeploy.ps1 was added later than the other scripts then the above could be the reason.