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

Make android-emulator plugin Pipeline-friendly

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      This plugin — at least the build wrapper, but preferably also the build steps — should be Pipeline-compatible.

        Attachments

          Activity

          Hide
          ahorner Andy Horner added a comment - - edited

          I think a step like this would work quite well

          step([
                  $class: 'AndroidEmulator',
                  osVersion: 'android-23',
                  screenResolution: '1080x1920',
                  screenDensity: 'xxhdpi',
                  deviceLocale: 'en_US',
                  targetAbi: 'x86',
                  sdCardSize: '200M',
                  showWindow: true,
                  commandLineOptions: '-noaudio -gpu mesa -qemu -m 1024 -enable-kvm'
          ])
          
          Show
          ahorner Andy Horner added a comment - - edited I think a step like this would work quite well step([ $class: 'AndroidEmulator' , osVersion: 'android-23' , screenResolution: '1080x1920' , screenDensity: 'xxhdpi' , deviceLocale: 'en_US' , targetAbi: 'x86' , sdCardSize: '200M' , showWindow: true , commandLineOptions: '-noaudio -gpu mesa -qemu -m 1024 -enable-kvm' ])
          Hide
          garethnz Gareth Shaw added a comment -

          I'm interested in implementing this (no promises though)
          (I have parts of it working already, based on the pipeline-dsl branch)
          Could I discuss here / somewhere before creating a Pull Request?

          Show
          garethnz Gareth Shaw added a comment - I'm interested in implementing this (no promises though) (I have parts of it working already, based on the pipeline-dsl branch) Could I discuss here / somewhere before creating a Pull Request?
          Hide
          ahorner Andy Horner added a comment -

          Gareth Shaw Please do! I've not ever contributed to a Jenkins plugin before but I will definitely provide input and code review.

          Show
          ahorner Andy Horner added a comment - Gareth Shaw Please do! I've not ever contributed to a Jenkins plugin before but I will definitely provide input and code review.
          Hide
          orrc Christopher Orr added a comment -

          Gareth Shaw: Sure, feel free to discuss your ideas here. If you have code pushed, you could also link to any branches that you might have.

          But note that the code in that experimental pipeline-dsl branch isn't amazing and, having discussed it with Kohsuke and Jesse (aka the pipeline gurus) at Jenkins World, it's maybe not going in the right direction. Using DSLs in this way apparently isn't really pipeline-y (and won't work with the Snippet Generator), and the way I implemented it means that we lose out on some of the important pipeline features, like durability (AbstractSynchronousNonBlockingStepExecution doesn't support it; but without this I think I ended up blocking the CPS thread).
          i.e. it's generally preferable to provide a series of pipeline steps.

          I really need to get back into the code, and look at my notes from the Jenkins World discussions, think again about the design, and also think about how to incorporate automated installation of system images etc.
          Pipeline support is currently #1 on my list of things to implement, and I do have a lot of free time right now, but I'm about to go on holiday for two weeks…

          Anyway, if you have any ideas, or anything to share, I'd be happy to take a look at it.

          Show
          orrc Christopher Orr added a comment - Gareth Shaw : Sure, feel free to discuss your ideas here. If you have code pushed, you could also link to any branches that you might have. But note that the code in that experimental pipeline-dsl branch isn't amazing and, having discussed it with Kohsuke and Jesse (aka the pipeline gurus) at Jenkins World, it's maybe not going in the right direction. Using DSLs in this way apparently isn't really pipeline-y (and won't work with the Snippet Generator), and the way I implemented it means that we lose out on some of the important pipeline features, like durability (AbstractSynchronousNonBlockingStepExecution doesn't support it; but without this I think I ended up blocking the CPS thread). i.e. it's generally preferable to provide a series of pipeline steps. I really need to get back into the code, and look at my notes from the Jenkins World discussions, think again about the design, and also think about how to incorporate automated installation of system images etc. Pipeline support is currently #1 on my list of things to implement, and I do have a lot of free time right now, but I'm about to go on holiday for two weeks… Anyway, if you have any ideas, or anything to share, I'd be happy to take a look at it.
          Hide
          garethnz Gareth Shaw added a comment -

          Christopher Orr Sorry, no code pushed yet.

          Yes I wasn't sure about the DSL either, my first steps was to get it working by refactoring AndroidEmulator.java and supporting classes to separate out the logic of managing the emulator and the handling required for a BuildWrapper (Keeping AndroidEmulator.java as the BuildWrapper so as not to break plugin upgrades) - Calling the logic only class "AndroidEmulatorManager".

          Pipeline specific things:

          • I left your Dsl.groovy mostly as is (except I added a 'withAvd(String name)' to use a pre-existing AVD).
          • For specifying all AVD details, I went with what Andy Horner suggested above. (Didn't quite have that working last I worked on this, but it was close)
          • I made the WithAndroidEmulatorStepExecution similar to the build wrapper, using the AndroidEmulatorManager to manage the emulator instance for the step.

          Regarding how the DSL should work, I think something like what Job Dsl does?

          Allow users to instantiate an AndroidEmulatorManager, then provide methods (Steps) like .boot(), .bootAsync(), runWith({}), stop().
          unsure how exactly how to do this at present.
          (You'd also have to provide a way to ensure stop is called in the case of some other exception/error - if the user wants).

          What were you thinking of doing for the DSL?

          Show
          garethnz Gareth Shaw added a comment - Christopher Orr Sorry, no code pushed yet. Yes I wasn't sure about the DSL either, my first steps was to get it working by refactoring AndroidEmulator.java and supporting classes to separate out the logic of managing the emulator and the handling required for a BuildWrapper (Keeping AndroidEmulator.java as the BuildWrapper so as not to break plugin upgrades) - Calling the logic only class " AndroidEmulatorManager ". Pipeline specific things: I left your Dsl.groovy mostly as is (except I added a 'withAvd(String name)' to use a pre-existing AVD). For specifying all AVD details, I went with what Andy Horner suggested above. (Didn't quite have that working last I worked on this, but it was close) I made the WithAndroidEmulatorStepExecution similar to the build wrapper, using the AndroidEmulatorManager to manage the emulator instance for the step. Regarding how the DSL should work, I think something like what Job Dsl does? Allow users to instantiate an AndroidEmulatorManager, then provide methods (Steps) like .boot(), .bootAsync(), runWith({}), stop(). unsure how exactly how to do this at present . (You'd also have to provide a way to ensure stop is called in the case of some other exception/error - if the user wants). What were you thinking of doing for the DSL?
          Hide
          mrsasha Sasa Sekulic added a comment -

          Hi guys, any news on this? Would be really nice to have it.

          Show
          mrsasha Sasa Sekulic added a comment - Hi guys, any news on this? Would be really nice to have it.
          Hide
          bwatson Benjamin Watson added a comment -

          Any updates?  This would be such an awesome feature.

          Show
          bwatson Benjamin Watson added a comment - Any updates?  This would be such an awesome feature.
          Hide
          garethnz Gareth Shaw added a comment -

          Sorry. 
          I did manage to get a version working (that only supported loading existing AVDs, not creating new ones).

          My company may instead move to:

          https://github.com/AzimoLabs/fastlane-plugin-automated-test-emulator-run

          As our builds use fastlane anyway.

          Show
          garethnz Gareth Shaw added a comment - Sorry.  I did manage to get a version working (that only supported loading existing AVDs, not creating new ones). My company may instead move to: https://github.com/AzimoLabs/fastlane-plugin-automated-test-emulator-run As our builds use fastlane anyway.
          Hide
          tobilarscheid Tobias Larscheid added a comment -

          So I assume still nothing new here?

           

          In theory supporting Pipeline should be relatively easy for the BuildWrapper, it would just need to extend

          SimpleBuildWrapper

          instead of

          BuildWrapper

           

          I tried getting that to work, the problem is that there is a lot of custom stuff happening (e.g. manual expansion of environment variables) that were not trivial to transfer.

          Show
          tobilarscheid Tobias Larscheid added a comment - So I assume still nothing new here?   In theory supporting Pipeline should be relatively easy for the BuildWrapper, it would just need to extend SimpleBuildWrapper instead of BuildWrapper   I tried getting that to work, the problem is that there is a lot of custom stuff happening (e.g. manual expansion of environment variables) that were not trivial to transfer.

            People

            • Assignee:
              orrc Christopher Orr
              Reporter:
              orrc Christopher Orr
            • Votes:
              24 Vote for this issue
              Watchers:
              28 Start watching this issue

              Dates

              • Created:
                Updated: