I am trying to build my packages using TFS, already integrated with octopus server so that the package can be pulled to octopus server afterwards and get deployed automatically.Created a build definition to build db and windows packages. it goes successful for db however stuck in case of windows where it is supposed to create a release for its deployment.Error -:
There was a problem with your request.
- Release '20170808.12' already exists for this project. Please use a different version, or look at using a mask to auto-increment the number.
Error from Octopus server (HTTP 400 BadRequest)
Could anyone please help me on it....
Thanks in advance !!
You are attempting to a create an Octopus Deploy Release with a name which already exists.
You could adjust your version strategy through AssemblyInfo.cs or adjust Octopus Deploy to not use package names for Releases for under Octopus -> Project -> Settings
Please check if the Release '20170808.12' already exists.
According to the description in this article, it should be an Octopus Deploy issue.
Which version of Octopus Deploy do you use? If you are using the old version, just trying update to the latest version.
In addition, you can try to use below Create release options to check if that works:
--ignoreexisting If a release with the version number already
exists, ignore it
--force [Optional] If a project is configured to skip
packages with already-installed versions,
override this setting to force re-deployment
(flag, default false).
Also try to create a release with a specified release number:
octo create-release --project HelloWorld --version 1.0.3 --server http://octopus/ --apiKey API-ABCDEF123456
See creating-releases for more information.
Related
can some one explain some steps how to upgrade Jenkins manually in production where server doesn't have any internet. what precautions do we need to take for production env before upgrading. How to manage plugins upgrade too if there is no internet
thanks....
So there are multiple options. Blue-Green, Regular Upgrade, Advance Test Upgrade
Blue-Green - Spin up another instance of Jenkins for the desired version. Copy plugins, jobs directories from PROD to new Instance of Jenkins. Verify the setup is working as expected. Apply any patches specific to version if required. E.G: Upgrade incompatible plugins specific to new Jenkins version. Test all types of Jobs. Finally Make the newly installed instance as PROD and make the existing as passive. You can repeat the same exercise in future and the passive becomes active in future. Infact you can put a Apache Reverse proxy infront of both instances, and make your Apache point to the desired instance for PROD.
Regular Upgrade - Inform all required and impacted parties. Take an approval for the downtime. Take the backup of you JENKINS_HOME. Make a note of Plugins that are incompatible in newer version of Jenkins. Upgrade to new version. Replace the incompatible plugins with supported version and finally test the jobs. Worst case if you are running out of time rollback to backup version.
Advance Test Upgrade - Copy the Jenkins_HOME. Install Jenkins new version on some other machine. Copy the jobs,workspace, plugins and config.xml. Verify the new instance is working. Make a note of things that you followed for the upgrade. Next take an approval for Downtime of PROD jenkins. Upgrade Jenkins based on the above steps.
Please comment if you need additional details specific to any of the above 3 options
I used NuGet to add CastleWindsor to a project. Eveything works ok.
When I check it into tfs, I get the following message.
Unable to find version '3.3.3' of package 'Castle.Core'.
Any idea how I can get the build server to get the new version of Castle.Core?
First just as Dave commented, please check if you have add the nuget install task in your build definition and before your build task.
Also make sure you are using the right version of Nuget. For example, if you already use V3.0 and the config file are still point to V2.0. You will get this error.
Moreover, double check if the packages can be restored successfully on you dev PC and build agent manually, you can also compare the nuget.config file on your TFS server and dev PCs to see if there is any difference between them. The nuget.config file locates at "%APPDATA%\NuGet\NuGet.Config".
TFS2012 does not restore the nuget packages automatically, you need to add a build step to call the nuget command to restore the nuget packages. Refer to this link for details: Package Restore with Team Foundation Build.
With TFS 2013 and later, packages are automatically restored by
default during build, provided that you're using a Team Build Template
for Team Foundation Server 2013 or later.
If you're using a previous version of build templates (such as in a
project that's been migrated from earlier versions of TFS), you'll
need to also migrate those build templates to TFS 2013. This
essentially means recreating the custom parts of the Build Templates
using the appropriate template for your source control (TFVC or Git).
For earlier version of TFS, you can simply include a build step to
invoke command-line restore as described earlier.
AEM muti-module project has pom.xml at each module level. Version can we changed at that level, new build shows the artifacts with updated version.
With versions, there would be a new AEM Package created for each version. We would want to uninstall/delete the old package before installing new version.
Question is, how can we handle the uninstallation/deletion part of old package (new package to be installed is of different version) in CI-CD job? We could think of following solutions
Query the list of packages to get the version and use that to uninstall.
Pass version as parameter to Jenkins Job in "Build with Parameters". But automatic build trigger on code check-in could have issue.
Has anyone faced similar situation? Please share if there is best practice which is followed for AEM CI-CD jobs for handling different release versions.
Querying the list of packages is your best option I think. You can collect any previous version of your package then, no matter when you deployed that specific package to that server the last time.
An alternative option might be to delete the package immediately after installing it, but I fear there might be lots of problems waiting for you then:
Some packages need a restart, you may not delete the package to early, ...
As I said, I would go for the querying solution.
I am attempting to fully automate the deployment of a simple assembly onto two application servers (which have the Tentacle services installed), and I'm running into a few challenges.
What I have achieved:
I can create a NuGet package with /p:RunOctoPack=true.
I can manually upload (publish?) the package to my built-in feed on the Octopus Deploy server.
I can deploy the packages to both my application servers using the Octopus Deploy portal.
I can infer from the post (OctopusPublishPackageToHttp in TFS Service) that I should be able simply put all of the following on the Process/Build/Advanced/MSBuild Arguments box
/p:RunOctoPack=true
/p:OctopusPublishPackageToHttp=http://octoserver:8081/nuget/packages
/p:OctopusPublishApiKey=API-MYKEY.
However my builds are returning the error
Exception Message: Access to the path 'C:\Builds\1\Experiments\CIBuildDef\bin\ConsoleTibcoMefClient1.1.0.0.0.nupkg' is denied.
(type UnauthorizedAccessException)
With this assembly (a simple .NET Class Library). The builds are all being dropped into the same path (C:\Builds\1\Experiments\CIBuildDef\bin). I'm accustomed to a new folder being created by the build every time. I must be missing something in the build definition settings. Am I getting this error because I'm not changing the version number of the package yet? I cannot seem to delete the nupkg that was originally dropped in the Builds directory, even after deleting it from the feed.
How do put my NuGet package onto the feed with TFS?
How do run my Octopus Deploy steps from TFS?
Am I asking the right questions?
Thanks for any input you can provide.
Could you ping your octopus server from tfs build server? And could you telnet to 8081 port from your tfs build server? If you could, you should rebuild the project not build for the same repository. If the new nuget version is not higher than 1.0.0.0 octopack could fail. You must increment the nuget version from your tfs build template. The following commands must be work for you. This commands are for msdeploy deployment with powershell. If you want to use msdeploy you must install it to tentacles. I am using it for web project deployment.
Command line arguments:
/t:Rebuild /p:AutoParameterizationWebConfigConnectionStrings=False
/p:DebugSymbols=false /p:DebugType=None /p:IsAutoBuild=True
/p:CreatePackageOnPublish=true /p:Configuration=Release;DeployOnBuild=True;PackageLocation=".\obj\Release\Myproject.zip";PackageAsSingleFile=True /p:RunOctoPack=true
/p:OctoPackPackageVersion=%VERSION%-dev
/p:OctoPackPublishPackageToHttp=http://octopus.yourdomain.com/nuget/packages /p:OctoPackPublishApiKey=API-xxxxxxxxxxxxx
I've been reading and experimenting for days. I bought the latest "Inside the Microsoft Build Engine - Using MSBUild and Team Foundation Build". I've been trying to figure things out by looking at the build targets.
I was quickly able to get a package to be built on the build server, but I want to be able to specify the installation folder, so it doesn't go into wwwroot. I read that I would have to switch the project over from using cassini to the local IIS server. Went through all of that.
The args I'm passing to msbuild through the definition:
/p:DeployOnBuild=true /p:DeployTarget=Package /p:MSDeployPublishMethod=InProc /p:CreatePackageOnPublish=True /p:MsDeployServiceUrl=localhost
I've got SO MANY questions, but I'll start simply. If anyone can provide guidance I'd be super thankful.
If the named application doesn't exist on the build server (which it shouldn't!) the package creation fails. If I add a shell app named accordingly the package is built.
Even if I hack my way past #1 when I try to deploy using Web.deploy.cmd, it fails:
Error: Using a 64-bit source and a 32-bit destination with provider appHostConfig is not supported.
Note that the build server is 64-bit and THIS target server (development) is 32-bit. I have the build configuration building against "any cpu". Oh, and I'm invoking the deployment FROM the 32-bit machine, so there's only the 32-bit msdeploy.exe available.
In the appropriate BuildDefinition under "Process", expand the "Advanced" section and set the value of "MSBuild Arguments" to "/p:DeployOnBuild=True".
That will make your WebDeploy Package built according to your settings in the project properties.
I write 2 articles about how to create Web Package and auto deploy it to a Web Server, I think it maybe useful for you.
Auto Deploy your Website for QA with Team Build click here
How to run remote deploy with MS Deploy? click here