Closed ppanyukov closed 8 years ago
@ppanyukov Are you on visualstudio.com or using on-premises TFS?
@ericsciple on visualstudio.com, using git repos.
Great! Can you try the new vsts-agent that is deprecating the vso-agent?
That is certainly planned, but at the moment we are stuck with this one for the moment. We have quite sophisticated setup, not as easy to swap things out .
hmm, I'm no longer able to reproduce this. Neither with 0.4.5 version or with the latest 0.6.5. Very odd. Maybe something went corrupt at some point and that's what caused the issues. I have the logs _diag logs if anyone is interested. (still don't understand why we do hashing differently though).
Probably can close for now.
OK - it's also fixed in the replacement agent. You should switch over https://github.com/Microsoft/vsts-agent
The builds we are running always do new clone of repos. On our system this is due differences in hash code calculations between
plugins/build/sourceMappings.js
andscm/lib/scmprovider.js
.The result is:
_work/NN
directory.The code in question:
plugins/build/sourceMappings.js:: https://github.com/Microsoft/vso-agent/blob/master/src/agent/plugins/build/sourceMappings.ts#L139
scm/lib/scmprovider.js: : https://github.com/Microsoft/vso-agent/blob/master/src/agent/scm/lib/scmprovider.ts#L37
I have confirmed that changing
plugins/build/sourceMappings.js
to only useendpoint.url
for hashing resolves the issue once the_work/SourceRootMapping
are deleted (which forces to created them).This behaviour is a bit odd because I'm almost certain everything used to work correctly in the past. Not 100% sure though.