Library Packages all show Publish date as the day a migration occurred

Legacy Uncategorised
1

I recently migrated my Octopus instance between servers by copying/restoring the database and bringing over all the package files. Currently, every version of every package shows it has a Publish date of the day I performed the migration. I need this information to accurately reflect when they were originally published. How can I correct this information? Will export/import work? Can I do a replace on the JSON column in the NuGetPackage table? Will the Octopus service change this information to the Windows file creation date when it reindexes? Do I need to recopy all of my packages while preserving the file creation date?

2

Hi Steve,

Thank you for getting in touch! The timestamps of the packages get indexed in the repository on the server. By moving your package to a new server means the timestamps are lost.

However, a workaround would be to delete your packages, zip everything up, move it to the new server, unzip, and then re-index. That should keep the timestamps intact for the move.

Let me know how you go!

Kenny

3

I’ll give that a try and let you know the results.

In the meantime, I ran a script to update the Date Created value to match the original values on the deprecated server and restarted the Octopus Deploy service with the intent for it to re-index the packages, but the dates still show the date they were copied to the current server.

4

I’ve zipped all the packages and brought them over to the new server, replaced the existing ones, and restarted the Octopus Deploy service. All packages still show the incorrect date.

5

Hi Steve,

When we tested this ourselves the zip process preserved the timestamp on the destination server. If that did not work for you then another option will be something like Robocopy where you can tell it to preserve the timestamps. That is what is happening here.
You cannot update the database, as ever index (when the service is restarted) is just going to overwrite that as you can overwrite packages, we need to check each time.

if you cannot find a way to copy and preserve the file timestamps then you will not be able to get this information on the new server. We need to use this for the different formats that we use as not all of them have metadata for us to read.

Vanessa

6

Hi Vanessa,

The time stamps are preserved on the files themselves when zipping the packages, but the publish date isn’t changing.

7

Hi Steve,

Octopus uses the file timestamp as the publish date when completing the index of the repository. It needs to stay updated as you can overwrite files that already exist. A direct copy or zip that does not preserve the timestamp on the file from the origin server will mean all the dates are overwritten with the updated time.

The way to maintain your publish dates after the migration would have to be done by preserving the timestamps in your file system. We’ve seen that there are tools like Robocopy and 7zip that could possibly preserve the timestamps, though we’re not too familiar with these tools.

Sorry it’s not better news!

Kenny

8

What I’m saying is that I zipped the files and copied them over, confirmed the timestamps were preserved, then overwrote the existing packages. The Octopus Deploy service was restarted and the Publish date didn’t update. I tried deleting packages and restarting the service again, then replaced the deleted files and restarted the service again. The Publish date is still incorrect.

9

Please, I need a resolution to this problem. I’m being asked for status updates every other day and am now going a week between responses. This is a production issue affecting my entire development department and the users are very unhappy with the length of time this is taking to resolve.

10

Hi Steve,

Thanks for following-up. I’m helping out on the ticket and I’ve been reading/scanning all the code related to this. From the code, it appears that if a package already has been index (i.e. it exists in Octopus database table [NuGetPackage]) then it’s published date time offset won’t be updated. I did a quick test of this and it appear to keep the updated published date time offset.

NOTE: If you are going to update your Octopus database, it’s critically important that you have a backup of our database and master key. Please visit http://docs.octopus.com/display/OD/Backup+and+restore for more information.

That said, I’m pretty sure you would have everything backed up after doing the migration but it’s better to be safe than sorry. :slight_smile:

I’d suggest trying this out on a couple packages to ensure it’s consistent with my results and if it does, you should be able to script this to correct all the values. Specifically, I did the following steps.

  • Stop the Octopus Windows Service using the Octopus Manager.
  • Execute SELECT * FROM NuGetPackage; against your Octopus database in Sql Management Studio.
  • Copy the JSON string from a package you would like to update and pasted it into your favourite text editor (I used Atom) and edit the Published date time offset.
  • Execute UPDATE NuGetPackage SET JSON = 'YourUpdatedJsonString' WHERE Id = 'YourPackageId'; in Sql Management Studio with the appropriate values.
  • Start the Octopus Windows Service using the Octopus Manager.

Let me know how you go!

Thanks

Rob

11

Updating the database directly has made my publish dates accurate and has resulted in a minor amount of celebration among the developers. Here is the PowerShell script I used for the update, which probably isn’t written as efficiently as it could be, but did the job:

$dbserver = DatabaseServerName
$packages = Invoke-Sqlcmd -query 'select * from NuGetPackage' -ServerInstance $dbserver -Database OctopusDeploy
foreach ($package in $packages) {
    # uncomment below line for test output
    #write-host "Old JSON:"$package.JSON
    $json = ConvertFrom-Json $package.JSON
    # using replace method to change timezone offset to 0, some packages will be off by an hour due to DST. Future people: maybe convert to UTC, then update the end of the string.
    $fileDate = (get-item "\\\DEPLOYSERVER\PATH\Octopus\Packages\$($package.packageid)\$($package.id)$($json.FileExtension)" | select CreationTime).CreationTime.AddHours(4).ToString("o").Replace("0000000-04:00","0000000+00:00").Replace("0000000-05:00","0000000+00:00")
    $json.Published = $fileDate
    $json = ConvertTo-Json $json -Compress
    # uncomment below line for test output
    #write-host "New JSON:" $json
    $query = "update NuGetPackage SET JSON='$json' where Id='$($package.Id)'"
    # uncomment below to make work happen, comment to test values
    Invoke-Sqlcmd -ServerInstance $dbserver -Database OctopusDeploy -Query $query
    }
12

Hi Steve,

Thanks following-up and sharing your script. It’s great to hear you got it working.

Happy deploying! :slight_smile:

Rob

13

Notice:

This issue has been closed due to inactivity. If you encounter the same or a similar issue and require help, please open a new discussion (if we asked for logs or extra details in this thread, consider including them in the new thread). If you are the creator of this thread and believe it should not be closed let us know via our support email.