Details

    • Similar Issues:

      Description

      (include sub-directories)
      Replace the log text "The artifact xxxx doesn't match .ear" by "The resource xxxx doesn't match .ear"

        Attachments

          Activity

          Hide
          ajw625 Andrew Wilkinson added a comment -

          This change is causing me problems. My ant build creates the ear to be deployed in a different directory each time I update the release number, for example:

          build/02_05_00/app.ear
          build/02_06_00/app.ear

          Then the build copies the ear to the root of the workspace to make it quick for the deployer to find it. But now the deployer doesn't look at the root of the workspace first. It is finding the oldest ear in build/02_05_00/app.ear. I can't figure out how to prevent the recursion or make it look in the workspace root first. So now I have to either clear the workspace each time or modify a bunch of build scripts to clear out any old builds.

          Am I missing something?

          Show
          ajw625 Andrew Wilkinson added a comment - This change is causing me problems. My ant build creates the ear to be deployed in a different directory each time I update the release number, for example: build/02_05_00/app.ear build/02_06_00/app.ear Then the build copies the ear to the root of the workspace to make it quick for the deployer to find it. But now the deployer doesn't look at the root of the workspace first. It is finding the oldest ear in build/02_05_00/app.ear. I can't figure out how to prevent the recursion or make it look in the workspace root first. So now I have to either clear the workspace each time or modify a bunch of build scripts to clear out any old builds. Am I missing something?
          Hide
          raphc Raphael CHAUMIER added a comment -

          Hi,

          Can't you rename your old artifact (e.g app.ear.02_05_00) instead of copy to a subdirectory . So if the name doesn't match the regex these artifacts will be ignored.

          Regards

          Show
          raphc Raphael CHAUMIER added a comment - Hi, Can't you rename your old artifact (e.g app.ear.02_05_00) instead of copy to a subdirectory . So if the name doesn't match the regex these artifacts will be ignored. Regards
          Hide
          ajw625 Andrew Wilkinson added a comment -

          I could, but that would require updating the build. There are many projects, each with their own build script. That's a lot of scripts to update and test. We're consultants and this only affects us internally, so we'd have to fix all these without being able to bill to anyone.

          Your comment for this change was:

          Implemented the recursive search when no base directory is set in freestyle job configuration.

          This seems to indicate that if I don't set the base directory, it will always do a recursive search. I tried setting the base directory to

          ${WORKSPACE}

          but since that is the default it seemed to ignore that and do the recursive search anyway.

          As a test, I also tried setting the base directory to all of these (the specific location of the ear file in the workspace):

          build/dev/02_08_00/ear/target
          build/dev/02_08_00/ear/target/
          ${WORKSPACE}/build/dev/02_08_00/ear/target
          ${WORKSPACE}/build/dev/02_08_00/ear/target/
          

          All of those give me this error:

          java.lang.RuntimeException: The base directory specified [${WORKSPACE}/] is invalid (doesn't exists or is not a directory or has insufficient privilege)
          

          I assume I'm doing something wrong since the directory does exist and jenkins must have privileges to it since it created the directory.

          Is there no way for me to tell the plugin that the ear file that the resource to deploy is in the root of the workspace? Even if there is only one copy of the ear, the plugin will still search the entire workspace recursively. It's a bit inefficient and it outputs a log message for every file that doesn't match the resource. Most of the log is those messages.

          Show
          ajw625 Andrew Wilkinson added a comment - I could, but that would require updating the build. There are many projects, each with their own build script. That's a lot of scripts to update and test. We're consultants and this only affects us internally, so we'd have to fix all these without being able to bill to anyone. Your comment for this change was: Implemented the recursive search when no base directory is set in freestyle job configuration. This seems to indicate that if I don't set the base directory, it will always do a recursive search. I tried setting the base directory to ${WORKSPACE} but since that is the default it seemed to ignore that and do the recursive search anyway. As a test, I also tried setting the base directory to all of these (the specific location of the ear file in the workspace): build/dev/02_08_00/ear/target build/dev/02_08_00/ear/target/ ${WORKSPACE}/build/dev/02_08_00/ear/target ${WORKSPACE}/build/dev/02_08_00/ear/target/ All of those give me this error: java.lang.RuntimeException: The base directory specified [${WORKSPACE}/] is invalid (doesn't exists or is not a directory or has insufficient privilege) I assume I'm doing something wrong since the directory does exist and jenkins must have privileges to it since it created the directory. Is there no way for me to tell the plugin that the ear file that the resource to deploy is in the root of the workspace? Even if there is only one copy of the ear, the plugin will still search the entire workspace recursively. It's a bit inefficient and it outputs a log message for every file that doesn't match the resource. Most of the log is those messages.

            People

            • Assignee:
              raphc Raphael CHAUMIER
              Reporter:
              raphc Raphael CHAUMIER
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: