Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5755

Definition of the revision for the latest strategies

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • ivy-plugin
    • None

      It would be very nice if the plugin could be optimized which defintions of the latest strategies should be used when other depending projects will be build.
      If nothing is placed the plugin should build all other depending projects.
      If something like rev="latest.integration" is been placed in the options of the project,
      only projects which are using this strategie will be build.
      This is very usefull because we have about 600 projects with dependencies and if the
      most used would be build all the depending would be build too.

          [JENKINS-5755] Definition of the revision for the latest strategies

          dirkh added a comment -

          added the component

          dirkh added a comment - added the component

          I'll see what I can do. I've had to hack this area around a bit already.

          The revision matching stuff is tricky because Hudson can't easily tell if the build is using a custom implementation of ivy revision matchers, custom latest strategies, etc.

          Perhaps the best would be to allow the user to enter a regular expression for matching revisions to be linked up as build triggers. If it's left blank, the behaviour will be identical to what it is now, otherwise the user-provided regex will override the default behaviour.

          Oh, and is this when using Freestyle jobs with the Ivy Build Trigger or using the new Ivy Project functionality added in version 1.0 of the plugin?

          Timothy Bingaman added a comment - I'll see what I can do. I've had to hack this area around a bit already. The revision matching stuff is tricky because Hudson can't easily tell if the build is using a custom implementation of ivy revision matchers, custom latest strategies, etc. Perhaps the best would be to allow the user to enter a regular expression for matching revisions to be linked up as build triggers. If it's left blank, the behaviour will be identical to what it is now, otherwise the user-provided regex will override the default behaviour. Oh, and is this when using Freestyle jobs with the Ivy Build Trigger or using the new Ivy Project functionality added in version 1.0 of the plugin?

          dirkh added a comment -

          We are using Freestyle Jobs and strategies like.
          latest.milestone (for released Components)
          latest.integration (for snapshot or local developed)
          latest.releaseCandidate (for RC )

          Hudson only should build Snapshot Version of our Components.

          I think with a regular expression would be the best way to implement this.

          dirkh added a comment - We are using Freestyle Jobs and strategies like. latest.milestone (for released Components) latest.integration (for snapshot or local developed) latest.releaseCandidate (for RC ) Hudson only should build Snapshot Version of our Components. I think with a regular expression would be the best way to implement this.

          dirkh added a comment -

          I would like to known, if this issue will be fixed soon.
          This would be very nice, because now we are using a customized ivy plugin ( where
          we changed this:

          public final class ModuleDependency implements Serializable {
          public ModuleDependency(String organisation, String name, String revision, String branch) {
          this.organisation = organisation;
          this.name = name;
          this.revision = (revision.startsWith("latest.integration") ) ? UNKNOWN : revision;
          this.branch = (branch == null || branch.contains("${")) ? UNKNOWN : branch;
          }

          and we would like to use the standard again.
          So please fix it soon

          dirkh added a comment - I would like to known, if this issue will be fixed soon. This would be very nice, because now we are using a customized ivy plugin ( where we changed this: public final class ModuleDependency implements Serializable { public ModuleDependency(String organisation, String name, String revision, String branch) { this.organisation = organisation; this.name = name; this.revision = (revision.startsWith("latest.integration") ) ? UNKNOWN : revision; this.branch = (branch == null || branch.contains("${")) ? UNKNOWN : branch; } and we would like to use the standard again. So please fix it soon

          Apologies for neglecting this issue. I've been focussed on a few other improvements/fixes and I had just left this sitting there. I'll start working on this now.

          From the code you've given, I assume this must be for Ivy Projects rather than Freestyle Projects right? You mentioned in a previous comment a while ago that you were using Freestyle Projects, but the code you've given in your last comment is only used in the Ivy Project type.

          Is that correct? Have you migrated your projects to the Ivy Project type?

          It makes a big difference as the code and even the approach is entirely different for these two areas.

          Timothy Bingaman added a comment - Apologies for neglecting this issue. I've been focussed on a few other improvements/fixes and I had just left this sitting there. I'll start working on this now. From the code you've given, I assume this must be for Ivy Projects rather than Freestyle Projects right? You mentioned in a previous comment a while ago that you were using Freestyle Projects, but the code you've given in your last comment is only used in the Ivy Project type. Is that correct? Have you migrated your projects to the Ivy Project type? It makes a big difference as the code and even the approach is entirely different for these two areas.

          dirkh added a comment -

          Thx for responding,

          no, we have not migrated the projects.
          I don't why but with this customized version it works
          well on our hudson server.
          I did not see the difference of the two prjects types in the code.
          So i have to wait for your bugfix.
          Thanks

          dirkh added a comment - Thx for responding, no, we have not migrated the projects. I don't why but with this customized version it works well on our hudson server. I did not see the difference of the two prjects types in the code. So i have to wait for your bugfix. Thanks

          reeve lau added a comment -

          We are using ivy plugin for all jobs. This fix would greatly improve the build efficiency. May I know what is the status of this issue?

          reeve lau added a comment - We are using ivy plugin for all jobs. This fix would greatly improve the build efficiency. May I know what is the status of this issue?

            tbingaman Timothy Bingaman
            dirkh dirkh
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: