Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-20919

Conan repository v1 search endopoint returns incorrect revision

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: 4 - Normal
    • Resolution: Unresolved
    • Affects Version/s: 6.12.2, 6.16.1
    • Fix Version/s: None
    • Component/s: None
    • Severity:
      Medium

      Description

      It looks that after uploading different revisions of a Conan package to Artifactory and the searching that package through Conan with revisions disabled in the client, Artifactory is returning an incorrect revision (it should return the last one).

      As stated in the last paragraph this issue happens for the search when multiple packages were uploaded using revisions and one client with revisions disabled searches for those. With revisions enabled in the client it works OK (only the v1 endpoint gives the incorrect result).

      To reproduce (tested with Artifactory 6.12):

      # activate revisions
      ➜  conan config set general.revisions_enabled=1 
      # create a dummy package
      ➜  conan new dummy_pkg/0.1
      # create some new revisions and upload to artifactory
      ➜  echo "# new revision" >> conanfile.py && conan create . && conan upload dummy_pkg/0.1@ -r artifactory-local --all --force -c
      ➜  echo "# new revision" >> conanfile.py && conan create . && conan upload dummy_pkg/0.1@ -r artifactory-local --all --force -c
      ➜  echo "# new revision" >> conanfile.py && conan create . && conan upload dummy_pkg/0.1@ -r artifactory-local --all --force -c
      ➜  echo "# new revision" >> conanfile.py && conan create . && conan upload dummy_pkg/0.1@ -r artifactory-local --all --force -c
      

      Now you can check the repo to see all the uploaded revisions:

      ➜  conan search dummy_pkg/0.1@ -r artifactory-local --revisions
      Revisions for 'dummy_pkg/0.1' at remote 'artifactory-local':
      58f0498b9da9a3d7e7f83d4e9abad989 (2019-12-20 16:26:44 UTC)
      1a43e98260595e81eac6bd898af33371 (2019-12-20 16:26:40 UTC)
      91015b7bf5cb76b364cecba0d4685a77 (2019-12-20 16:26:35 UTC)
      6aaa651a1a9dbece815cb8b06db98393 (2019-12-20 16:26:29 UTC)
      

      Finally, deactivate revisions and search for the package:

      ➜  conan config set general.revisions_enabled=0  
      ➜  conan search dummy_pkg/0.1@ -r artifactory-local
      Existing packages for recipe dummy_pkg/0.1:
      
      Existing recipe in remote 'artifactory-local':
      
          Package_ID: 103f6067a947f366ef91fc1b7da351c588d1827f
              [options]
                  shared: False
              [settings]
                  arch: x86_64
                  build_type: Release
                  compiler: apple-clang
                  compiler.libcxx: libc++
                  compiler.version: 11.0
                  os: Macos
              Outdated from recipe: True
      

      It is marked as outdated because the search endpoint for v1 is returning a random revision that does not correspond to the last one. For this case it should return the revision with id 58f0498b9da9a3d7e7f83d4e9abad989 but it is returning the one with id: 91015b7bf5cb76b364cecba0d4685a77.

      That can be checked calling directly to the endopoint:

      http://localhost:8081/artifactory/api/conan/conan-local/v1/conans/dummy_pkg/0.1/_/_/search

      That is returning in this case:

      {
        "103f6067a947f366ef91fc1b7da351c588d1827f" : {
          "settings" : {
            "os" : "Macos",
            "compiler.libcxx" : "libc++",
            "arch" : "x86_64",
            "compiler" : "apple-clang",
            "build_type" : "Release",
            "compiler.version" : "11.0"
          },
          "options" : {
            "shared" : "False"
          },
          "requires" : [ ],
          "recipe_hash" : "91015b7bf5cb76b364cecba0d4685a77"
        }
      }
      

      IMPORTANT NOTE: After running several tests, looks like Artifactory is sorting the revisions alphabetically and returning the latest in that order, not the latest that was uploaded. That's why it returns 91015b7bf5cb76b364cecba0d4685a77 in this example.

      This same problem happens in bintray too, but there the remote returns a different random revision each time the endpoint is called.

      Some more details in the issue in the Conan repo: https://github.com/conan-io/conan-center-index/issues/200

      Also reported by Conan users:

      https://github.com/conan-io/conan/issues/6873

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            carlosz Carlos Zoido Benítez
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:

                Sync Status

                Connection: RTFACT Sync
                RTMID-20919 -
                SYNCHRONIZED
                • Last Sync Date: