COU-655 - Files are not committed to git

Created by Claus Jensen 09 Mar 2018, 12:15:30 Updated by Robert Copilau 21 Mar 2018, 12:10:49

Relates to: COU-652

Subtask of: UAASSCRUM-1375

There's a regression issue in the latest commits of Courier, causing .courier files not to be committed to git on Cloud.

Recent commits:

are related to adding files to git. This doesn't work which means that even though the files are written to disk, they are not really "persisted" correctly.


Mikulas Tomanka 15 Mar 2018, 14:14:06

In order to reproduce this I've tried:

*On rainbowsrock create a project with sku: oldie update ccourier to latest from dev-v7 (latest commits mentioned in the issue headline have not been pushed into a git tagged release.) ** Add a user, create a document type. Both of these resulted in a .courier file added to fs and git. ** Could see the events fired by the messaging module on the webworkers:

[Thread 262] - CopyAndCommitHandler: Website '5e58bb98-ed91-43b7-bcd4-ecdc36b034fd'|'32cb15ad-1d72-4148-a2f9-16a171647cbb', Branch 'master (refs/heads/master)' - Commit Result: Commit Result: Files committed to 'master (refs/heads/master)' in 'C:\inetpub\temp\DWASFiles\Sites\5e58bb98-ed91-43b7-bcd4-ecdc36b034fd\VirtualDirectory0\site\repository' because Success. IsCurrentRepositoryHead? True (Checkout master-branch? False) Current Revision: dde466181b53f2959705e9395c6497ea08c73672, Previous Revision: 77e9839d8fbda848c6decc9464eaaa5127fe259c. Files: C:\inetpub\temp\DWASFiles\Sites\5e58bb98-ed91-43b7-bcd4-ecdc36b034fd\VirtualDirectory0\site\repository\data\Revision\documenttypes\096d3bd7-e79e-4393-acf6-925090665363.courier

*On s1 create a project with sku 7.5.0, update to latest courier ** Could see .courier files being added to fs and commited to git for new document type created.

I say can't reproduce, however I might not know how to upgrade courier... (1. checkout tag I'm upgrading from, 2. build, 3. wait a minute 4. checkout newest commits 5. build 6. copy/paste freshest dlls by edited time into the project.)

Robert Copilau 16 Mar 2018, 07:31:57

I'll give this a try.

Mikulas Tomanka 16 Mar 2018, 07:36:40

Also it seems like this is just a duplicate of this one?

Claus Jensen 16 Mar 2018, 12:22:42

It isn't a duplicate :) the other task was a spike to see if there was actually an issue. This task was then created based on that spike to be scheduled for sprint work.

I've located the issue and fixed it here:

Turns out there was a couple of issues here. First of all this seemed to not really work that well with the assembly bindings and the modules we force-transform into Cloud sites on deployment (the messaging module). So we will need to make sure we remove this transform - and also make sure to do a remove-transform in case someone for some reason has added this in, in their web.config manually. I have no idea why you would do this but I wouldn't be surprised if someone had done it by accident...

Part two: The MessagingService was not getting injected into the DeleteItemTask which means that the DeleteItemTask would just hit null exceptions when trying to call methods on this in Cloud.

Part three: There was no null checks in the code using the messaging module. This is fine when it is running on Cloud, but these tasks will (and should) actually also run in local environments. The MessagingModule is just the part responsible for syncing file changes to git in Cloud, but on local we would still want saves/deletes of doctypes reflected in file operations on disk... although the git-part is done manually instead of the MessagingModule.

So when this code was run on local - it would hit null exceptions when trying to submit messages to the module.. which caused the code to stop and then files would not always get handled as they should.

Robert Copilau 20 Mar 2018, 13:38:31

Hey @claus, could you provide some test notes as I am not quite sure if I did this right.

What I did: *Checked out on COU-655 *Built courier *RunBuild.bat *Copied bin and App_plugin of the build result *Pushed to cloud

Now I have a project with the updated version of courier.

Test results: *On cloud creating a document type would take up to 5 minutes for the messaging service to push it to git. *On cloud deleting a document type would not persist on local, same for local -> cloud.

All feels like a mess so it might be that I have skipped a step while updating courier.

Robert Copilau 21 Mar 2018, 12:09:19

After talking to Claus and removing messaging module from web.cofing, I can confirm that git commands works once more. Merging.

Priority: Normal

Type: Bug

State: Fixed




Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version: 3.1.7

Sprint: Sprint 81

Story Points: 1

Cycle: 8