search

microsoft / vso-agent

Visual Studio Team Services and TFS agent for Mac OSX and Linux
MIT License
131 stars 56 forks source link

Setting the repository parameter "Clean" = true, doesn't clear the workspace #303

Closed JKennedy24 closed 8 years ago

JKennedy24 commented 8 years ago

So by setting Clean = true, my understanding is that it should re use the same workspace but this isnt the case and it creates a brand new one on each run.

(my build does infact fail at building my project time, I don't know whether this affects this issue)

bryanmacfarlane commented 8 years ago

Are you using git or tfsvc?

JKennedy24 commented 8 years ago

tfsvc

ericsciple commented 8 years ago

That's currently by design. Scorch isn't available, so the current approach is recreate the workspace.

JKennedy24 commented 8 years ago

I am a Xamarin developer developing for iOS, Android, UWP so continuous integration is great for me to keep ontop of these 3 projects. but recreating a workspace every time means my Mac build server HD is filling up and my tfs workspaces look silly

bryanmacfarlane commented 8 years ago

yes, that's a bad bug. it should tf scorch or if not available, delete the dir if clean. on windows we scorch and if git we clean -fdx and reset head.

yacaovsnc commented 8 years ago

What is your scenario? "Clean = true" currently should do those two things:

  1. delete the dir -- so I need to find out why your HD is filling up.
  2. delete the workspace and recreate -- can you please be more specific about "tf sworkspaces look silly"? It should have removed every out of date workspace.
JKennedy24 commented 8 years ago

OK so some more info. I am only experiencing this on my mac. (Windows works as expected as you stated) I set the property "Clean = True" in the repositories tab. behavior I'm seeing is Brand new directory created, brand new workspace created. Prepare Workspace log shows:

2016-05-11T14:44:03.207Z: running clean 2016-05-11T14:44:03.207Z: workspace name: ws_12_13 2016-05-11T14:44:17.632Z: getting code 2016-05-11T14:44:17.633Z: workspace name: ws_12_13 2016-05-11T14:44:22.837Z: Creating workspace ws_12_13

ever increasing the first number each run.

Hope that helps let me know if you need any more info

JKennedy24 commented 8 years ago

Although in addition to that. I am actually using the Windows Build agent provided by VSTS online

yacaovsnc commented 8 years ago

Are you running the same build definition in a pool that has both windows and mac build agents?

The workspace is per machine, so if you run a build on a Windows build agent, it will create one workspace; but when the same build is run on Mac, you should see a new workspace created.

JKennedy24 commented 8 years ago

Yes I the workspaces work and that there should be one mapped to on Windows and one mapped on Mac. So let me clarify with whats happening. I am running the agent as a service so....

Today: I do 3 seperate builds on Windows build agent. End Result After all 3 builds: 1 directory created, 1 workspace created.

I do 3 seperate builds on my Mac build agent: End Result after all 3 builds: 3 directories created, 3 workspaces created.

The problem is that the "Clean" setting is being ignored on the mac build agent

JKennedy24 commented 8 years ago

and yes my build definition is running in a pool that contains mac and windows build agents

yacaovsnc commented 8 years ago

2016-05-11T14:44:03.207Z: running clean

Clean flag isn't ignored. The problem maybe because we are getting different source folder mapping each time. The workspace format is "ws_agentId_sourcefolder" -> I assume the middle number never incremented in all those three runs and the last digit kept incrementing?

When we detect clean flag, we try to delete this path calculated from the source folder id, and recreate the workspace, but if the source folder id changed, we have no idea what was the original workspace path and name.

JKennedy24 commented 8 years ago

If the format is "ws_agentId_sourcefolder" then this just got even stranger. It would make more sense if it was "ws_sourcefolder_agentId". below is a screen shot of my TFS workspaces output. GMPs = Mac Build Agent GMP10 = Windows build agent.

The two windows build agent w/s are expected because of two different build definitions. as for the mac ones these are all from the same build agent tfs

yacaovsnc commented 8 years ago

Sorry my bad! I meant the other way, it's ws_sourcefolderid_agentid!

This does indicate we are getting different source folder every time. I will ask Eric and Bryan about that.

ericsciple commented 8 years ago

What version of the node agent are you using?

Can you run a build for a definition, capture the _work/sourcerootmappings folder, queue the same definition, capture that folder again? I can't remember if the GC folder is within the sourcerootmappings folder or sibling, please capture that both times as well (if one exists). The diff between the two will likely reveal why it's not reusing the same folder. Or you can zip and email to and I can analyze (at microsoft com).

ericsciple commented 8 years ago

What version of the node agent are you using?

ericsciple commented 8 years ago

Sorry I missed your question in the email. The version is in the package .json, e.g. "version": "0.6.5",

ericsciple commented 8 years ago

It looks like this may be the same issue: https://github.com/Microsoft/vso-agent/issues/305

ericsciple commented 8 years ago

Can you try out the new agent (different repo): https://github.com/Microsoft/vsts-agent

ericsciple commented 8 years ago

@JKennedy24

JKennedy24 commented 8 years ago

@ericsciple I've installed the new agent and at the "Get Sources" stage I'm getting the following error:

/Users/chrisjohn/myagent/externals/tee/tf eula -accept Exit code 13 returned from process: file name '/Users/chrisjohn/myagent/externals/tee/tf', arguments 'workspaces -format:xml -collection:https://gmpsoftware.visualstudio.com/ -login:_,**** -noprompt'.

ericsciple commented 8 years ago

@JKennedy24 On the variables tab of your definition, can you set system.debug to true and run the build again?

I would expect some output from the command (in addition to non-zero exit code). The output of the command should be dumped already when it fails... system.debug will reveal the output regardless of whether it fails.

JKennedy24 commented 8 years ago

@ericsciple I have set debug = true and put the logs here: http://pastebin.com/i5TnXdjM

ericsciple commented 8 years ago

@JKennedy24 i've got a local repro. digging in now. sorry for the inconvenience.

ericsciple commented 8 years ago

The execute bit was missing on my externals/tee/tf. We shifted around how the externals were pulled in at build time, I'll have to go back and look at what the difference is.

As a workaround, it looks like you should be able to chmod +x /Users/chrisjohn/myagent/externals/tee/tf

JKennedy24 commented 8 years ago

I'm not sure how to use the workaround. I don't mind hanging on for a fix as the iOS build isnt vital at the moment. Let me know if you want me to try anything out

bryanmacfarlane commented 8 years ago

This is fixed in the latest drop: 2.101.0 https://github.com/Microsoft/vsts-agent