Re-using repository names causes drone not to see them?

Drone Bugs
1

We’ve noticed that drone fails to pick up a repository if that repository name existed previously, but had been deleted. By failing we mean that it does not show up in the repo list after a sync. However, and if a user is logged into drone ui as administrator, directly going to the URL of that repo does show it, and it can be activated and builds will run. But not for regular repository users. They get a 404.

We are using drone, self hosted, version drone:latest

We are using Bitbucket Cloud.

As a test.

  1. create a repo in bitbucket (i.e. test-repo)
  2. go to drone ui and refresh / sync and see your repo there
  3. go to bitbucket and delete the repo
  4. verify drone ui no longer lists the repo (sync again)
  5. create a new repo with the same name
  6. go to drone ui and sync, notice the repo is not shown
  7. if you are an admin user hit the repo URL directly in the drone ui (i.e. https://drone.yourdomain.dev/your-bitbucket-username/test-repo/) and you should be able to load and activate it
  8. go to the same URL as a regular bitbucket repo user and get a 404.

Nothing in the drone logs for the server or agent that is related to this, so no logs to share.

Thanks,
John

2

Hi John,
We spent a lot of time on our sync logic and to my knowledge all syncing issues were fixed in 1.6.0 and higher. We account for this particular edge case by identifying a repository with the same name but a different unique id exists, and we delete this repository, so that we can insert the new entry.

This was the relevant issue:

You can inspect this code here:
https://github.com/drone/drone/blob/master/store/batch2/batch.go#L58:L81

We would encourage submitting a unit test that demonstrates that this is not working as expected here:
https://github.com/drone/drone/blob/master/store/batch2/batch_test.go#L263-L389

We also have instructions for debugging repository sync issues. This thread discusses issues syncing GitHub, however, many of the debug steps can be used regardless.

3

Hi Brad,

Thanks for the detailed reply. We may not be able to do a unit test to show that it is not working, but we will try and debug it further and see.

The steps above we have consistently replicated a few times now on our setup.

As a side note, should we use drone/drone:1.8.0 instead of drone:latest? (i usually prefer to version lock)

Thanks
John

4

We may not be able to do a unit test to show that it is not working, but we will try and debug it further and see.

I tested deleting, syncing, re-creating, syncing a repository and was unable to reproduce.

This was the repository entry before delete:

{"id":85,"uid":"92","namespace":"bradrydzewski","name":"test-dupe-name"

This was the repository entry after re-creating and re-syncing:

{"id":86,"uid":"93","namespace":"bradrydzewski","name":"test-dupe-name"

The uid represents the unique identifier (typically a database key) from the source code management system (e.g bitbucket, github, etc), and the uid change indicates the new repository replaced the old, deleted repository in the drone database. I spent a lot of time working to fix this exact edge case a few months back, and my testing a few minutes ago did not yield any unexpected issues or regressions.

The (below) thread I posted can be used to trace the sync process and understand what is being returned from the source control system and whether or not it is being added to the Drone database. Because my testing was successful, I do not have enough data to conclude that Drone cannot sync re-used repository names, so I would recommend gathering more data and trace logs which may help narrow down a root cause.
http://discuss.harness.io/t/drone-not-seeing-nor-syncing-forked-repo/5846/8

As a side note, should we use drone/drone:1.8.0 instead of drone:latest?

We recommend using drone/drone:1 but you can also use drone/drone:1.8 (these tags both currently point to the same image)