conan: [bug] scm Attribute fails to clone commit
I feel like this is very related to https://github.com/conan-io/conan/issues/5587 “scm Attribute fails to clone tag” but in our case we are using version 1.19.2. which according to the note in #5587 “Conan 1.18.1 has been released with the fix for this issue!” should contain the fix.
Our old conanfile that worked in v1.16.1 did:
scm = {"type": "git",
"url": url, # location of source to build
"revision": commitAtVersion}
But now after upgrading to v1.19.2 it failed to check out any sources on our build servers. But if we comment out the scm
section and add:
# Testing: don't use scm in case it's broken https://github.com/conan-io/conan/issues/5587
def source(self):
git = tools.Git()
os.remove("debian/changelog")
#git.clone(self.url, branch=self.commitAtVersion)
git.clone(self.url, branch="master")
git.checkout(self.commitAtVersion)
then it works also in v1.19.2
Our commitAtVersion was a git commit string of the form e.g. 8aa1740b
Environment Details (include every applicable attribute)
- Operating System+version: Windows Server 2012 R2
- Compiler+version: VS2015
- Conan version: 1.19.2
- Python version: N/A conan exe installer
Steps to reproduce (Include if Applicable)
Update code from 1.16 to 1.19 and rebuild an existing recipe that uses the scm plugin while requesting a specific git commit.
Logs (Executed commands with output) (Include/Attach if Applicable)
(Sadly) silent fail of the git clone to actually check out any files, build fails shortly afterwards as it can’t find required .sln file to build:
pal/1.41.0@PORT/stable: Configuring sources in E:\nX\nX_nightlybuild\workspace\Conan_pipeline\.co\14e36c\1
pal/1.41.0@PORT/stable: Getting sources from url: 'git@bbgithub.dev.bloomberg.com:nx/pal.git'
[...]
The following files were specified on the command line:
vstudio/pal/pal.sln
These files could not be found and will not be loaded.Microsoft (R) Build Engine version 14.0.25420.1
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (7 by maintainers)
With @lasote 's added verbose logging for the
scm
operation and his helpful analysis via email, we’ve established that the issue has to do with a wrapper script we had on our Jenkins server used to invoke git with the correct credentials, that unfortunately wasn’t properly returning the %error_level% returned from the git invocation.I hope we didn’t waste too much of your time – I think the newly added optional verbose logging of the scm plugin operation will help everyone in the future.