I have installed last version of Artifactory (4.15.0) and it comes with several default folders.
My questions are:
What are those folders for?
Is it possible/safe remove them?
Artifactory comes pre-configured with a set of repositories of 3 types: local, remote and virtual.
This set of repositories allows easy onboarding to Artifactory (assuming you are using Maven/Gradle) and reflects some best practices such as using virtual repositories.
If no one is using them right now, you can safely remove them with no harm done. You will need, however to create your own set of repositories.
The only repository you should not remove is the "Trash Can" repository which is used for storing deleted artifacts for recovery purposes (you can disable it if you like to).
You can delete repositories by going to Admin > Repositories > Local (or Remote, Virutal), selecting the repository from the grid and clicking the "Delete" button.
Related
I'm currently starting with JFrog Artifactory. Up to now I have only been working with source code control systems not with binary repositories.
Can someone please tell how the versioning of files is done in Artifactory?
I have been trying to deploy a file, then change it and deploy it again.
The checksum has changed, so it's the new file. But it seems that the old version is gone.
So it looks like there are no version of files. If I want that do I have to do it in the filename?
I found versions related to packages.
But I was thinking to use it for other files as well.
Thanks for your help
Christoph
Artifactory, unlike a VCS system, is not managing a history of versions for a given path. When you deploy an artifacts over an existing artifact, it will overwrite it (you can block this by configuring the right permissions).
If you wish to manage permission for generic artifacts (ones which are not managed by a known package manager like npm, Maven etc.), there are a couple of options you can take:
Add the version as part of the artifact name, for example foo-1.0.0.zip
Add the version as part of the artifact path, for example /foo/1.0.0/foo.zip
Combine the 2 above approaches, for example /foo/1.0.0/foo-1.0.0.zip
Use an existing package management tool which is flexible enough to handle generic packages. Many people are using Maven to manage all types of packages beyond Java ones (it comes with its pros and cons)
From the Artifactory point of view there are a couple of capabilities you can leverage:
Generic repositories - aimed at managing proprietary packages which are not managed by a known package manager
Custom repository layout - can be used to define a custom layout for your generic repository and assist with tasks like automatic snapshot version cleanup
Properties - can be used to add version (and other) metadata to your artifacts which can used for searching, querying,resolution and more
Lastly, Conan is another option you should consider. Conan is a package manager intended for C and C++ packages. It is natively supported in Artifactory and can give you a more complete solution for managing your C libraries.
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
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).
If you want to use a package between two projects, what's the best way to handle it. Considering two scenarios :-
First Scenario
Git Repository with the two projects like
root folder
-- Mobile App Folder
-- Web Folder
So both projets are in the same repository
Second Scenario
Each project is in separate Git repositories and we want to share the package between those projects.
What's a good ways to handle each scenario? ( Either using the same method for both, or different methods for each scenario)
You need to be aware of how Meteor handles package scanning when confronted with meteor add package :
searching for it inside the local packages/ folder of your app.
searching for it inside every folder specified in the PACKAGE_DIRS environment variable.
searching for it on Atmosphere.
Not sure about the specific order but I'm assuming the one that makes most sense.
So your question is basically where to store the package for an optimal workflow.
Using the fist scenario, you would store your private packages inside the app root folder under packages/, you'll just have to git pull from the repo to get the latest versions of the packages. Then you would have to make sure to define correctly the PACKAGE_DIRS env variable, something like this :
export PACKAGE_DIRS=$PACKAGE_DIRS:$HOME/meteor/my-repo/packages
Using the second scenario, you would store each private package on its own git repo, then pull them into a local $HOME/meteor/packages of yours and don't forget to set PACKAGE_DIRS appropriately.
export PACKAGE_DIRS=$PACKAGE_DIRS:$HOME/meteor/packages
I would tend to go with the second scenario if there's a chance that these private packages may be reused for other projects, if you are sure they only make sense in a particular project, then storing them along in the repo is OK.
Another option would be to symlink your shared private packages into the "packages" folder of each of your apps.
So assume you have have your shared package in the folder /dev/mysharedpackage. You could create a symlink via ln -s /dev/mysharedpackage packages/mysharedpackage and then add the package via meteor add.
Here is a Meteor Cast on this topic: https://www.meteorcasts.net/ep/3
My team has is working on a git repository which contains a fully deployable Wordpress app. This was configured in this way so that it could be deployed to a AWS stack quite easily. The repository contains a caching plugin which creates two folders in the wp-content/ folder named
cache/
w3tc-config/
When devs are checking out this application they are removing the caching features for development and thus the plugin is writing these changes to the two directories it uses. Which then encourages .git to stage them for a commit.
Is there anyway we can ignore these folders on dev machines but not remove them from the repo? Also i'd be interested in hearing other solutions which might help me get round this problem even if it is a larger change.
If you check out your repository and let master follow that, then you can create a devel branch where you just add cache w3tc-config to .gitignore.
I do something similar at work where I use git-svn to work with a svn repository which "links" in another svn repository for a sub module. Git clone did not fetch that sub module, so I just copied in the content from a svn checkout, checked into a devel branch (leaving master following the svn trunk branch), and added the sub module directory to .gitignore.
This is a solution that will require specific action from each developer, and not something you can push out from the repository. But similar to git hooks, if you create a tools/do_it.sh script that does the required actions it is possible to lower the bar considerably.
You cannot have it both ways. Either the files are tracked or they are not. You cannot keep files in the repository but avoid tracking changes to them. Once they are tracked, it is up to you to not git add them. (And it is worth noting that git does not track folders ever.)
Create an archive called UnzipMeRightAfterCloning.zip that contains all the stuff you want ignored. Anyone cloning the repo needs to extract that archive, and it will add all the files/folders blocked by your .gitignore settings. (And given your current setup, you will have to untrack the files in those folders first.)
Put these in your .gitignore file. (Do not put in asterisk.)
cache/
w3tc-config/
Yes, create a local .gitignore file in the project directory.
in the file paste the following
cache/*
w3tc-config/*
Now, these files will be excluded from git, but they won't be removed from the repository.