Uploaded image for project: 'Infrastructure'
  1. Infrastructure
  2. INFRA-1763

Neither [RELEASE] nor [INTEGRATION] are working when downloading packages from the Artifactory repo.

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Not A Defect
    • Component/s: artifactory
    • Labels:
      None
    • Similar Issues:

      Description

      Neither [RELEASE] nor [INTEGRATION] are working when downloading packages from the Artifactory repo.

      E.g.

       http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/swarm-client/[RELEASE]/swarm-client-[RELEASE].jar

      fails. Using specific version numbers works:

      http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/swarm-client/3.13/swarm-client-3.13.jar 

      It stopped working on or about 24/8 according to my build logs. I returned from holiday to find things broken. I verifed that the calls fail on several packages using Postman.

      Thanks.

       

        Attachments

          Activity

          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Few notes...

          1. You should not be using Jenkins Infra as a 24/7 source of binaries. Our infrastructure may be under maintenance. Also, there may be mirror issues
          2. You should not download files from HTTP. It makes you open to MITM attacks, especially in this case when you download binaries to be executed
          3. If you need to download the binary on a regular basis, it is served from your Jenkins master starting from Swarm Plugin 3.10: ${JENKINS_URL}/swarm/swarm-client.jar

          I do not know what caused the issue in your particular case (CC Olivier Vernin). But, whatever is the root cause, the use-case is invalid IMO

           

          Show
          oleg_nenashev Oleg Nenashev added a comment - Few notes... You should not be using Jenkins Infra as a 24/7 source of binaries. Our infrastructure may be under maintenance. Also, there may be mirror issues You should not download files from HTTP. It makes you open to MITM attacks, especially in this case when you download binaries to be executed If you need to download the binary on a regular basis, it is served from your Jenkins master starting from Swarm Plugin 3.10: ${JENKINS_URL}/swarm/swarm-client.jar I do not know what caused the issue in your particular case (CC Olivier Vernin ). But, whatever is the root cause, the use-case is invalid IMO  
          Hide
          ghs1 g hs1 added a comment -

          Thanks. My comments:

          1. Nonsense. That's what an artifact repository is for.
          2. I'm actually using HTTPS.
          3. That's great and even better. Where was this change promulgated?

          I'll switch to using the master forthwith.

          How can I tell what version is being returned? Like the API, the version number is stripped from the returned jar's name.

          Many thanks.

           

          Show
          ghs1 g hs1 added a comment - Thanks. My comments: Nonsense. That's what an artifact repository is for. I'm actually using HTTPS. That's great and even better. Where was this change promulgated? I'll switch to using the master forthwith. How can I tell what version is being returned? Like the API, the version number is stripped from the returned jar's name. Many thanks.  
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          > Nonsense. That's what an artifact repository is for.

          Every infrastructure needs maintenance, we do not guarantee 24/7 availability of the main repo and mirrors. You can ask Olivier Vernin and Daniel Beck whether my response is nonsense or now, but I consider this approach as YOLO if you depend on it in your production Jenkins instances

          > How can I tell what version is being returned? Like the API, the version number is stripped from the returned jar's name.

          Swarm Plugin version is equal to the Swarm Plugin Client CLI it returns. At least for now

           

          Show
          oleg_nenashev Oleg Nenashev added a comment - > Nonsense. That's what an artifact repository is for. Every infrastructure needs maintenance, we do not guarantee 24/7 availability of the main repo and mirrors. You can ask Olivier Vernin and Daniel Beck whether my response is nonsense or now, but I consider this approach as YOLO if you depend on it in your production Jenkins instances > How can I tell what version is being returned? Like the API, the version number is stripped from the returned jar's name. Swarm Plugin version is equal to the Swarm Plugin Client CLI it returns. At least for now  
          Hide
          ghs1 g hs1 added a comment -

          So the question remains how can I determine the version of the client on download?

          Thanks.

          Show
          ghs1 g hs1 added a comment - So the question remains how can I determine the version of the client on download? Thanks.
          Hide
          danielbeck Daniel Beck added a comment -

          Nonsense. That's what an artifact repository is for.

          Jenkins project infrastructure is provided on a best effort basis. There is no SLA, and anything you do relying on it working 24/7, or beyond the specific uses implemented in Jenkins or other parts of infra (nowhere are we using [RELEASE]) is on shaky ground at best.

          FWIW we're using a hosted Artifactory service provided for free by JFrog, so in this case, there's nothing we can do. Might just be a changing feature set there, we have no visibility into their upgrade schedule. This issue does not seem relevant enough to spend our 'good will equity' with their support team on, so closing it.

          Show
          danielbeck Daniel Beck added a comment - Nonsense. That's what an artifact repository is for. Jenkins project infrastructure is provided on a best effort basis. There is no SLA, and anything you do relying on it working 24/7, or beyond the specific uses implemented in Jenkins or other parts of infra (nowhere are we using  [RELEASE] ) is on shaky ground at best. FWIW we're using a hosted Artifactory service provided for free by JFrog, so in this case, there's nothing we can do. Might just be a changing feature set there, we have no visibility into their upgrade schedule. This issue does not seem relevant enough to spend our 'good will equity' with their support team on, so closing it.
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          > So the question remains how can I determine the version of the client on download?

          W.r.t that, see https://stackoverflow.com/questions/9815273/how-to-get-a-list-of-installed-jenkins-plugins-with-name-and-version-pair and other similar threads. Generally you can query the plugin version from the master OR read JAR manifest.

           

          Show
          oleg_nenashev Oleg Nenashev added a comment - > So the question remains how can I determine the version of the client on download? W.r.t that, see https://stackoverflow.com/questions/9815273/how-to-get-a-list-of-installed-jenkins-plugins-with-name-and-version-pair and other similar threads. Generally you can query the plugin version from the master OR read JAR manifest.  
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Feel free to submit a feature request for "–version" argument in Swarm Plugin Client, it may be useful in such cases

          Show
          oleg_nenashev Oleg Nenashev added a comment - Feel free to submit a feature request for "–version" argument in Swarm Plugin Client, it may be useful in such cases
          Hide
          olblak Olivier Vernin added a comment -

          repo.jenkins-ci.org is a service sponsored by Jfrog, we don't maintain it, regarding your question I "think" you need to specify the right version.

          Show
          olblak Olivier Vernin added a comment - repo.jenkins-ci.org is a service sponsored by Jfrog, we don't maintain it, regarding your question I "think" you need to specify the right version.

            People

            • Assignee:
              oleg_nenashev Oleg Nenashev
              Reporter:
              ghs1 g hs1
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: