|Delete projects through web interface|
|Reported by german.o...@gmail.com, Dec 2 2009||Back to list|
Add the posibility to delete a project. This is really important.
Dec 2 2009,
Deleting a project is tricky. Questions: - 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.
Dec 2 2009,
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!.
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.
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 Gerrit.
Dec 2 2009,
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.
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.
Apr 10 2010,
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.
Jul 14 2010,
I just need to delete the empty project. which name or path might mistyped.
Jul 16 2010,
Proposal: 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. $0.02.
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 = p.name) and not exists (select 1 from ref_rights rr where rr.project_name = p.name) and not exists (select 1 from changes c where c.dest_project_name = p.name); delete from account_project_watches where project_name not in (select name from projects); 4) Remove the repo from disk.
Aug 20 2010,
Hi Shawn, Ulrik asked us to take a look in this issue. Do you know if is there already anybody working on this? Thanks
Aug 20 2010,
Nope, nobody is working on it. But that's because this issue is really hard. :-(
Aug 23 2010,
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?
Aug 23 2010,
Yes, deleting an empty project is a great first step.
Aug 28 2010,
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. :-(
Aug 31 2010,
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?
Aug 31 2010,
Renaming projects requires that we first submit the work from SAP 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.  https://review.source.android.com/16512 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).
Aug 31 2010,
+1 on comment 17, that sounds like an excellent design to me.
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).
Sep 1 2010,
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  implemented for this change to be complete. That's it for me, as far as the details go. :)  http://groups.google.com/group/repo-discuss/browse_thread/thread/945f313be4f26167#msg_1c8a85c07d980687
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?
Sep 1 2010,
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".
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.
Sep 1 2010,
Hmm, you're right, at least as of today. But with the rename projects change , 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.  http://code.google.com/p/gerrit/issues/detail?id=560
Sep 6 2010,
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.
Nov 11 2010,
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...
May 13 2011,
Issue 941 has been merged into this issue.
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).
May 20 2011,
Jun 8 2011,
Hi all, we really need a definition prior to kill this. Shawn, we have already developed this feature 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  https://review.source.android.com/#change,17436 https://review.source.android.com/#change,20368 https://review.source.android.com/#change,20369 https://review.source.android.com/#change,20370
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.
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?
Jul 31 2011,
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. Thanks.
Aug 2 2011,
This ticket is the one that has more stars!... I think that gives the ticket the importance to do it right now!
Aug 2 2011,
This issue resulted in the change: https://review.source.android.com/#/c/24659/ It's pending review
Nov 18 2011,
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. projects ref_rights account_project_watches account_patch_reviews patch_comments patch_set_ancestors patch_set_approvals patch_sets starred_changes tracking_ids change_messages changes
May 4 2012,
This issue resulted in https://gerrit-review.googlesource.com/#/c/24659/ . Which is not exactly what was requested originally. What should we do? Leave it open? Close as "Released" and then open a new Change?
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 ).
May 10 2012,
need this feature, please!
Jun 3 2012,
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.
Jun 3 2012,
I think you can still leave this open since it is only partially implemented so far.
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.
Jan 9 2013,
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.
Jan 10 2013,
For 2.5 the gerrit-delete plugin should be able to really delete a project.
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.
Jan 10 2013,
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...
Jan 11 2013,
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.
Jan 11 2013,
is there also some guide how to use the plugin? (after I've installed it successfully I mean)
Jan 11 2013,
Hmmmm... yes, that was some trial and error; please try this: $ ssh -p 29418 $yourGerritServer deleteproject delete --help
Jan 12 2013,
FYI - that compiled plugin will not work on PostgreSQL due to the TODO part about submodules.
Jan 21 2013,
deleteproject.jar (compiled) works as a charm on H2 database. Thank you!
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 https://gerrit.googlesource.com/plugins/delete-project $ 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.example.com 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.example.com gerrit create-project --name fooproj $ ssh -p 29418 gerrit.example.com 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.
May 20 2013,
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 com.google.gerrit.sshd.BaseCommand : 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(AbstractJdbc2ResultSet.java:210) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.first(AbstractJdbc2ResultSet.java:292) at org.apache.commons.dbcp.DelegatingResultSet.first(DelegatingResultSet.java:364) at org.apache.commons.dbcp.DelegatingResultSet.first(DelegatingResultSet.java:364) at com.google.gerrit.plugins.DeleteCommand.doDelete(DeleteCommand.java:114) at com.google.gerrit.plugins.DeleteCommand.run(DeleteCommand.java:87) at com.google.gerrit.sshd.SshCommand$1.run(SshCommand.java:35) at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:430) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:337) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Any ideas?
May 20 2013,
@57 Yes you can mod the code to change the result set type. That's what we did to work around this.
May 21 2013,
@58 - patches to fix this are more than welcome :)
Jul 5 2013,
Can some one please post compiled latest version of delete-project ? https://gerrit.googlesource.com/plugins/delete-project please?
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  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/ build/deploy delete-project  https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit+branch:master+topic:ui-plugins,n,z  https://gerrit-review.googlesource.com/#/q/status:open+project:plugins/delete-project+branch:master+topic:ui-plugins,n,z
Sep 16 2013,
Sep 27 2013,
The delete-project plugin  provides now a button on the project screen  to delete the project.  https://gerrit-review.googlesource.com/#/admin/projects/plugins/delete-project  https://gerrit-review.googlesource.com/49250
Oct 21 2013,
Oct 23 2013,
Issue 2214 has been merged into this issue.
Jan 7 2014,
The plugin 'delete-project.jar' doesn't seem to work when installing to 2.8+ I got these errors: om.google.gerrit.server.plugins.PluginInstallException: 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. at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:136) 1 error at com.google.gerrit.server.plugins.PluginLoader.runPlugin(PluginLoader.java:412) at com.google.gerrit.server.plugins.PluginLoader.installPluginFromStream(PluginLoader.java:167) at com.google.gerrit.sshd.commands.PluginInstallCommand.run(PluginInstallCommand.java:92) at com.google.gerrit.sshd.SshCommand$1.run(SshCommand.java:35) at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:442) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:344) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Caused by: com.google.inject.CreationException: 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. at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:136) 1 error at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:448) at com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155) at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107) at com.google.inject.internal.InjectorImpl.createChildInjector(InjectorImpl.java:230) at com.google.gerrit.server.plugins.JarPlugin.startPlugin(JarPlugin.java:156) at com.google.gerrit.server.plugins.JarPlugin.start(JarPlugin.java:123) at com.google.gerrit.server.plugins.PluginLoader.runPlugin(PluginLoader.java:395) ... 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. at com.google.gerrit.plugins.DeleteProjectCommandModule.configureCommands(DeleteProjectCommandModule.java:43) at com.google.gerrit.sshd.PluginCommandModule.configure(PluginCommandModule.java:37) at com.google.inject.AbstractModule.configure(AbstractModule.java:62) at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:230) at com.google.inject.spi.Elements.getElements(Elements.java:103) at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:136) at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104) ... 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] ------------------------------------------------------------------------ [INFO] Building Delete Project Gerrit Plugin 2.8-SNAPSHOT [INFO] ------------------------------------------------------------------------ [WARNING] The POM for com.google.gerrit:gerrit-plugin-api:jar:2.8-SNAPSHOT is missing, no dependency information available [INFO] ------------------------------------------------------------------------
Feb 19 2014,
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?
Feb 25 2014,
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??
Feb 27 2014,
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.
Aug 12 2014,
Is there any built jar file available for Gerrit 2.9?
|► Sign in to add a comment|