How do I delete all packages with a given version in Sonatype Nexus 3 - nexus

I don't want to have to select each package one by one and delete the version, this is incredibly tedious (there could be a 100 packages, but even 20 is painful using the UI).
What is the easiest way to achieve this?
I wish I could just do this from the Advanced Search from Browse, but there's no way I can see to multi-select and Delete isn't an option until I go to the folder tree view.
A Task would be nice, but all the tasks I see don't have filtering

You can achieve this by using the Cleanup Policies Feature.
Here's how:
Create a cleanup policy:
Goto Administration->Repository->Cleanup Policies and click:
- Create Cleanup Policy
In cleanup criteria deselect all and then select:
- Asset Name Matcher
In the textfield add a regex to suit your needs.
For example to clear the repo completely:
.*
For example to clear the repo of maven package "cert-cvc" version 1.4.9:
.*cert-cvc-1.4.9.*
Attach the cleanup policy to your repository
Edit your Repository and add the cleanup policy you just created.
Goto Administration->System->Tasks
- Select the Cleanup service
- Click Run
It will cleanup the repository immediately.
Once complete don't forget to remove the cleanup policy if you don't want it to kick in again at the next scheduled run.

Related

Sonatype Nexus cleanup policy doesnt clean

I'v made the Cleanup Policy in Sonatype Nexus 3.18.1-01 for the past x days, then made a task Cleanup service Admin - Cleanup repositories using their associated policies, ran it, and all is good and fine - the old artefact versions are gone from UI, but on the machine I still have the same xx GB space taken - any thoughts on that ?
You need to run an 'Admin - Compact blob store' task. Any clean up (task, or individual deletions) done via NXRM3 is soft deleted in case it's removed the wrong thing, you can restore. Compact blob store finishes the job (removing all soft deleted items). Of course, it's worth noting that after you do this your stuff is gone for good (likely what you want, but can be worth caution on your first impl of cleanup policies to make sure you didn't delete too much, etc.).
Reference link

Automatic backup/restore at start server

I would like an automatic backup of a schema to a file on every load and at a restart of icCube an automatic restore of the last backup. And of course an automatic cleanup of those files. This way we would have a lot less downtime on a restart.
It looks like icCube has that with backup and/or offline data, but I can't get that working like I described above. Is what I want possible and how?
You can activate the backup in the schema file (Advanced Properties).
Now everytime you load the schema it will create a backup.
And if you set "Load On Startup" as well, icCube is going to load the last backup available.
There is no automatic cleanup: for that purpose you can use the Rest API available in the latest icCube. Otherwise, you can cleanup yourself the backup files created in the ~/icCube-data/backup folder.
Hope that helps.

How to configure iccube maximum count of schema-backups?

Is this possible in the section backupConfiguration inside icCube.xml?
As an alternative, is it possible to create some sort of Schedulertask to delete old backups? Or is there a possibility to trigger this via the XMLA-interface?
You can configure icCube to keep the last backup (see backupHistory in inCube.xml). Otherwise, you can configure a cron task to cleanup the backup directory according to your own requirements.

Phabricator: how to fire herald rule on acceptance of of Audit?

Is there a way to create herald rule to fire once a audit has been marked as accepted?
Basically what I am trying to do is to trigger build job once a commit has been audited and marked as accepted
cheers
There is no built in functionality for reacting to commit audits. Phabricator has developed a "pre-commit" code review system that would accomplish this by putting the review process before the commit. Then, once it is reviewed it can then be "landed"/committed and then the build can kick off.
For more information on their pre-commit review, please read their "Reviews vs. Audit" doc.
There is no herald rule for accepted audits. Like CEPA already said, you need to to a pre commit review. You can create a diff without using the cli arcanist.
Do your stuff in the repo
Stage and commit changes
Create a diff for example with: git diff origin/master > diff
Create a new diff in phabricator with: Differential > Create Diff and paste the file there. If you can't find the URI just use the link https:///differential/diff/create/
Now you could create herald rules to react on new diffs and add blocking reviewers for example.
You could also protect commiting to master.
Keep in mind: This isn't the recommended way to work with differentials.

Phabricator restrict git push

I want my team including myself to review commits of each other. None of commits should be pushed including mine into repo until it's not audited by other team member. I kind of lost in phabricator documentation, so i'm asking here, is there any way to setup that kind of workflow?
You can only restrict pushes to repositories hosted by Phabricator. If your repository is hosted elsewhere (like GitHub), Phabricator obviously can't prevent users from pushing to it.
To restrict pushes, create a new Herald rule (in the Herald application), like this:
Create a new "Commit Hook: Commit Content" rule.
Select "Global" as the rule type.
Then configure the rule like this:
When [all of] these conditions are met:
[Accepted Differential revision][does not exist]
Take these actions every time this rule matches:
[Block change with message][Review is required for all changes.]
You may want to use additional conditions like this, to run the rule only in certain repositories:
[Repository][is any of][ ... list of review-requied repositories ... ]
Or a condition like this, to let users bypass the rule by writing some string like "#bypass-review" in a message in an emergency:
[Body][does not contain][#bypass-review]
If you add a bypass like this, you can mention it in the rejection message.
It seems that you want a Pre-Commit Code Review. We set this up by doing the following (we use Git repos. If you use some other type, these steps may be different):
Setup a Herald rule
New rule for: Commit Hook: Commit Content
If you only want one repo, you can use Rule Type: Object, however, we used Global
For the conditions: we selected Accepted Differential revision and does not exist
Action: Block Change with message For the message, we refer them to an article that walks them through using Arcanist
Each project will need a .arcconfig with at least this line:
{
"phabricator.uri": "http://your.phabricator.url"
}
Day-day developers are going to have to use arcanist.
Developer creates a local branch.
Changes and commits code to the local branch.
When finished, run arc diff [base_branch_name]
This will create a Differential revision that will allow another developer to code review.
If changes are needed, the developer checks out his local branch, makes changes, makes commits, and re-runs arc diff [base_branch_name] to update the diff.
After all revisions are done, run arc land [local_branch_name] --onto [base_branch_name]
I hope this helps. Also, Phabricator developers hangout in freenode.net IRC channel called #phabricator. Come join the community; they have always been very helpful for me.

Resources