A repository I use regularly deletes old version of deb packages as it releases new ones, which is very annoying as it breaks our builds until we can bump the package version in our config management.
I was hoping that the Remote Repositories feature would let me create a cache that keeps packages in it even though the original repository has deleted them.
Does Artifactory Remote Repositories delete files when they are deleted from the original repository?
Thanks
The answer is NO, Artifactory will not delete the files if the remote repository deleted the files. Now there is a scenario that Artifactory will clean unused artifacts BUT only if the Admin choose to and I will explain. In the Artifactory UI --> Admin --> Remote repositories --> Repository configuration --> Advanced tab, you have a checkbox named "Unused Artifacts Cleanup Period". By default, this field is empty which means no cleanup. Unless the Admin change this field nothing should be deleted automatically by any Artifactory process.
Related
I have an instance of Artifactory OSS (latest version) running in a docker container locally.
We have a remote instance of Artifactory (non-OSS) running as well.
In my local instance, I set up a remote repository of package type Ivy pointing to each of the repositories we have set up in our remote non-OSS instance.
Once I have created a remote repository configuration, I can view each remote repository I created and its artifacts being served under the Application --> Artifactory --> Artifacts page HOWEVER under the Administration --> Repositories --> Repositories page where I am expecting to be able to make changes to the configurations (I have logged in as Admin with administrator privileges btw), none of the repositories I set up are actually visible here! I only see a 0 Repositories count and a No remote repositories message where I am expecting to see a list.
When I do Ivy resolves against my local (remote repository) it works as expected, so they're definitely working... just not showing up for administration.
I have tried rolling back to earlier versions of Artifactory OSS but that hasn't changed anything.
I can tediously work around this with a combination of the REST API and the UI but I REALLY JUST want to be able to administer the configurations within the web app... Am I just being dumb about something or is there a known issue regarding this? I have searched around and I haven't found an answer to this issue, so any help or direction would be greatly appreciated! Thanks!
I was able to reproduce it on my end on as well on version 7.19.1, seems this issue happens when working with Ivy on Artifactory OSS.
I have opened a bug for this on JFrog Jira.
How to disable re-publish of the same version of the artifact in the Jfrog Artifactory?
For example Docker repository - my-docker-releases: Image myapp:1.0.0 is published in the repository. It should not be possible for anyone to publish another image with the same tag myapp:1.0.0 in the same repository.
How to achieve this feature by repository settings of Artifactory?
As mentioned in their documentation:
https://www.jfrog.com/confluence/display/RTF6X/Managing+Permissions
Preventing Overwriting Deployments
You can prevent a user or group from overwriting a deployed release or unique snapshot by not granting the Delete permission. Non-unique snapshots can always be overwritten (provided the Deploy permission is granted).
After a fresh install of Artifactory, I've noticed a huge number of files I don't need in artifactory/libs-release dir. From Artifact Repository Browser, these artifacts are listed under the libs-release folder cf image below
Is it possible to install Artifactory without all these artifacts ?
Can I safely remove them ?
Those are not stored in your Artifactory instance. The repository libs-release is a virtual repository that contains both local and remote repositories. This will show an aggregate view of three things:
The items in the Artifactory local repositories (which are stored in your instance)
The items cached in your Artifactory remote repositories (which are stored in your instance)
The items available in the Artifactory remote repositories (but not stored in your instance)
In your case, the items you are seeing fall under #3 and are not actually stored in your Artifactory instance, as such you cannot delete them.
I'm setting up a new atrifactory installation for the first time in my life. Downloaded the tar and extraceted it ok. Got some firewall rules in place to allow https to jcenter.bintray.com. After an initial refresh I see loads of artifacts in the com tree that must come from jcenter, so all seems fine, but when I preform simple maven tasks like mvn help:active-profiles I only get warnings and errors that indicate that none of the relevant stuff is available from my artifactory.
I have accessed the firewall logs and I found no outgoing traffic from my artifactory server to anything that's not permitted. What have I missed? My artifactory is OSS version 7.5.7 rev 705070900.
Artifactory remote repositories are not working as a mirror or the external repository they are pointing at.
Remote Artifactory repositories are proxying the external repository, which means that you have to actively request for artifacts. When requesting for an artifact, Artifactory will request it from the external repository and cache it inside Artifactory. Farther requests for a cached artifact will be served from Artifactory without the need to go out to the external repository.
The list of artifacts we are seeing, are ones which are available in the external repository. This is a feature is called remote browsing and available for some of the package types supported by Artifactory.
I found the issue, sort of. For reasons I now understand I have plugin repositories. I added the true source for the plugins to my list of plugin repositories, and that solved the issue for me.
I'm using artifactory (OSS 5.1.3) as a general build dependency cache. I've noticed that in the repository browser, for each remote repository there is a second entry with -cache appended. ex: "jcenter" and "jcenter-cache".
The -cache entries are created automatically. After I added a generic "gradle-distributions" repository to cache https://services.gradle.org/distributions/, I found that I had a "gradle-distributions-cache" repository in the tree as well. The -cache has a different icon, but it's not listed under any of the different repository types in the admin area, and it's not selectable as a source when defining a virtual repository.
Once I've downloaded an artifact once, I can access it through either the main repository name or the -cache name. But if I haven't downloaded something yet, then the -cache name will 404 (while the main name will go out and fetch it).
I couldn't find anything in the settings or documentation to explain the -cache repository. It's useful as a way of seeing what artifactory has already downloaded from the remote, but is there another explanation for it that I'm not apprehending? Is there a reason to point to one name or another in direct urls? (ex: gradle wrapper --gradle-version 3.4.1 --gradle-distribution-url http://localhost:8081/artifactory/gradle-distributions/gradle-3.4.1-bin.zip) This is mainly a curiosity question.
The "-cahce" repositories are mentioned in the remote repositories configuration section.
The idea is that in some cases it is useful to directly access artifacts that are already stored in the cache (for example to avoid remote update checks).