Is it possible to output/deploy a .nupkg file that is downloaded from a teamcity server. Currently it extracts the .nupkg that is downloaded from the teamcity server. The file that is extracted into the Applications folder is stored in the Octopus\Applications.Tentacle\Packages folder but it has an internal name which is not very user friendly.
My only option at this point is to run a custom powershell script that copies the file and renames it, but this seems like a rather crude hack.
Use the system variables to access the internal values set within Octopus to find what the name and path of the nuget package you want. This list of system variables on the Octopus Deploy site is where'd I'd start to look first. I don't know how complete the list is but there are a consider number of variables you have access to in Octopus Deploy.
Related
I'm using Artifactory 7.10.6.
go version 1.15.6 (also tested with older versions)
I am not using the jfrog cli, and would prefer not to.
I'm trying to sort out what I'm doing wrong here. I've used Artifactory to pull down content from remote connections to be stored on an local repository for other package types, but this doesn't seem to be working for me fully with GO. Disclaimer, I'm not super versed in GO...
Here is what I have setup.
a local go repo called "go-ext-release"
a remote of gocenter called "go-gocenter"
a virtual called "go-virtual" that contains only "go-ext-release"
a virtual called "go-virtual-dev" that contains "go-virtual" followed by "go-gocenter"
The idea here of course. Run a build with my GOPROXY set to "go-virtual-dev", copy the downloaded files from go-gocenter-cache to "go-ext-release". That should get me all the files I need to reset my environment, point to GOPROXY to "go-virtual" and run a build.
My build pointing to "go-virtual-dev" works fine. Build works, content is pulled down (mostly .mod and .info).
I move that content to the local (go-ext-release) and build in a clean environment using "go-virtual" and the build fails. it says it can't access .zip files. i.e. a 404 on /github.com/gorilla/mux/#v/v1.7.4.zip
Of course when I look for that zip, it doesn't exist.
If I take the url its trying to access and change the url from the "go-virtual" path to "go-virutal-dev" and punch it into a web browser the correct zip file gets downloaded to the "go-gocenter-cache" repo (as expected).
I did this process for the 4 or 5 zip files the build needed (its a small test build), and then moved the zips from the cached location over to the "go-ext-release" repo. After that, the build works using the "go-virtual" repository (i.e. the repo that just sees into our local repo).
So what am I doing wrong here? My expectation was that the initial build would have pulled all the files , zips included, to the cache as well. I know the build pulled them down because I can see them in my GOCACHE folder. Its as though it isn't using my GOPROXY to pull the zips down
Any help would be appreciated.
is there any commanline switch to force go to show me the exact URL it is using for pulls? I've experimented with using go get -v, but it doesn't give the full url.
Can you try running the build against go-virtual-dev using an empty GOPATH. I believe the Go client will not trigger the module zip download if you already have it locally which will not allow Artifactory to cache it from the remote repo.
BTW, Running go get -x should show you all the URLs being fetched.
My automation deployment environment I have web.war file deployment under tomcat.
Lets assume this web.war application contains mix.jar file which is under /lib directory of web.war archive file.
(mix.jar releases giving by different DEV team and they don't responsible for giving web.war and the organization practice is putting the latest mix.jar file into the web.war archive file manually )
Can anyone help me to automate this process from CHEF recipe ?
Basically what I need during the chef deployment is, putting the mix.jar file into the web.war/lib directory under tomcat container.
Our current practice is open the web.war file from Winrar and put the mix.jar file into it and redeploy it into tomcat.
But I want to automate this process.
Jar files are just zip files so you can probably write some code using either the zip command line tool or the RubyZip gem (I would go for the latter but depends on your comfort level with Ruby code) to do this on the fly, but please don't. Chef is really not built for this kind of task and it will be very frustrating to build the code in a robust manner. If you need it ASAP and want to build a fragile version now and fix the process afterwards that's more understandable, but otherwise probably just talk to your dev team about what this is and why you need it added to their build process. Some problems are best solved with communication rather than code.
For a .NET Developer, the Teamcity artifact paths are not very straightforward.
Per project I do, I have a folder called BuildTools and, within it, folders called Drops and Inputs (drops being the reports and outputs inputs being the config files for various command line apps).
BuildTools/Drops/NDependOut => GenericSolution/Drops/NDepend
Is this correct? BuildTools is from the root of the (custom) checkout dir, and then GenericSolution is from the root of the artifacts path (Called "Artifacts" folder).
The other problem I have is that the NDepend report has a lot of images etc in the same folder as the .html file. How would I upload this? Do I upload the entire folder (in which case, is the syntax above correct?)
In general this is right. TeamCity has an option to zip artifacts before publish. For that use the following syntax
Folder/folder/*/ => destfolder/archive.zip
Another trick is to use TeamCity service message to publish artifacts dynamically from build script.
I am trying to setup my TFS2010 Build and I want to access the files that are downloaded via the "Version control path to custom assemblies".
From what I can tell those files are downloaded to:
C:\User\<Build User>\AppData\Local\BuildAgent\<Built Agent Number>
I can directly access that folder via the above path, but it would be nice if there was an environment variable (or something I can use in the build) to access that folder indirectly.
Or... Is there a better way to get at these files? (I am putting a version file in there to be downloaded every time the build is run).
You can use %LOCALAPPDATA% environment variable. It expands to
RootDrive:\User\LoggedInUser\AppData\Local
Example: %LOCALAPPDATA%\BuildAgent
Note that %APPDATA% will expand to
RootDrive:\User\LoggedInUser\AppData\Roaming
how can I copy the artifacts from Teamcity to another server?
Thanks
The way I have done this, make things a lot easier.. Setup another configuration that pulls in, via artifact dependencies, all the files you need then run a cmd script to xcopy/copy the files to another drive on the network. You can do this using cmd script, vbs, python, shell etc..
Remember, you only need to refer to directories as if they were local as you would have your script in the same working directory
i.e cmd script :: xcopy .\"my build artifact(s)" \path\to\drive\on\my\network\"my build artifacts"
It doesn't get easier than that.
Naturally, if your artifacts are huge, then you may want to consider your more complicated option. However, TeamCity currently have a ticket pending, which you can vote on, that allows you to run multiple runners in one configuration - so you could just add your cmd script to the same configuration to save the copy time; please vote if can spare a minute:
http://youtrack.jetbrains.net/issue/TW-3660
There is a Deployer plugin, that supports deploy by fileshare/SMB, FTP, SSH and other means. The usage is basically the same as the Artifact paths.
We have used just samba, so you must enter:
target Host path: //server/drive/myfolder
Username: mydomain\myusername - in our case we had to write domain
here too
Password: ****
Domain: mydomain
and in path just select the files as in artifacts:
product/* => product.zip
and it will create file //server/drive/myfolder/product.zip
You can do it from your build script or externally.
If you are looking to get artifacts copied from a remote build agent to the primary TeamCity server, you may want to look into configuring Build Artifacts under the General Settings.
According to TeamCity's wiki entry on BuildArtifacts (http://confluence.jetbrains.com/display/TCD7/Build+Artifact) "Upon build finish, TeamCity searches for artifacts in the build's checkout directory according to the specified artifact patterns. Matching files are then uploaded ("published") to the TeamCity server, where they become available for download through the web UI or can be used in other builds using artifact dependencies."