Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression: exit status not waiting for run interactively process to complete #432

Open
mroth opened this issue Apr 20, 2017 · 10 comments
Open
Assignees
Milestone

Comments

@mroth
Copy link

mroth commented Apr 20, 2017

Summary

In version 0.6.2, a run interactively step followed by a the exit status should be step would complete, allowing the results of the process to be examined (as well as ensuring any side effects were complete before moving on to additional steps).

Upon updating to latest stable 0.14.2, this no longer happens, causing commands to run out of order, and all the workarounds I can think of seem fairly hacky and undesirable. It appears run interactively is now functioning as a "background" process by default?

I believe this may be a regression/bug?, since that doesn't appear to be the goal of the behavior from sample Features.

Expected Behavior

There should be a way to let an interactive process complete before checking it's exit status, or another mechanism to avoid "out of order" problems.

Current Behavior

I've annotated the actual Scenario Outline in my test cases here to illustrate what is happening, see comments inline:

Scenario Outline: Wrapped `git reset` can handle files with spaces properly

  Given I am in a git repository
  Given an empty file named "file with spaces.txt"
  ###AAA
  Given I successfully run `git add "file with spaces.txt"`

  ###BBB
  Given I run `<shell>` interactively
    And I type `eval "$(scmpuff init -ws)"`
    And I type "scmpuff_status"
    And I type "git reset 1"
    And I type "echo 'DEBUG: PHASE BBB'"
    And I type "exit"
  Then the exit status should be 0
  ### ^^^ this is now checking exit status of AAA, not BBB!

  # Then the output should contain "BBB"
  ### ^^^ this command however, would force aruba to wait until BBB completes (hacky option #1)

  # Then I stop the command started last
  ### ^^^ (hacky option #2) also seems to ensure BBB completes, but throws a deprecation error

  ###CCC
  ### currently, this phase is failing, because it is taking place *BEFORE* BBB completes
  When I run `scmpuff status`
  Then the stdout from "scmpuff status" should contain:
    """
    untracked:  [1] file with spaces.txt
    """
  Examples:
    | shell |
    | bash  |
    | zsh   |

Possible Solution

I've indicated two possible workarounds in the above code sample comments, but neither seems like it's the intended solution (and one throws a deprecation warning).

Context & Motivation

In our tests, we need to do some stuff in an interactive shell (as our program modifies the shell environment for end-users as it's primary use case), and follow that up by additional (non-interactive) tests afterwards to check on the state of things.

Your Environment

  • Version used: 0.14.2 and 0.6.2 (pre-regression)
  • Operating System and version: tested on both macOS and Linux (travis-ci)
  • Link to your project: https://github.com/mroth/scmpuff
@maxmeyer
Copy link
Member

@mrod Thanks for reporting this. This is weird and should not happen.

  1. We use an event bus in newer version of aruba to track command starting/stopping

    def events

  2. A stopped command should be reported back to the command monitor

    runtime.command_monitor.last_command_stopped = event.entity

  3. In the following step we call #last_command_stopped
    https://github.com/cucumber/aruba/blob/master/lib/aruba/cucumber/command.rb#L273

  4. This method should make sure all command started should be stopped (via CommandMonitor)

    event_bus.notify Events::CommandStopped.new(self)

Questions

Help

  • Can you please answer the questions for your usecase?

@mroth
Copy link
Author

mroth commented Apr 24, 2017

Thanks @maxmeyer, starting on debugging but might need a little help.

I've currently modified the step to be like the following:

  @wip
  Scenario Outline: Wrapped `git reset` can handle files with spaces properly

    Given I am in a git repository
    Given an empty file named "file with spaces.txt"
    ###AAA
    Given I successfully run `git add "file with spaces.txt"`

    ###BBB
    Given I run `<shell>` interactively
      And I type `eval "$(scmpuff init -ws)"`
      And I type "scmpuff_status"
      And I type "git reset 1"
      And I type "echo 'DEBUG: PHASE BBB'"
      And I type "exit"
   ### BELOW IS NEW
    Then the exit status should be 0
    Then I print the value of last command stopped
    Then I manually sent a stop event to runtime monitor
    Then I print the value of last command stopped
    Then the exit status should be 0
   ### ABOVE IS NEW
    ### ^^^ this is checking exit status of AAA, not BBB!

    # Then the output should contain "BBB"
    ### ^^^ this command however, would force aruba to wait until BBB completes (super hacky option #1)

    # Then I stop the command started last
    ### ^^^ (hacky option #2) also seems to ensure BBB completes, but throws a deprecation error

    ###CCC
    ### currently, this phase is failing, because it is taking place *BEFORE* BBB completes
    When I run `scmpuff status`
    Then the stdout from "scmpuff status" should contain:
      """
      untracked:  [1] file with spaces.txt
      """
    Examples:
      | shell |
      | bash  |

With new step definitions:

#
# for debugging cucumber/aruba#432
#
Then(/^I print the value of last command stopped$/) do
  puts last_command_stopped
end

Then(/^I manually sent a stop event to runtime monitor$/) do
  # TODO: not working
  event_bus.notify Events::CommandStopped.new(self)
end

On the first debug evocation, last_command_stopped returns #<Aruba::Processes::SpawnProcess:70196393371320 commandline="git add "file with spaces.txt"": output="">, which seems consistent with the bug in that the interactive command has not been stopped.

However, I'm having trouble figuring out how to properly send the "stop" event to the proper place within a step definition for debugging -- could you please help with the correct way to define that? Thanks!

@maxmeyer
Copy link
Member

Thanks. I will get to this soon - hopefully.

@mvz
Copy link
Contributor

mvz commented Sep 3, 2017

I think what happens here is this:

  • The non-interactive command finishes and sets @last_command_stopped.
  • The interactive command gets started and is told to finish by the fake user, but Aruba doesn't know about this.
  • The exit status should be 0 step calls #last_command_stopped. This method sees that @last_command_stopped has a value and therefore does not wait for the interactive command to finish.

I have checked version 0.6.2, and the implementation of exit status should be 0 seems similar. That means it probably looks at the exit status for the first command there as well (note that that command also has exit status 0). It is therefore unclear to me why the scenario works with version 0.6.2.

@stale
Copy link

stale bot commented Nov 9, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

@stale stale bot added the stale These issues were closed by stalebot and need to be reviewed to see if they're still relevant. label Nov 9, 2017
@stale
Copy link

stale bot commented Nov 16, 2017

This issue has been automatically closed because of inactivity. You can support the Cucumber core team on opencollective.

@stale stale bot closed this as completed Nov 16, 2017
@mvz
Copy link
Contributor

mvz commented Nov 16, 2017

I think this issue still exists & I'm going to take a look at it.

@mvz mvz reopened this Nov 16, 2017
@stale stale bot removed the stale These issues were closed by stalebot and need to be reviewed to see if they're still relevant. label Nov 16, 2017
@mvz mvz self-assigned this Nov 16, 2017
@mvz mvz modified the milestones: 1.0.0-alpha.5, 1.0.0 Jan 1, 2020
@mvz
Copy link
Contributor

mvz commented Jan 1, 2020

I've looked again at the 0.6.2 implementation, and it stops all processes unless it has deliberately stopped a process before. In the case of this scenario, this means it stops all processes.

@mvz
Copy link
Contributor

mvz commented Jan 1, 2020

@mroth I'm afraid you will have to add some step that waits for the interactive command to finish. This would be either I stop the command started last or "I stop the command "<shell>".

@mvz mvz removed the bug label Jan 1, 2020
@mvz mvz removed this from the 1.0.0 milestone Jan 1, 2020
@mvz
Copy link
Contributor

mvz commented Jan 1, 2020

Documentation about this should probably be improved, since the interaction between steps is not very clear in this case.

A step definition like I let the command started last finish might also be nice, since it may better describe the intent in a case like this.

@mvz mvz added this to the 1.1.0 milestone Jan 1, 2020
@mvz mvz modified the milestones: 1.1.0, 1.2.0 Aug 21, 2020
jdelStrother added a commit to jdelStrother/scmpuff that referenced this issue Nov 6, 2020
Aruba changed its process management which made this harder:
cucumber/aruba#432
@mvz mvz modified the milestones: 1.1.0, 2.0.0 Jun 20, 2021
@mvz mvz modified the milestones: 2.0.0, 2.1.0 Aug 1, 2021
mroth added a commit to mroth/scmpuff that referenced this issue Dec 5, 2021
see cucumber/aruba#432 for details and this suggested workaround.
mroth added a commit to mroth/scmpuff that referenced this issue Dec 5, 2021
* build(ci): test switch to aruba 2.0

* build(ci): update travis for aruba2

* fix(ci): aruba current_directory scope

* build(ci): workaround to allow directory escape in aruba2

* build(ci): publish cucumber report from travis

* build(ci): safer tmpdir in aruba

* build(ci): workaround for cucumber/aruba#432

see cucumber/aruba#432 for details and this suggested workaround.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants