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?
Related
we are updating the nuget packages in dotnet application with dotnet add package "package name" from a private feed in Azure Devops.
Recently we updated to .net 5.0.1( I am not sure if its related to the issue.)
But now while running the above command gives error in local machine as well as in azure piplelines.
I have tried the --interactive option and refreshed the PAT for packages etc as well.
command dotnet add "csprojFile" package "mypackageName"
Determining projects to restore...
Writing C:\Users\SirajUrRahman\AppData\Local\Temp\tmpD8BD.tmp
info : Adding PackageReference for package 'my package' into project '.\my csproj'.
info : GET https://api.nuget.org/v3/registration5-gz-semver2/mypackageName/index.json
info : NotFound https://api.nuget.org/v3/registration5-gz-semver2/mypackageName/index.json 889ms
error: Unable to load the service index for source https://pkgs.dev.azure.com/myorganization/_packaging/Feed/nuget/v3/index.json.
error: Response status code does not indicate success: 401 (Unauthorized).
Usage: NuGet.CommandLine.XPlat.dll package add [options]
Options:
-h|--help Show help information
--force-english-output Forces the application to run using an invariant, English-based culture.
--package Id of the package to be added.
--version Version of the package to be added.
-d|--dg-file Path to the dependency graph file to be used to restore preview and compatibility check.
-p|--project Path to the project file.
-f|--framework Frameworks for which the package reference should be added.
-n|--no-restore Do not perform restore preview and compatibility check. The added package reference will be unconditional.
-s|--source Specifies NuGet package sources to use during the restore.
--package-directory Directory to restore packages in.
--interactive Allow the command to block and require manual action for operations like authentication.
--prerelease Allows prerelease packages to be installed.
Thanks for any help.
Feel free to ask anything if needed.
This issue was related to .net 5 and there is already a bug created for that on github here is the link for that. https://github.com/NuGet/Home/issues/10305.
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!
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 deploying a nuget package which is a result of TeamCity Feature Branch build. The build number format I use includes branch name: 1.0.0.%build.counter%-%vcsroot.branch%.
I need branch name at Octopus Deploy side to customize my deploy. What is the right way to have branch name as a Variable?
We should be able to parse this out from the Package Name and set an Octopus Variable using something like this
Create the variable
Create a step to extract the NuGet (no features) and a PowerShell step
Use some PowerShell to set the variable by parsing the version number of that package
Hope this helps
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.