There is API command to promote artifacts from one repository to another but this means that path to artifacts will be replicated. Is there a simple way to change a path to files in a new directory? Or I need to use copy/move for this ?
The promote option is used to actually promote artifacts from one state to another. For example from a snapshot state to staging and from staging to release. If all you want is to move the artifacts from one folder to another then yes, use the move/copy REST API (Or UI, up to you).
Related
I have a project that depends on another project, how can I configure Jenkins to use the reference of that project in the workspace.
For an example, project B depends on a certain set of classes from project A. Jenkins should be aware to build project A first and then B.
The trigger point is when a commit is pushed to the master of project B.
If a project depends upon another project, it is typically part of the same solution and always part of the same source tree. This means the slave will probably have the source already - or if it doesn't, the step that obtains the source needs the workspace mapping updated to not exclude it.
Also, when a project depends upon another project, the reference information includes the path to the referenced project. In the absence of solution file, this is used directly to build the other project with the same configuration (as in Debug/Release).
It's usually best to use a solution file instead of building projects directly as that ensures platform/configuration customisation is honoured as well as determining the correct build order of the projects.
So I got it sorted out. Since my project was based on project reference, the path had to be the same.
Naming the Jenkins project folder same as the dependent project name I referenced solved the issue.
I was under the impression that another workspace can't access another workspace. But it seems to be Jenkins handles it internally when building projects.
Is there a way to alter a build using the CLI after having published it?
UseCase: A deployer (be it automated or manual) wants to add additional files (e.g. Testresult-logs) to an already published build (because they need very long to be created but the artifacts of the fresh build should be published asap).
When I redo a jfrog rt bp over and over again I get "new" builds with the same description (same buildnumer etc.) instead of overwriting/extending existing build.
Appreciating any hint :-)
The main idea of the buildinfo in Artifactory is that they are immutable, which means they cannot be modified post publish. This is to make sure the integrity of them.
In your case, a possible way to achieve this may be:
When publishing the artifacts themselves, you might want to not publish the buildinfo.
You can collect buildinfo through your build cycle, and publish everything as a single buildinfo object after all the tests.
I'm using Artifactory Pro with custom repository layouts. I promote my build and move all artifacts to my production repo. But I need to add an article number in this path, so the guys can reference it to their ERP System.
I tried some stuff here, with promoting and moving artifacts to match their needs. It works, but its not nice.
So I added my custom layouts:
For my developement repo:
[org]/[module] ...etc...
For my production repo:
[Articlenr<.*>]/[org]/[module] ...etc...
When I promote my build, my files are stored like this
[Articlenr]/customer/linux ...etc...
The article number is just filled up with [Articlenr], but I'm not able to replace it by the real one, without moving the complete directory.
Anyone here knowing, how to set the article number while promoting this build?
My builds are promoted by JFrog CLI, but using the Artifactory REST API is an option, too.
Thanks a lot!
Currently, there's no way to use the promote command to promote a build with a target path as an argument.
If you are not set on using promotion, consider using the CLI's COPY or MOVE commands, where you can use placeholders in the target path to increment your Articlenr.
The downside of using cp/mv instead of bpr would be the fact that your build will not be flagged as promoted in artifactory (build-info), which may be a problem in some cases (like if you are using build retention for example).
It is not an ideal solution, but it might suffice for what you are trying to accomplish.
HTH, Or
If you have a project that builds one project before building the next, but the next needs to know the 'path' of the first build, is it possible to get this?
For example:
Project A has Build Configuration A and Build Configuration B.
Build Configuration B has a dependency on Build Configuration A. From without the Build Configuration B it will need access to the path of Build Configuration A. Is there are a way to obtain this?
Most simple approach would be to define a custom checkout directory in the A and use the same hard-coded value in B.
If you use TeamCity snapshot or artifact dependencies, you can use %dep.btXXX.teamcity.build.checkoutDir% to get checkout directory of the dependency build. However, this will not work in 6.5.0-6.5.5 TeamCity versions, see details and workaround in the issue TW-18715.
However, you should really avoid accessing checkout directory of one build from another. If you need sources of A, you can checkout them in B; if you output of the A's build, then publishing the output as build's artifacts and then using TeamCity artifact dependencies is the way to go. In both cases additionally using TeamCity snapshot dependencies will ensure both builds use the same sources snapshot which is probably what you need.
If you have one agent, and only ever one agent then you could try and use the path from a previous build.
I wouldn't recommend doing this however because if you had two agents, or scaled up in the future to two agents, then it is possible your projects will be built on different agents; this would mean your dependency working directory won't be on the same machine, or it will be outdated as the latest was built elsewhere.
I assume you're after the path of the first build to get its output?
If so, the method we use to share dependencies between projects is to checkin the output from each project into our source control, then every project that requires the output simply has to check them out.
We currently have a CruiseControl.Net server that is merrily building the trunk on our svn server. I have a new requirement to build the "latest" branch as well; is there a best practice in CruiseControl to handle this? What specific changes are needed to build from the trunk and a branch at the same time?
Make a second project just like the original where the source control is pointed to the proper branch.
As far as Cruisecontrol.net is concerned, a project is a project. It doesn't care whether it's a branch or a trunk. Simply setup another project in the ccnet.config that points to where the branch is located.
To keep things organized, i like to add the version number to the name of the branch projects like this:
ProjectX <- Trunk
ProjectX-4.0 <- Historical branch for v4.0
I generally create a new working directory named branch, set up the source control to monitor the branch and pull to the new folder. I also put in an exculusion filter on the trunk build so it does not get kicked off by a check in to the branch (our branches usually reside within the trunk realm of checking for changes). I also remember to change the labels, if we label, to reflect the branch naming convention. One very helpful thing you can do is if you will only ever have one branch active simply name it branch that way once you have your configuration all set You only have to comment or uncomment those parts in the config file as needed, instead of having to upgrade it in all the places like if one time it is branch 6.1 and next time it is 6.2, it saves a lot of cut and replace and I only have to changed the project name and the label the next time we use a branch.