conan: [bug] conan upload fails on 1.22.0

Summary

A Jenkins job that builds a package and uploads it to Artifactory was working with Conan 1.21.2 but is now failing to upload the package with Conan 1.22.0.

No errors are displayed in the Jenkins log (see below); I see the recipe successfully uploaded to Artifactory but the package itself does not end up there. What then happens is that the next build order thinks the package needs to get built (because it did not end up on Artifactory) and we end up in an endless loop of Jenkins trying to build the package.

All packages are using the same Jenkins code to build (see the ‘steps to reproduce’ section below to see what the Jenkins pipeline code essentially does). All packages - except for the application - are uploading successfully, making this even more bizarre. The only significance here is that the application package is what the build order was generated for.

I reverted back to 1.21.2 and the upload/process in general works again.

Environment Details

  • Operating System+version: Red Hat Enterprise Linux 7.4
  • Compiler+version: gcc4,gcc7
  • Conan version: 1.22.0
  • Python version: 3.7
  • Jenkins version: 2.164
  • Jenkins Artifactory plugin version: 3.5.0

Steps to reproduce

The Jenkins job is essentially doing the following:

  1. conan config install
  2. conan create
  3. conan upload

Pipeline stage:

            stage("Upload Artifactory"){
                steps {
                    script {
                        String command = "upload ${params.name_version} --remote ${serverName} --all --confirm"
                        buildInfo = client.run(command: command)
                        buildInfo.env.collect()
                        server.publishBuildInfo buildInfo
                    }
                }
            }

Logs

Jenkins: 13:01:44 [appX_conan_1.22.0_test] $ sh -c "conan upload appX/1.0.0 --remote 2c88c345-e261-4017-8b7a-8602054ed1a4 --all --confirm " 13:01:46 Uploading to remote ‘2c88c345-e261-4017-8b7a-8602054ed1a4’: 13:01:46
Uploading appX/1.0.0@user/conan_1.22.0_test to remote ‘2c88c345-e261-4017-8b7a-8602054ed1a4’ 13:01:46 Compressing recipe sources… 13:01:51 Uploading conan_sources.tgz -> appX/1.0.0@user/conan_1.22.0_test 13:01:51 Uploading conanfile.py -> appX/1.0.0@user/conan_1.22.0_test 13:01:51 Uploading conanmanifest.txt -> appX/1.0.0@user/conan_1.22.0_test 13:01:51
Uploaded conan recipe ‘appX/1.0.0@user/conan_1.22.0_test’ to ‘2c88c345-e261-4017-8b7a-8602054ed1a4’: http://XXXX/artifactory/api/conan/conan-local 13:01:51
Uploading package 1/1: b198f5cd74d7ad0b383f92c66ed997ce6f0531a1 to ‘2c88c345-e261-4017-8b7a-8602054ed1a4’ 13:01:51 Compressing package… 13:03:44 [appX_conan_1.22.0_test] $ sh -c "conan_build_info /scratchnobackup/devops_jenkins/workspace/appX_conan_1.22.0_test/conan_home/conan_log.log --output /scratchnobackup/devops_jenkins/workspace/appX_conan_1.22.0_test@tmp/artifactory/conan8339048503017901616build-info " [Pipeline] collectEnv [Pipeline] publishBuildInfo 13:03:47 Deploying build info to: http://XXXX/artifactory/api/build 13:03:47 Deploying build descriptor to: http://XXXX/artifactory/api/build 13:03:48 Build successfully deployed. Browse it in Artifactory under http://XXXX/artifactory/webapp/builds/appX :: conan_1.22.0_test/2

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 29 (13 by maintainers)

Commits related to this issue

Most upvoted comments

The problem is that it’s hard to make a unit test for it since the tick timeout is 30 seconds by a const variable inside the Progress Bar file, so we have no means of changing it in tests.

I have been able to write a test patching that variable (python can be magic for these things 😄 ). It seems this was also causing https://github.com/conan-io/conan/issues/6330 issues reported by @KerstinKeller, as very lengthy compressions will also crash due to this bug leaving the conan_package.tgz.dirty state, so the new test covers both uploads and compression, hopefully both bugs are gone now.