Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fake.Deploy fail investigation #49

Closed
caprofage opened this issue Jul 30, 2012 · 4 comments
Closed

Fake.Deploy fail investigation #49

caprofage opened this issue Jul 30, 2012 · 4 comments

Comments

@caprofage
Copy link

Hello, I'm trying to use FAKE as continuous delivery system for the set of my apps (web sites, services, db scripts). When I integrate pushing of assembled nuget package to the server in CC.NET deployment process, and if deploy scripts for server side execution fails, is there any way to find out what went wrong? May be there's some kind of logging can be provided?

Thx in advance.

@ronnieholm
Copy link
Contributor

I'm not sure I follow you. Do you have CC.NET call out to FAKE? And then you're missing output from the build process?

@caprofage
Copy link
Author

I have CC.NET project, that builds and packs built output into the nuget package and pushes this package to the remote machine. All this staff is made by msbuild script executed by CC.NET.

Remote machine has Fake.Deploy ran as a service on it. When Fake.Deploy tries to publish pushed package it fails for some unknown reason. My question is how can I find out what happened. When Fake.Deploy ran as a console I can see fail reason in console.

@forki
Copy link
Member

forki commented Dec 11, 2012

It seems this is the same bug like the newest from the mailing list.

@colinbull : "I'll get onto this asap.. " ;-)

colinbull added a commit to colinbull/FAKE that referenced this issue Dec 11, 2012
FSI didn't seem to like executing the scripts from the system32 folder
despite LocalSystem having full access to this folder. I have added a
workDirectory applicationSetting to the Fake.Deploy agent and it now
appears to fix the problem when it is set to a path outside of System32.
Additionally I have made detecting FSI when only Fsharp 3.0 is installed
possible, as well as making the detection of the ProgramFile based on
CPU architecture more robust.
@forki
Copy link
Member

forki commented Dec 12, 2012

seems fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants