We have read="false" set so that if we push any updates (triggering a application pool restart), uSync won't automatically go and rebuild everything from scratch. We don't want uSync to get run unless we specifically push changes in the uSync folder.
Thus, we have watchFolder="true" set so that uSync automatically reads and makes changes if we have pushed anything new to the uSync folder.
We have write="false" and attach="false" because we don't make structural or development changes on staging or live, and we neither want changes written to disk at application start or OnSave, OnDelete.
Provided I am using these properties as intended, I have some issues.
uSync doesn't seem to be running when pushing changes to the uSync folder (we use TeamCity). I tried manually recycling the app pool, and it still doesn't run. I'm starting to think that uSync will only watch for changes during the application's lifecycle? i.e. if you deploy some changes that reset the application, then uSync won't know what's changed and what's not, so will not do anything?
Placing a usync.once file in the uSync folder doesn't seem to be having the desired effect with this setup. Is this overriden by watchFolder="true"? UmbracoTraceLog.txt looks like:
2014-02-14 15:54:21,181 [10] INFO jumps.umbraco.usync.uSync - [Thread 1] uSync Starting - for detailed debug info. set priority to 'Debug' in log4net.config file
2014-02-14 15:54:21,196 [10] INFO jumps.umbraco.usync.uSync - [Thread 1] Watching uSync Folder for Changes
2014-02-14 15:54:21,196 [10] INFO jumps.umbraco.usync.uSync - [Thread 1] uSync Initilized
I can't figure out what causes uSync to place a usync.stop file in my uSync folder. This seems to happen sometimes.
That's an interesting one, the read features have sort of grown with the builds of usync, and I added the watch mainly for development convenience, to be honest I never really thought of it in these ways - but that doesn't mean its wrong :)
your right watch does only run when the app is running so it doesn't pick up things that change when the app pool restarts, It was original just an addendum to Read - so you didn't have to restart if you didn't need to. i don't think
I've maintained the logic correctly enough for setting read=false and watch=true.
watch currently skips the .once / .stop stuff, which is a mistake - it should behave the same as read
the once logic is in the RunSync Method that only (currently) fires when you have read=true. it does the following (at app startup)
if there is no usync.stop file then
do the full read from disk
if their is a usync.once file then
rename it from usync.once to usync.stop
If this happens you should see it in the logs if your log level is set to debug
i would suggest (but i don't know if it's possible in teamcity)
that you run with read=true and watch=true. and have a usync.stop file in the root of the usync folder.
when you deploy to the site(s) the last thing you do is rename the usync.stop file to usync.once - then is the app pool doesn't restart the watch method will fire, if the app pool does restart usync will build the changes and put the stop file in.
I have updated the package to 1.5.8.2 to make file watching work the same way as read so this should be possible (assuming you can write/rename the stop file when you deploy)
if this doesn't work/isn't suitable - then maybe there is something else that can be added to help when using teamcity ? i am open to suggestions.
I think there are probably a lot of different ways to achieve what we need, and I'm not sure that uSync necessarily needs anything new to do this. But if it was easy and perhaps useful for others, I suppose if uSync could keep a hash of the uSync folder through the restarts that would be pretty cool :)
With the changes to 1.5.8.2 you mentioned (thanks!), putting in read=true and watch=true whilst keeping a usync.stop file in the folder might be the simplest answer here. Then we just need a way of choosing when to activate uSync by renaming that file to usync.once. I suppose this could just be a build parameter added in TeamCity, or a manual rename on the actual target filesysytem.
I probably need to work on my MSBuild skills, as I wonder if it's possible to write some logic that basically says "If there are any changes to the uSync folder, then delete usync.stop and write usync.once". That would remove the manual step. What I was trying to do was make it so that developers didn't really have to think about anything other than pushing changes in the uSync folder to commit to making them go to stage/live. :)
Read="false" and usync.once (1.5.8.1)
Hi all.
I some questions about the process, and perhaps something that I'm either misunderstanding, or doesn't seem to be working correctly.
On our staging and live environments, we have uSyncSettings.config set up as follows:
We have
read="false"set so that if we push any updates (triggering a application pool restart), uSync won't automatically go and rebuild everything from scratch. We don't want uSync to get run unless we specifically push changes in the uSync folder.Thus, we have
watchFolder="true"set so that uSync automatically reads and makes changes if we have pushed anything new to the uSync folder.We have
write="false"andattach="false"because we don't make structural or development changes on staging or live, and we neither want changes written to disk at application start or OnSave, OnDelete.Provided I am using these properties as intended, I have some issues.
Placing a
usync.oncefile in the uSync folder doesn't seem to be having the desired effect with this setup. Is this overriden bywatchFolder="true"? UmbracoTraceLog.txt looks like:I can't figure out what causes uSync to place a
usync.stopfile in my uSync folder. This seems to happen sometimes.Finally, thanks Kevin for your work on uSync.
Hi
That's an interesting one, the read features have sort of grown with the builds of usync, and I added the watch mainly for development convenience, to be honest I never really thought of it in these ways - but that doesn't mean its wrong :)
your right watch does only run when the app is running so it doesn't pick up things that change when the app pool restarts, It was original just an addendum to Read - so you didn't have to restart if you didn't need to. i don't think I've maintained the logic correctly enough for setting read=false and watch=true.
watch currently skips the .once / .stop stuff, which is a mistake - it should behave the same as read
the once logic is in the RunSync Method that only (currently) fires when you have read=true. it does the following (at app startup)
If this happens you should see it in the logs if your log level is set to debug
i would suggest (but i don't know if it's possible in teamcity)
that you run with read=true and watch=true. and have a usync.stop file in the root of the usync folder.
when you deploy to the site(s) the last thing you do is rename the usync.stop file to usync.once - then is the app pool doesn't restart the watch method will fire, if the app pool does restart usync will build the changes and put the stop file in.
I have updated the package to 1.5.8.2 to make file watching work the same way as read so this should be possible (assuming you can write/rename the stop file when you deploy)
if this doesn't work/isn't suitable - then maybe there is something else that can be added to help when using teamcity ? i am open to suggestions.
Kevin, that's very enlightening, thanks!
I think there are probably a lot of different ways to achieve what we need, and I'm not sure that uSync necessarily needs anything new to do this. But if it was easy and perhaps useful for others, I suppose if uSync could keep a hash of the uSync folder through the restarts that would be pretty cool :)
With the changes to 1.5.8.2 you mentioned (thanks!), putting in read=true and watch=true whilst keeping a usync.stop file in the folder might be the simplest answer here. Then we just need a way of choosing when to activate uSync by renaming that file to usync.once. I suppose this could just be a build parameter added in TeamCity, or a manual rename on the actual target filesysytem.
I probably need to work on my MSBuild skills, as I wonder if it's possible to write some logic that basically says "If there are any changes to the uSync folder, then delete usync.stop and write usync.once". That would remove the manual step. What I was trying to do was make it so that developers didn't really have to think about anything other than pushing changes in the uSync folder to commit to making them go to stage/live. :)
is working on a reply...