Can't delete tag from tagsets after migration

Legacy Scale
1

Hi,

We’re on Octopus 3.8.5 with multi-tenant deployments enabled. I’ve attempted to migrate a project from our test server to our production server using Octopus.Migrator.

I’ve noticed, that following the migration, I can no longer delete a tag from one of the imported tagsets in production. I believe this is because the migrator has jumbled up the IDs of the tagsets at import.

For example in the exported JSON file the tagset ID to tag reference is correct:

 "Id": "TagSets-2",
"Name": "Products",
"Description": "The core product(s) the customer has signed for",
 "SortOrder": 1,
 "Tags": [

    {
      "Id": "TagSets-2/Tags-41",
      "Name": "Scheduler",
      "Description": null,
      "Color": "#227647",
      "SortOrder": 0
    }

However, if I look at the API output for tagsets, I can see it has been imported as:

 "Id": "TagSets-3",
 "Name": "Products",
 "Description": "The core product(s) the customer has signed for",
 "SortOrder": 1,
 "Tags": [

        {
          "Id": "TagSets-2/Tags-41",
          "CanonicalTagName": "Products/Scheduler",
          "Name": "Scheduler",
          "Description": null,
          "Color": "#227647",
          "SortOrder": 0
        }

The ID of the tagset no longer matches the reference in the tag or the underlying tag has not been updated with the new ID.

In the import log I see:
2017-02-06 14:12:30.6631 1 DEBUG Insert took 0ms in transaction ‘’: INSERT INTO dbo.[TagSet] (Name, SortOrder, Id, Json) values (@Name, @SortOrder, @Id, @Json)
2017-02-06 14:12:30.6631 1 DEBUG Created TagSet “Database” (TagSets-3 -> TagSets-2)
2017-02-06 14:12:30.6788 1 DEBUG Insert took 0ms in transaction ‘’: INSERT INTO dbo.[TagSet] (Name, SortOrder, Id, Json) values (@Name, @SortOrder, @Id, @Json)
2017-02-06 14:12:30.6788 1 DEBUG Created TagSet “Products” (TagSets-2 -> TagSets-3)

Please can you advise if this is a bug and how I can safely restore our configuration? Does this issue only relate to tag sets? I have a database backup to restore back to if necessary.

In addition to the above problem, I’ve noticed your migrator documentation states that the instance is a mandatory parameter but it is optional (i.e. using the default instance).


Best regards,
Blair.

2

Hi Blair,

We apologize. That is certainly a bug.

I believe it will only effect TagSets. I have a created an issue for this, and we will resolve it as a priority (within the next few days).

In the meantime, if it would help, I can write a SQL script which will update the Tag IDs for you. Just let me know if this would be of assistance?

Again, we sincerely apologize for the inconvenience.

Also, I have marked that parameter as optional on those pages.

Regards,
Michael

3

Hi Michael,

Thanks for looking into this and for getting back to me. Thanks for the offer but there is no need to write a script as I’ll clean up the instance. It’s better to have your time working on other more important things :slight_smile:

Cheers,
Blair.