Monorail Project: gerrit Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 183 users
Status: Submitted
Email to this user bounced
Closed: Sep 2013

Blocked on:
issue 203

issue 798

Sign in to add a comment
Delete projects through web interface
Reported by, Dec 2 2009 Back to list
Add the posibility to delete a project.
This is really important.
Comment 1 by, Dec 2 2009
Blockedon: 203
Status: Accepted
Summary: Delete projects though web interface (was: NULL)
Deleting a project is tricky.


- Does deleting a project *DELETE* its Git repository and permanently destroy the
  project's history?  Or does it *ARCHIVE* the repository into an attic area?  Or
  does it support both?

- What happens if we create "A", delete "A", create "A", delete "A" ?  If we archive
  deleted projects, how do we now archive two different "A" projects?

- What happens to the change records of a deleted project?  Change records are keyed
  by the project name.  If the name is available for reuse we may have to delete all
  of the change records, or modify them to point at the attic.

- What happens in a larger context with something like repo, where the deleted
  project may still be necessary to build older products?  We need to hold onto
  the deleted projects so clients can check out a historical branch and still get
  all source files.

Current work around:

The current work around we use is to leave everything alone on disk (don't touch the 
Git repository, don't touch the change records) and simply remove all permissions 
except READ +1.  This means users cannot upload changes into the project, they cannot
approve existing changes, and they cannot submit existing changes.
I think you can delete the project permanently, after all, git is distribuited, and 
some one is going to have that project.
My POV is that gerrit is just to do CR, it is not a central reposotory, i have no 
central repo.

thanks for the fast answer!.
Comment 3 by, Dec 2 2009
That may be true for you, but for many other organizations, Gerrit is the central 
repository, and the user repositories are more likely to disappear.
Project Member Comment 4 by, Dec 2 2009
Android is a good example.  If a project is removed from Donut to Eclair, I still need 
to be able to download the Donut branch and have everything build.  Being able to 
repeat a build down the road is a key requirement for lots of organizations using 
Ok, I see your point. But in that case you are not going to delete the project, 
because that project is still alive. I'm talking about, I don't need this project 
anymore, or I made a mistake and this project shouldn't be here, or something like 
that.. For the situations you mention, I think an active flag, could be a good idea.
Comment 6 by, Apr 9 2010
I also have the issue of their being a completely unused projects due to a mistake
(e.g. someone miss-typed the name on create). In this case I think a great big
"unrecoverable warning" / "are you sure?!" with all the items listed in comment 1,
and then purge everything (git files, and dB references). This leaves the server in a
clean state so that even if the name does get used down the line, it is free for
someone to do a create project on.
Yes, Completelly agree.. Now, we, in my company, we have the situation, that many (3) 
Project leaders, decided to try gerrit.. so they did, 3 different projects, because 
they have 3 different workfows to do the review.. so, the result of this, is 3 projects 
that i have to go into the gerrit DB, and delete them..
That is not good.
I just need to delete the empty project. which name or path might  mistyped.
Project Member Comment 9 by, Jul 16 2010

Phase 1:

- delete all metadata related to the project from gerrit
- if the project has no changes just proceed w/o confirmation, otherwise confirm first with a big warning that deletion is undoable (modulo figuring out the SQL needed to restore the project on your own).
- leave the git repo alone on disk
- if someone tries to recreate the project and there is already a git repo on disk, error out.

Phase 2:

- gerrit exports its metadata into the git repo (git notes?)
- if someone tries to recreate the project and there is already a git repo on disk, gerrit offers to import the repo.
- if the user doesn't want to import the repo, it's up to them to move it aside on disk first

We could go on, but I think just having a way to delete empty projects created in error would be a great first step.

Project Member Comment 10 by, Jul 16 2010
To delete an empty project (one with no changes) from gerrit 2.1.3, you can use the following steps (confirmed by sop):

1) In the gerrit UI, delete all the project's rights.

2) In the gerrit UI, set the project's description to 'DELETE'.

