Failed to get remote repository during update-repos migration step

Drone Support
1

Hi,

I’m in the process of migrating from drone v0.8 to v1 and I am encountering some issues with the migration with drone-migrate.

The repos owned by some users (looks like the ones that have not accessed drone or the scm for a while) show errors during the remove-renamed and update-repos steps.

The error is:

level=error msg="failed to get remote repository" error="Bad credentials" owner=xxx repo=my-organisation/my-repo

My understanding is that this is happening because the tokens cached in the drone db have expired.

The problem with this is that because the update-repos step failed, those repos have still a temporary uid as it could not be retrieved from the scm.

In turn, when a user logs in and the repos are synced, the repos that could not be updated by drone-migrate appear as brand new repos as uids do not match. And because there is now a new record in the database representing that repo, the secrets that were migrated are
no longer associated with the repo.

Is there a way of overwriting the credentials used to obtain the UID of a repo if the cached credentials fail? I’m thinking about a way of specifying the token of an admin robot on the scm, something like DRONE_GITHUB_CLIENT_ID and DRONE_GITHUB_CLIENT_SECRET (supported by Drone server), but from what I’ve seen, that’s not supported by drone-migrate?

Thanks

2

In this case you can run the remove-not-found and remove-renamed commands. This will remove any inactive repositories (where the user no longer has access or the repository no longer exists) and it will remove any repositories that may have been renamed.

You should ensure the following sql statement returns an empty result set before you complete the migration and before users login to the new system:

SELECT *
FROM repos
WHERE repo_uid LIKE 'temp_%'
3

I’m trying to avoid simply removing those repositories, as the repositories are still active. The original owner might have moved on, but other people in the group still contribute and make changes to those repos.
If I remove those repos, the drone secrets they contain will be lost and dev teams would have to re-create them manually. I’m trying to avoid such an outcome as there are quite a few repos being affected.

4

@nefischer in this case, these repositories would no longer be functioning in 0.8 which is why we generally consider them safe to exclude from the migration. However, if you want to preserve these repositories you would need to perform the following steps:

  1. get a list of repositories where the migration is failing
  2. change ownership of the repository from the current (inactive) user to a new (active) user by running the drone repo chown command [1]. This command must be run against your 0.8 system.
  3. re-run the migration from scratch once all repositories have been resolved

Note that the above steps would handle any scenarios where the repository owner is inactive. If the repository was renamed and has two entries in the 0.8 database (one entry for the old name, and one entry for the new name) the entry for the old name cannot be migrated to 1.x and would need to be removed with the remove-renamed command before completing migration.

[1] https://0-8-0.docs.drone.io/cli-repository-chown/