Remove faulty deploy refs for gitlab.com projects
In the last release cycle we've deployed code that saves refs for each Deployment object. So users can pull these refs locally and checkout more easily what was deployed.
Before the release however, GitLab saved deployments with their ID instead of their IID. We never reference the ID in the UI anywhere, so this made perfect sense. The impact of this 'bug' is that there are refs saved (by ID) which don't seem to exist on GitLab.com because we find them by IID.
Example: pulling all the refs will give you a number of refs, either in the range of 1300-1500 or 63000-69000. The latter should all be removed.
Now a couple of steps could be taken to fix this, and I'm unsure which is the best one:
- For projects we maintain, we remove the refs from the filesystem and be done with this.
- For all projects using deployments, find out which refs are wrong and remove those (rm path/to/ref/)
- Nothing -- this might create weird unreproducible bugs later.
About the second option, I'm not sure we can do this? The first option we should perform in any case, and is really simple:
cd path/to/www-gitlab-com/refs/environments/production
rm 6*
exitActivity
@jacobvosmaer-gitlab In the list number 2 touches on this point. Im unsure if we can remove refs from ones project?
We should never fix problems on gitlab.com only for ourselves. That would do a disservice to the majority of users.
@zj would it be possible to change the title and rephrase the issue so that this does not sound like 'something is wrong with the www-gitlab-com repo'?
-
Sorry for that @jacobvosmaer-gitlab. I just was not sure we could remove those references. But Ill update the title.
But now I've got your attention, what do you think is the best way forward here? Should I create a ruby script to delete these? WDYT?
@zj I am not the best person to ask perhaps. But I can throw up some questions.
Were the bad refs created by an RC version of GitLab only? Or was it done by an official release.
If it was an RC then it might be good enough to just create a rake task that cleans up the problem. That script could then be used by our infra team and whoever else ran GitLab release candidate x.y.
If it was released we should assume others have this problem and it would be better to create a migration that fixes this.
You might want to ask yourself if this is an infrastructure problem at all, because the application (gitlab-ce) created the mess, didn't it?
-
Were the bad refs created by an RC version of GitLab only?
Yes
If it was an RC then it might be good enough to just create a rake task that cleans up the problem. That script could then be used by our infra team and whoever else ran GitLab release candidate x.y.
Ok, makes sense.
You might want to ask yourself if this is an infrastructure problem at all, because the application (gitlab-ce) created the mess, didn't it?
Right, but to fix it I thought we need infra help, therefor I chose this issue tracker.
@zj Do we need the infrastructure team to help with creating the rake task? Or is this something the backend development team can do?
-
@jacobvosmaer-gitlab I can do this. Will try to create this next week.
@zj great! I will be out of office so better not ask me to review. ;)
Reassigned to @zj
mentioned in commit test-nick/gitlab-ce@d6531ced
