Update to the drone cli to allow renaming of repos - will still need …

[josmo]

trafficstars

…the drone-go update

Needs to have have https://github.com/drone/drone-go/pull/32 and https://github.com/drone/drone/pull/2168 before merging. :) mainly for comments @bradrydzewski

[bradrydzewski]

hey, there is one gotcha we didn't account for. If drone re-synchronizes your repository list you will end up with both the old and new repository in your list. drone repo mv will fail because the database will already have an entry for the repository ...

I'd like to brainstorm a fix at the server level for this. Open to ideas.

[josmo]

Oh good catch. It guess it's a timing issue right now but we should find a way to handle it :/ Would it make sense to check if the new one already exists and if it does and is not enabled to remove it before renaming?

[bradrydzewski]

If the goal is to KISS I would advocate that in order to successfully execute drone repo mv you must re-sync your repository list so that both repos are in the list. Then you can execute drone repo mv. The server would do a simple update and move builds, registry credentials and secrets from one to the other simply by updating the foreign key

update builds
set build_repo_id = @new
where build_repo_id = @old;

update secrets
set secret_repo_id = @new
where secret_repo_id = @old;

update registry
set registry_repo_id = @new
where registry_repo_id = @old;

[josmo]

We'd also have to update the timeout, enable the new repo and everything right? Seems like that might be more involved then maybe doing a switch.

1. Sync the repos
2. rename destination repo to temp
3. rename origin to destination
4. rename temp or origin

it keeps both the old and new but we don't need to worry as much about all the settings and links to other tables since it's still the original record?

That seams like less of an impact to me but I'm down to do it either way you want :)

[bradrydzewski]

rename temp or origin

This still has edge cases because the permission table has been synchronized as well. The solution I'm proposing is not the most user friendly, but instead focuses on eliminating edge cases. Since this is not a common daily operation for most users, I think focusing on correctness over usability is ok.

So with that being said, I think the user would login to the user interface and re-synchronize their repository list if necessary. This is not something we would handle automatically from the command line.

Now the user would be able to execute drone repo mv

The API call would essentially swap foreign keys in the database as well as copy over some custom properties from the old repository to the new repository. This would not be done in pure SQL, but we could visualize the pseudo code using SQL:

update repos set
 repo_timeout = @old
,repo_config = @old
,repo_visibility = @old
-- a few more fields --
where repo_full_name = @new

update builds
set build_repo_id = @new
where build_repo_id = @old;

update secrets
set secret_repo_id = @new
where secret_repo_id = @old;

update registry
set registry_repo_id = @new
where registry_repo_id = @old;

[josmo]

Sounds good! I'll take a stab at it later tonight or in the next couple days to update to this logic. Seems like from the CLI and drone-go perspective everything would stay the same and it would only be a server update.

[josmo]

@bradrydzewski let me know if you need anything else on this :)

[josmo]

@bradrydzewski looks like this and https://github.com/drone/drone/pull/2184 are the only PRs left for renaming via the cli :) . Is there anything else I should do with it?

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[bot-harness]

This PR has been automatically closed due to inactivity.