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
Related
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.
Are there more examples of custom build JSON payloads beyond that available at https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API? Or perhaps more in-depth documentation on the “application/vnd.org.jfrog.build.BuildsByName+json” payload?
We have a build that produces both JAR/IVY and RPM files (and some other file types that Artifactory doesn’t really know the content of). Today, we publish those into a generic repository to keep everything together.
What would be ideal is to be able to create my own custom build using the REST API, composed of the JAR files + RPM files, so I can do licensing searches across them.
In the given example, the artifacts composed in the build are referenced by ID/name/hash for reference.
The problem with the current Jenkins/Artifactory/Gradle plugin that we use is that our build is separated amongst many smaller builds, but ultimately, are released as one. This makes making a full report somewhat difficult, and doesn’t have any way for us to easily do license checks including RPM files. We want to be able to publish one build, which contains everything we know in the build.
The current setup also has us uploading our JARs into a Maven repository, which adds time to the builds, given we are also publishing the same content into the Generic repository alongside the RPMS and other content.
Thanks!
The build info JSON is fully documented in the README of this
repository: https://github.com/JFrogDev/build-info
Which is also the repository the holds the code of the build info
engine used by the various JFrog CI/Build plugins. You can definitely
create your own BI JSON, and, if you're going to use Java to do that,
you should check out this project that demonstrates the usage of the
various build info Java APIs:
https://github.com/JFrogDev/project-examples/tree/master/build-info-java-example
Another option you may want to look into is the JFrog CLI, which
recently brought support for associating artifact
deployment/resolution with a build object and deploying it to
Artifactory. This method is completely agnostic to the file types
your build produces or the build tool you are using. Have a look at
the official documentation here:
https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory#CLIforJFrogArtifactory-BuildIntegration
Lastly, if you are using Jenkins, the Jenkins Artifactory Plugin now
has Pipeline APIs that will allow you to collect artifacts and build
information programmatically, and even concatenate multiple build info
objects to deploy them as a single build entity to Artifactory,
which is pretty wicked.
Have a read about this here:
https://wiki.jenkins-ci.org/display/JENKINS/Artifactory+-+Working+With+the+Pipeline+Jenkins+Plugin
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.
I'm using the Subversive plugin for Eclipse/Flex and I can commit the files correctly, but I have to rebuild Data/Services each time and reconfigure return types for each, etc. Does Subversion not provide a way to check/in out Data/Services or must these be rebuilt each time?
If I understand your comment to your question correctly, then it seems to me that it's not a problem of Subversion/Subversive, but a problem of Flash Builder's code generator which is generating/overriding your customized return types.
Maybe there are some Flex project settings files that are not committed. That would explain why you need to rebuild Data/Services each time you open the project.
By the way, if you do commit the project settings files, make sure all the paths are relative paths, so that the project settings can be shared among several developers.
You might find value in this Adobe devnet article about Flex project settings
My partner and I had different local names for the project we were working on so we had conflicts with the settings file.
I need to define a model for newly created projects in Aptana.
Basically, I want, anytime, when I create a new project, it adds some defined directories/files (not existing files, but new ones) to this project.
I'm not even sure it's possible.
Aptana doesn't appear to support that.
Maybe you can just create a small external sript to do it for you? Not the ideal solution, but better then none.
This might be a longshot, but it is worth mentioning. Since Aptana is based on Eclipse, you might be able to see how Eclipse would handle custom project templates. It appears that the easiest way to go about this is to actually create an Eclipse plugin that has a Template Wizard. IBM has a nice guide on how to use PDE to create a Custom Template. I am not sure if you will be able use PDE from within Aptana (you might be able to), otherwise, you might need to download a stock version of Eclipse, create the Plugin, then install it in Aptana.
Aptana is based on eclipse, so you could use a combination of Maven Archetypes and the Maven eclipse plugin to achieve this really easily.
Download and install maven
Create a basic maven project using the quickstart archetype, Archetypes are project templates used to rubber stamp new project structures. The quickstart is a very basic project template
mvn archetype:generate
generate the eclipse project files using the eclipse plugin. This will create the standard
mvn eclipse:eclipse
tweak the pom until and re-run step 3 until you're satisfied with the layout etc. You'll no doubt have to add configuration the eclipse plugin to add the correct build spec and project nature. If you open an existing .project file it will contain the values you need. you can see here how to add them.
once the project is set up to your liking you can create your own archetype out of it and use this to rubber stamp new projects in the future.
mvn:archetype:create-from-project
now you can run the generate again and can select your archetype from the list. If its not there, you may need to run this first to update the list of archetypes
mvn archetype:crawl
Open Source your archetype for others to use ;)
It's very simple in Studio 3. Try the following: http://wiki.appcelerator.org/display/tis/Creating+a+new+template#Creatinganewtemplate-Creatinganewprojecttemplate
Basically you create a .zip file of the project content, and then write a few lines of Ruby code to reference it.
Aptana uses (as I'm sure you know) its own 'new rails' project that gives you a variety of options.
I don't think it's beyond Will (the RadRails maintainer) to add a simple text field to that Wizard that would allow you to enter a command-line option parameter. He's always been very responsive with my previous bug and feature requests.
If you want to give that a try, and that works, then I would HIGHLY and STRONGLY recommend that you look into one of the new Rails features 'templates' in which you could make a generic template, then call it through the new input box. We use templates at my current job and they save us about 4 hours of work on each project. They are very easy to use...def...definitely.
If you can't wait for the input box, then you could always write the template then call it from within the command line (see
http://m.onkey.org/2008/12/4/rails-templates
for info about templates)
Unless RadRails three is light-years ahead of the latest release, though, you'll be missing out on a lot of very handy advantages of using a more community-supported solution such as VIM or TextMate. (I switched to VIM from RadRails about 4 months ago and have never looked back).
Eclipse has a Plugin Development Environment. If I'm not mistaken, you can also create project templates with it. Please try: http://www.ibm.com/developerworks/library/os-eclipse-pde/