My organisation currently uses the OSS version of Artifactory which means we cannot use the artifactorycleanup plugin as this is designed for Pro only. Does anyone out there know of any alternatives to this plugin that do the same thing and also have an option of doing a dry run before deleting anything?
Happy to take a look at anything from jfrog or a 3rd party if needs be.
You can move to JFrog Platform Cloud, starting with the free plan, which gives you what you have with Artifactory OSS and much more, including JFrog Pipelines.
You can use Pipelines together with the JFrog CLI to create your cleanup tasks -
Use AQL to find the artifacts to cleanup
Use the JFrog CLI to execute your queries and operations on Artifactory
(e.g. see deleting files - by query, supports also dry-run)
Use an IncomingWebhook resource to trigger the pipeline via HTTP POST
Use a CronTrigger resource to trigger the pipeline on a time schedule
Trigger the cleanup pipeline manually with custom variables, e.g. DRY_RUN=true
But it is up to you to implement it all in your pipeline.
P.S.
For reference, the mentioned user plugin is Artifactory Artifact Cleanup User Plugin
See blog post: Artifactory Cleanup Best Practices
I believe OSS solution supports AQL queries, right?
If it does - you can use the tool https://github.com/devopshq/artifactory-cleanup (which we posted as open source project)
The recent release support YAML configuration, so you can define cleanup policies for Artifactory like this:
# artifactory-cleanup.yaml
artifactory-cleanup:
server: https://repo.example.com/artifactory
# $VAR is auto populated from environment variables
user: $ARTIFACTORY_USERNAME
password: $ARTIFACTORY_PASSWORD
policies:
- name: Remove all files from repo-name-here older then 7 days
rules:
- rule: Repo
name: "reponame"
- rule: DeleteOlderThan
days: 7
Related
I want to upgrade my Artifactory Pro setup. I planned to clone the database, create a similar instance, and set up Artifactory Pro with the current production version, then upgrade the test instance to the latest version and make some tests(Upload artifacts, SAML, etc). If all tests will be Okay, upgrade the version of Artifactory Pro on the production instance.
How to be sure that I am making it legally? Do I need to request a Trial License? Or I can use my "production" key for a while?
Thanks in advance.
I recommend reaching out to JFrog as having a license running on two Artifactory instances simultaneously is against the EULA (as it probably is to request a trial every time you need to do something not in prod). If it is production though you should consider having some sort of DR/test/dev/staging/qa setup, artifact availability is important
I have an artifactory server, with a bunch of remote repositories.
We are planning to upgrade from 5.11.0 to 5.11.6 to take advantage of a security patch in that version.
Questions are:
do all repositories need to be on exactly the same version?
is there anything else i need to think about when upgrading multiple connected repositories (there is nothing specific about this in the manual)
do i need to do a system-level export just on the primary server? or should i be doing it on all of the remote repository servers
Lastly, our repositories are huge... a full System Export to backup will take too long...
is it enough to just take the config files/dirs
do i get just the config files/dirs by hitting "Exclude Content"
If you have an Artifactory instance that points to other Artifactory instances via smart remote repositories, then you will not have to upgrade all of the instances as they will be able to communicate with each other even if they are not on the same version. With that said, it is always recommended to use the latest version of Artifactory (for all of your instances) in order to enjoy all the latest features and bug fixes and best compatibility between instances. You may find further information about the upgrade process in this wiki page.
In addition, it is also always recommended to keep backups of your Artifactory instance, especially when attempting an upgrade. You may use the built-in backup mechanism or you may manually backup your filestore (by default located in $ARTIFACTORY_HOME/data/filestore) and take DataBase snapshots.
What do you mean by
do all repositories need to be on exactly the same version?
Are you asking about Artifactory instances? Artifactory HA nodes?
Regarding the full system export:
https://www.jfrog.com/confluence/display/RTF/Managing+Backups
https://jfrog.com/knowledge-base/how-should-we-backup-our-data-when-we-have-1tb-of-files/
For more info, you might want to contact JFrog's support.
We're making use of a remote repository and are storing artifacts locally. However, we are running into a problem because of the fact the remote repository regularly rebuilds all artifacts that it hosts. In our current state, we update metadata (e.x. repodata/repomd.xml), but artifacts are not updated.
We have to continually clear our local remote-repository-cache out in order to allow it to download the rebuilt artifacts.
Is there any way we can configure artifactory to allow it to recache new artifacts as well as the new artifact metadata?
In our current state, the error we regularly run into is
https://artifactory/artifactory/remote-repo/some/path/package.rpm:
[Errno -1] Package does not match intended download.
Suggestion: run yum --enablerepo=artifactory-newrelic_infra-agent clean metadata
Unfortunately, there is no good answer to that. Artifacts under a version should be immutable; it's dependency management 101.
I'd put as much effort as possible to convince the team producing the artifacts to stop overriding versions. It's true that it might be sometimes cumbersome to change versions of dependencies in metadata, but there are ways around it (like resolving the latest patch during development, as supported in the semver spec), and in any way, that's not a good excuse.
If that's not possible, I'd look into enabling direct repository-to-client streaming (i.e. disabling artifact caching) to prevent the problem of stale artifacts.
Another solution might be cleaning up the cache using a user plugin or a script using JFrog CLI once you learn about newer artifacts being published in the remote repository.
I'm wondering how other Artifactory Admins do that so here's my question:
We're starting to use Artifactory to manage our artifacts. Internal as well as external artifacts. The external artifacts are all available in an internal repository. This is so because of a conversion from a file based repository to Artifactory.
Now this is starting to cause issues and I'm wondering how others are managing the external dependencies? As an Artifactory Administrator I want to be sure that my developers only use artifacts which have the correct license so I don't want to have a "feel free to download everything from the internet" culture.
I want to provide some sort of a "whitelisted and approved" set of external Artifacts.
Is this possible using Artifactory OSS or do we manually download the artifacts from a remote repository and deploy it to our local repository?
Thank you in advance!
this can be done with writing a user plugin but it will require a PRO version of Artifactory. You can see here examples to a governance control plugin that was written in the past.
With OSS version you can't reject downloads of users based on license.
Hope that answer your question.
Usual story, new to artificatory and looking for a jump start.
Can anyone point me at a decent how-to post for using Artifactory (free version) with Jenkins in a deployment pipeline?
I figure I'm likely to want to:
setup several repos for dev thru production (any standards for this?)
have jenkins publish artifacts to the first repo using the artifactory plugin - limiting the amount of builds kept in artifactory.
promote builds from one repo to next as release to next environment - again deleting older builds
I just need a good guide/example to get started...
Did you check the User Guide? It covers all your questions perfectly well. Here are:
Creating repositories (re the standards - the preconfigured repos reflect the standards).
Working with Jenkins
Jenkins Release Management
Keep in mind that all the promotion functionality is available in Pro version only. That includes both simple move operation (not recommended for promotion pipeplines) and extremely powerful release management, based on build integration with Jenkins Artifactory plugin.