3) Via gsql:

 delete from projects p where description='DELETE' and
 not exists (select 1 from projects where p.parent_name = and
 not exists (select 1 from ref_rights rr where rr.project_name = and
 not exists (select 1 from changes c where c.dest_project_name =;

 delete from account_project_watches where project_name not in (select name from projects);

4) Remove the repo from disk.

Hi Shawn, Ulrik asked us to take a look in this issue. Do you know if is there already anybody working on this? Thanks 
Comment 12 by, Aug 20 2010
Nope, nobody is working on it.

But that's because this issue is really hard.  :-(
I think that as a partial implementation we could remove projects that have no changes in the gerrit DB. That would at least forgive an admin that have created a project with the wrong name.
Would this be acceptible as a first step of the delete project implementation?
Comment 14 by, Aug 23 2010
Yes, deleting an empty project is a great first step.
Comment 15 by, Aug 28 2010
Labels: -Priority-Minor Priority-Major
Aside from being the most starred open change right
now, the #10 search term over the past 30 days that
drove traffic to our project was "gerrit delete project".

Apparently people are using Gerrit, and aren't sure how
to remove a project they have.  :-(
Hi, there.
So I'm going to start implementing delete only for empty projects.
As a second step do you have any suggestions?
We have discussed some implementation options:

We could rename the projects that have any changes to something like to_Delete_<project_name> and then

1. The owner user should be able to delete projects named to_Delete_<project_name> or,

2. Only admin users can delete projects named to_Delete_<project_name> or,

3. We can create an ApprovalCategory (canDeleteProject) and users that have this RefRight should be able to delete projects named to_Delete_<project_name>

What do you think about that?
Comment 17 by, Aug 31 2010

Renaming projects requires that we first submit the work from SAP[1]
to make renaming possible.  Since SAP is going to follow-on with
actually doing the renaming support, I wouldn't just yet waste my
time with trying to implement renaming.
Actually, for deletion of non-empty projects we probably want to keep
them at their current name, but cycle a project through some states:
 - Valid Project: This project can be used by any user assuming
   they have proper access to it.
 - Archived Project: The project still exists, but it cannot be
   modified by anyone.  Access controls and description can still be
   modified, but that is about it.  Access controls for Code Review,
   Submit, Push Branch, Push Tag, etc. (basically any writing)
   are ignored so that users cannot upload new changes, cannot
   approve changes, and cannot submit changes to an archived project.
 - Deleted Project: The project still exists, but it cannot be read
   or modified by anyone.  Only a site administrator can see it in
   Admin > Projects, but otherwise all access controls are ignored.
   Thus it cannot be accessed, but its name is still reserved,
   and its data is still kept around on disk.
Once a project is in "Deleted Project" state we can let a site
administrator purge it from the system.  Purging a project would
delete all of the change data from the database, and wipe out the
Git repository underneath.
To implement this we add a new status field to project with these
3 states on it, and add web UI to permit a project owner to cycle
it through these states.  I think the transition graph is:
  Valid -> Archived -> Deleted -> Prune
    /*\        |        |
     |         |        |
So you first need to archive the project, then you can make it
deleted.  Once its deleted, a site administrator can pick to have
the project pruned.
As a safety measure I think we want to make Prune an actual state
for the project and just move it into Prune status, then use a
background task to process the pruned projects out of the database,
and off disk.  That way we don't have to worry about how long it
will take to remove 50,000 change records when a project is being
wiped off a server.  Further by using a background task we can
put an "oops delay" in, say 5 days by default, where a project in
Prune state sticks around for a full 5 days after being put into
that state before the system actually wipes it from disk.  This is
similar to how Git does garbage collection, loose objects are kept
around for 2 weeks before being deleted from disk.
We can also add an SSH command to force the prune queue to run
immediately, so an administrator can force us to do the prune action
right now if they are really certain they want us to wipe data out.
To be extra safe I would have this command require use of a very
long option like `--force-prune-right-now` before it prunes anything
younger than the prune delay (e.g. 5 days).

Project Member Comment 18 by, Aug 31 2010
+1 on comment 17, that sounds like an excellent design to me.
Comment 19 Deleted
Comment 20 by, Aug 31 2010
Re comment #17, I should add that we probably also need
a last_updated_on timestamp added to the projects table.
Each time we modify the project, we should touch that to
a current time.  Then prune is implemented as a task that
runs once every 24 hours (similar to log compression), and
finds projects where their status = 'PRUNE' and their last
updated on timestamp is < 5 days ago (or whatever the prune
time period is set to).
I think the suggested process in #17 looks really good, it implements a quite good archive policy.
I have some details to suggest, however.

Valid is not a bad name of the state. I personally favor "Active" though. It's easy to think of the other states as a subset of the opposite to the first state, and invalid is not actually describing the state of the projects as well as inactive does. Valid/invalid makes me associate to fsck, a whole or a broken git. But maybe it originates from me not being a full native english speaker, I might simply associate wrong.

I really like the idea of an attic for some of these states. Perhaps even consider different behaviours on a master server versus a slave server, I'm mainly thinking of having the attic only on the master server and perhaps purge the project from disk at an earlier stage on the slave.
I suggest the following:
* Active - Git active in regular git storage location
* Archived - Git archived, but remains in regular git location
* Deleted - Git moved to attic on master server, queued for purge/removal on slave servers.
* Purge - Database and git in attic queued for purge on master server
If we move a project from deleted to any other state we would then have to recreate it at the slaves again, of course.
Hope this makes sense, if not I appreciate further comments on this.

On the topic of last_updated_on and the suggested 5 days timeout; it would be fantastic if this also could be a transparent countdown, i.e. the time of actual purge taking place would be displayed somehow to the admin, so you know how long time it is left before it is actually gone. But here it would be sufficient to show the countdown feature only for the final purge on the master server.

We would also need the admin entry in replication.config [1] implemented for this change to be complete. 

That's it for me, as far as the details go. :)

Comment 22 by, Sep 1 2010
I agree, "Valid" is a bad name for the initial/primary state.
"Active" as you suggest in comment #21 is better.
I think you are correct that we can purge it from a slave earlier than
the default of 5 days.  Once a repository is marked as Deleted on the
master its not available to any user, so at that point it makes sense
to consider removing from a slave in order to reduce slave disk space
used.  But it should have at least a 24 hour delay by default just in
case an admin moves it back to Archived or Active, so we don't need to
expend a lot of effort to bring the slave back.
Moving the Git repository into an attic directory doesn't seem to get  
us anything.  Moving a repository on disk is difficult due to its
files being concurrently open by another thread that is trying to read
from it.  The easiest way to make a move to an attic directory occur
safely is to wait 15 minutes after a project has entered the Deleted
status before moving it.  That allows any active user to (hopefully)
stop using the project before we try to close all of the files and
move the directory around.
What is the motivation for having an attic directory for the projects
that are in Deleted status?

Ok, a grace time, albeit shorter, is fair on the slaves too I guess. I don't object to that. :)

On moving the git into an attic. Yes. Admittedly a very insignificant problem/situation, but still.
There are some reasons. 
* Once the git becomes deleted, the name space is seemingly free and available, and theoretically a new project could be ordered that requires the name space in question. 
To clutter up other, less probable name spaces (Such as Deleted_$PROJECT_NAME or Deleted_by_my_aunt_$PROJECT_really_deleted) is still not fixing the problem. In theory (admittedly a _quite_ slim chance on this one, hrm...), the order for this project name could also appear.
* On a more practically viable level, it happens every now and then that we setup a new slave server. It's nice to be able to rsync/ship away one directory and be certain that only relevant stuff gets included. 
* At one point in time we also ran an independent gitweb installation here at $DAYJOB (I've forgotten why..), which would display the directory hierarchy when browsed to. We did a very crude kind of delete where we'd only remove the project and ref_rights lines in the database and not actually touching the gits on the servers. So gitweb our was at some point quite cluttered by projects that didn't exist in gerrit.

In conclusion then: admittedly not the end of the world without the attic, but if given the choice I'd choose a solution with the attic. The call is ultimately yours, and if the job of implementing an attic gets out of hands effort wise, let's skip it. It's just a nice-to-have, nothing more.

A 15 minute grace time for open file handles is quite acceptable, I consider that close enough to "immediate".
Comment 24 by, Sep 1 2010
OK.  But we can't recycle a project name until 
its record in the projects table is removed.

For a deleted project, I would implement the
deletion process as:

 - remove the change records
 - remove the git repository
 - remove other stuff like ref_rights
 - remove the project record

So the name is still "reserved" until the very last step
of the deletion is completed.  Thus moving a project into
the attic doesn't really free up the name.  It only helps
the "setup new slave via rsync" and "hide from gitweb" use
cases you mention above.  Which are still very reasonable
arguments for why we should move a project to an attic.
Hmm, you're right, at least as of today. But with the rename projects change [1], we're reintroducing synthetic primary keys again, if I'm not mistaken? 
Also, it'll be necessary to have a new field describing the current project status, and with the combination of these two parameters we're able to make the name space available at once (If desired, of course. At least the keys in the database isn't in the way for it anymore).

I would advice caution and recommend to remove the project record before the ref_rights. This is to prevent that previously read protected content is made public in the odd case that the second of those two commands should fail and the git made public again. But maybe we can surround all of those delete queries in a single transaction instead, then we'd be safe against that happening.

Actually, another good reason to have an attic during delete is for disk space reasons.
If there is a sudden shortage of disk space on the volume keeping the git storage, a pragmatic short term solution (too often used in reality.. :-) ) could be to hunt for some deprecated projects which take up a lot of space, and move them to deleted/attic. If the attic location is configurable it is entirely possible to put the attic on a separate partition / nfs location with comparably little hassle.

So, as far as available "instant rescue the situation/day"-solutions go, this one definitely fits the bill.
Please, please!!!
Project Member Comment 28 by, Apr 8 2011
I realize that it is probably too late for my suggestions, and that a lot of work has already gone into implementing many of the ideas here, but I figured that I should make my suggestions anyway.  Perhaps if they are not used here, they will be next time someone thinks of a similar problem.

Whenever I think of deleting data permanently, I am reminded of an article I read which suggests that "instead of adding confirmations, implement an undo feature".  I cannot help but think of how well that could apply here.

Some of the features suggested here do provide a limited undo capability, but I fear that they do not go far enough.  I would like to suggest that an approach be taken that would facilitate "exporting" a project's data to a format that could be reimported.  If it were easy to export/import a project, I suspect that some of the delete confirmation hoops suggested here will seem like overkill.  I also suspect/hope that the current migration of Gerrit data to a project's repo might even go along way to make importing/exporting easy?

Here are some of my concerns:  after reading this thread and actually viewing the submitted changes to implement much of what is discussed here, I am intimidated by both the hoops required to delete a project, and the code to implement these hoops.

For starters, I feel like the people who need "delete" the most are likely the people experimenting with Gerrit.  I am having a hard time imagining myself running through the various steps described here to delete a project.  I am having an even much harder time imagining a person just learning to setup Gerrit figuring out these steps, and I certainly can imagine their potential frustrations.  Not to mention that, a person just setting up or experimenting with Gerrit is likely to not really benefit from these steps.  So, who will benefit?  Likely an admin on a production site.  But, would such an admin not benefit more from the simple ability to reimport a project?

One thing that I gained from the discussion in this thread is that people want the ability to ramp down a project.  I think that this is great, but that perhaps this desire has been tied too much to the deletion idea.

So, what if instead, the various project states were reduced to 3: active/readonly/hidden?  I suspect that these states should cover what most people are concerned with.  Additionally, these states could very well be useful even in normal operation.  A simple change in management may make people want to make a project hidden.  A technical problem may make a temporary readonly state desirable... If these 3 states are not enough granularity, more can be added, but I do not see a good reason to tie them to deleting a project (or vice versa), except for perhaps desiring a quiescent project state (anything but active).

What should perhaps be tied to deleting a project, is a check that a current export of the project is available.  If a current export is confirmed by Gerrit, I see no reason why it should not be possible to outright delete the project from the server (except for the exported data naturally) with a simple command, GUI or SSH.

Such an approach would be both simpler for admins and for people just messing around or setting up Gerrit.  It would also likely make an admin sleep easier after deleting a project, not matter how many days he chooses to spread the ordeal over.

There are additional benefits that adding the ability to import/export projects would have.  It would make it easier to migrate projects from one server to another.  It would make it easy to backup projects individually.  Even more importantly, it would make it possible to restore projects individually.  It would make it possible to scale an installation with many projects by splitting out some projects onto a new server.  An export would also likely provide the attic feature proposed above...  

Project Member Comment 29 by, May 13 2011
 Issue 941  has been merged into this issue.
Comment 30 by, May 13 2011
I will try to answer Shawn's questions from my point of view (our needs):

"Does deleting a project *DELETE* its Git repository and permanently destroy the
 project's history?  Or does it *ARCHIVE* the repository into an attic area?  Or
 does it support both?"

Yes, deleting the project history is fine with us, that's why we would want to delete repositories, otherwise we would want to rename it which is a separate feature that  would also be great to have but that's irrelevant to the issue.

We have backups for all data anyways, I don't need Gerrit to implement his own backup system just because some operations are dangerous, this includes current operations such as removing a branch, how do you recover what the branch was pointing to if not from a backup? Or even worse, a nightly cron job may "gc" the repository and remove dangling objects that were referenced only by the removed branch. So even now you need backups anyways because some operations are dangerous.

"What happens if we create "A", delete "A", create "A", delete "A" ?  If we archive
 deleted projects, how do we now archive two different "A" projects?"

That is no problem if you remove the project and all its associated data.

"What happens to the change records of a deleted project?  Change records are keyed
 by the project name.  If the name is available for reuse we may have to delete all
 of the change records, or modify them to point at the attic."

Yes, please do. That is the whole point of asking this feature from Gerrit, right now I have to manually go through >5 tables and remove entries referencing to (referencing to, referencing to, etc) the deleted project. This is a complex, clumsy operation that Gerrit can do much safer since Gerrit can know exactly what its database structure is (instead of an error prone human that has to reverse engineer it).

"What happens in a larger context with something like repo, where the deleted
 project may still be necessary to build older products?  We need to hold onto
 the deleted projects so clients can check out a historical branch and still get
 all source files."

I don't think that's Gerrit's problem, it sounds more like a problem of the "repo" system. If you have a "repo" setup better not remove repositories since you may always need them (it is the "admin" that can issue the remove command and the "admin" knows if they use "repo" or not, also for increased safety, a config option that needs to be enabled to support the remove command could be added).
Project Member Comment 31 by, May 20 2011
Blocking: 798
Hi all, we really need a definition prior to kill this.

Shawn, we have already developed this feature[1] according to your comments, just pending rebase now!
Martin however came up a different and reasonable suggestion.

What do we do?

1)	Rebase and push for review.
2)	Abandon it and re-implement according to Martin


Comment 33 by, Jun 13 2011
Martin's comment #28 from April 8th makes a lot of sense. We are heading in that direction anyway with the notion of moving everything into Git.

Once the change data is also in Git, there is no need to "export" before deleting. We can implement delete by moving the repository to a randomly generated name in a hidden attic directory. Undoing this deletion would be a matter of moving the repository back, and allowing the server to (re)index the change data for search purposes. For this reason I would like to put off deletion until I can finish moving the data into Git. I'm hoping to work on that code this week actually, so we may not be waiting that long after all.

The notion of "active/readonly/hidden" for a project state we can implement now. Its just an enum value stored in project.config. A few places need to be modified to honor the setting, but this should be a fairly small change.

To be clear:

* active: Default state if the variable is not present in the configuration.

* readonly: Users can see the project if read permission is granted, but all modification operations are disabled. Most of these are in RefControl, and just need to ensure the RefControl method always returns false. We also need a check in the PublishComments class to prevent comments from being published while the project is in the readonly state.

* hidden: A minor change to RefControl.isVisible(). If the user is not a project owner, the project is hidden, even if it would normally be visible to them.
Comment 34 by, Jun 24 2011
How is the project attribute feature (and the "move to the attic" directory idea) going to hide projects from GitWeb/cgit index view?
Please, implement at least the simplest way to remove a project from gerrit.. I'm having 20 projects I don't use any more... The repos are in backups, and deleting them from gerrit DB is not a good solution..
Please, at least, implement the full delete.

This ticket is the one that has more stars!... I think that gives the ticket the importance to do it right now!
This issue resulted in the change:

It's pending review

Comment 39 by, Dec 29 2011
Yes, I'm expecting new function "delete projects though web interface"

For project archive, I have some scripts to delete gerrit project and related changes in mysql DB. The following are table name.


This issue resulted in .

Which is not exactly what was requested originally. What should we do? Leave it open? Close as "Released" and then open a new Change?
Project Member Comment 41 by, May 4 2012
Hiding projects is nice, but there's times when you want to remove a project entirely and never have it come back. That should still be possible, even if only from the command line ( issue 798 ).
need this feature, please!
I don't think that hiding projects is enough, certainly not for our needs.
I would vote for keeping this issue open until deletion via UI or command line is possible.
Project Member Comment 44 by, Jun 3 2012
I think you can still leave this open since it is only partially implemented so far.
Project Member Comment 45 by, Oct 9 2012
Blockedon: -gerrit:203 gerrit:203
Blocking: -gerrit:798 gerrit:798 gerrit:798
Comment 46 by, Dec 11 2012
I really could use this feature now.  I want to delete the project and it's git repository.  I do not care about archiving into an attic.  I just want it gone.
I agree that this is a priority for us to. 

At the moment it is possible to delete the repository from the file system and flush the cache which removes it from the web ui however if I attempt to re-create a repository with the same name it indicates that it still exists.
Comment 48 by, Jan 10 2013
For 2.5 the gerrit-delete plugin should be able to really delete a project.
Project Member Comment 49 by, Jan 10 2013
@Liam - like iceelch said, use the delete-project plugin if you are running Gerrit 2.5.  Otherwise there are other database entries and associated cruft you'll need to clean out to fully delete a project.
Is there already compiled delete-project plugin we could use? I tried to compile it myself, but it complains about missing dependencies (gerrit-plugin-api), and I am not quiet versed in Java ecosystem...
Attached is my jar file of the delete projects plugin, I've run it succesfully in Gerrit v2.5.0 and v2.5.1. Have fun.
8.2 KB Download
Comment 52 by, Jan 11 2013
is there also some guide how to use the plugin? (after I've installed it successfully I mean)
Hmmmm... yes, that was some trial and error; please try this:
$ ssh -p 29418 $yourGerritServer deleteproject delete --help
FYI - that compiled plugin will not work on PostgreSQL due to the TODO part about submodules.
deleteproject.jar (compiled) works as a charm on H2 database. Thank you!
Comment 56 by, May 15 2013
I just wanted to mention some issues I had with deleting and creating repos. I used the gerrit delete-project plugin and I was able to delete and recreate repositories fine. I ran:

$ git clone
$ cd delete-project
# We're using gerrit 2.5 and there were some incompatibilities in the latest code:
$ git checkout d818c5
$ mvn clean package
$ ssh -p 29418 gerrit plugin add --name deleteproject - < target/deleteproject-1.0.jar

I was then able to do the following over and over:

$ ssh -p 29418 gerrit create-project --name fooproj
$ ssh -p 29418 deleteproject delete --yes-really-delete fooproj

Until I created the slave git repo that the replication plugin replicates to. Unbeknownst to me, having a repo exist at the replication destination prevents one from then creating the repo in gerrit. So I could delete the project, but then create-project started failing with:

fatal: project "fooproj" exists

I thought perhaps the deleteproject wasn't fully deleting the project for some reason now. Perhaps either deleteproject could warn when a replicated repo is still around, or create-project could give better errors about why a project couldn't be created.
I've run the following command:

$ ssh -p 29418 <my_gerrit_server> deleteproject delete --yes-really-delete <myproject>

and get the following:

fatal: internal server error

Server side log has the following:

[2013-05-20 15:50:32,916] ERROR : Internal server error (user blah account 1000003) during deleteproject delete bua/linux_bua --force --yes-really-delete
org.postgresql.util.PSQLException: Operation requires a scrollable ResultSet, but this ResultSet is FORWARD_ONLY.
        at org.postgresql.jdbc2.AbstractJdbc2ResultSet.checkScrollable(
        at org.postgresql.jdbc2.AbstractJdbc2ResultSet.first(
        at org.apache.commons.dbcp.DelegatingResultSet.first(
        at org.apache.commons.dbcp.DelegatingResultSet.first(
        at java.util.concurrent.Executors$
        at java.util.concurrent.FutureTask$Sync.innerRun(
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(
        at java.util.concurrent.ScheduledThreadPoolExecutor$
        at java.util.concurrent.ThreadPoolExecutor.runWorker(
        at java.util.concurrent.ThreadPoolExecutor$

Any ideas?
Comment 58 by, May 20 2013

Yes you can mod the code to change the result set type. That's what we did to work around this.
Project Member Comment 59 by, May 21 2013
@58 - patches to fix this are more than welcome :)
Can some one please post compiled latest version of delete-project ?
Project Member Comment 61 by, Jul 10 2013
Deletion of project through Gerrit web UI is implemented and can be used. The implementation uses ui-plugins features developed
during the last Hackathon. Among other defined places on core Gerrit screens, like current patch set action panel, plugins can
contribute to project info screen. Existing delete-project plugin was extended and implements now UiDeleteProjectCommand.

When deployed, and the user is logged in and has the ACL "Delete"-button appears on project info screen. The workflow is as follow:

* Click on Delete Button
* Confirmation dialog appears: "Are you sure ..."
* Click yes
* Project get deleted
* User is redirected to the project list screen

While the "ui-plugins" series was partially merged to master "Support for project info screen place" and "Support for redirect and reload outcome" is still pending for reviews.
Changes in delete-project plugin are still pending for reviews.

to test/deploy that before it is merged:

Patch gerrit itself
1/ apply the ui-plugins core series [1]
2/ build deploy/gerrit
3/ build gerrit-plugin-api and deploy it to local maven repository

Patch delete-project plugin
1/ apply the ui-plugins delete-project plugin series [2]
2/ build/deploy delete-project

Summary: Delete projects through web interface (was: Delete projects though web interface)
Project Member Comment 63 by, Sep 27 2013
Status: Submitted
The delete-project plugin [1] provides now a button on the project screen [2] to delete the project.

Project Member Comment 65 by, Oct 23 2013
 Issue 2214  has been merged into this issue.
The plugin 'delete-project.jar' doesn't seem to work when installing to 2.8+

I got these errors: Guice creation errors:

1) An exception was caught and reported. Message: This version of the delete-project plugin is not compatible with your current schema version (Version: 84). Please update the plugin.

1 error
	at java.util.concurrent.Executors$
	at java.util.concurrent.FutureTask$Sync.innerRun(
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(
	at java.util.concurrent.ScheduledThreadPoolExecutor$
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$
Caused by: Guice creation errors:

1) An exception was caught and reported. Message: This version of the delete-project plugin is not compatible with your current schema version (Version: 84). Please update the plugin.

1 error
	... 13 more
Caused by: java.lang.RuntimeException: This version of the delete-project plugin is not compatible with your current schema version (Version: 84). Please update the plugin.
	... 17 more
fatal: plugin failed to install
╭─sxiao at thq-m-sxiao01 in ~/workspace/delete-project on master✔ using ‹›
╰─± mvn package                                                                                                 
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Delete Project Gerrit Plugin 2.8-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
Project Member Comment 67 by, Jan 18 2014
You are using old version of the plugin. In this change [1] support for version 84 was added and in this change [2] the guessing of delete handler was redesigned.

The latest link only leads to source files
Where can I find the latest compiled version for deleteproject.jar to download so I can use it in Gerrit 2.8.1?
Is there anyone out there in the community who is able to provide the latest jar for the delete project gerrit plugin somewhere and post the link to make a version available that can be used with gerrit 2.8.1??
As I need it myself as well, I tried to compile it. Took some time, patience, good reading, but it seems I succeeded. Attached is a JAR file I've ran on 2.8.1

The usual disclaimer: it works on my machine, and I've tested it on my machine alone.
27.6 KB Download
Is there any built jar file available for Gerrit 2.9?
Sign in to add a comment