configuration option to avoid unncessary restarts of process

[maxandersen]

Not sure how this fits in with devfile 2.0 spec but it is/was a problem of odo behavior causing a full restart of the running server when files changed - that is not wanted for things like springboot and quarkus.

see odo issue at redhat-developer/odo#3043

[sbose78]

Good point, looks like redhat-developer/odo#3043 should be resolving this?

[maxandersen]

Yes, 3043 is I understand it odo's approach to support it but not part of the devfile spec.

[l0rd]

It's not clear to me how this would translate in the devfile spec. @kadel any idea?

[kadel]

It's not clear to me how this would translate in the devfile spec. @kadel any idea?

I'm not sure. It could be an additional option for exec component. But it might look weird as it make sense only for some type of commands.

This is why we are currently using attributes for this.

Would something like this make sense for Che? As far as I know, Che doesn't do any automatic application restarts. The Che user is in control when and if the application process should be restarted.

[sbose78]

Yes, options which must not be added as a strongly typed attribute, should go into the loosely typed list of attributes in attributes?

[pdaverh]

I imagine options that do not apply to a tool can be ignored by the tool. For example, if this is added as a devfile spec (RESTART=No), then Che can ignore it but odo can respect it.

[kadel]

Here is an example of how to use the "restart" attribute in devfile v2. (works only in odo)
https://github.com/odo-devfiles/registry/blob/master/devfiles/quarkus/devfile.yaml#L35-L36

[kadel]

Proposal

The commands that get executed can be of two types:

• one-shot command This is a command that does its job and exits. The typical case is build command. Tool executing this command should wait for this command to finish and report its status.
• long-running command This is command is running and doing their job without exiting (like servers). The typical case is run command. The tool should not wait for it to finish. The tool needs to ensure that the command is kept running even when it is not attached to the process.

In addition, the long-running process can be also of two types:

• hot-reload capable
• needs to be restarted to pick up changes

This is especially important for debug and run command groups. Some tools like for example odo need to know if the command needs to be restart to pick up changes or not.

This means that we need two additional fields for exec commands.

• background: (true|false)
• restartOnChange: (true|false)

Each command group will have different defaults based on its typical use:

restartOnChange- tells tool to restart the process when there is a change that needs to be applied
restartOnChange: false - hotreload capable process
restartOnChange: true - tool (odo/Che) needs to restart the process when the source changes

• build
  • background: false
  • restartOnChange: true
• run
  • background: true
  • restartOnChange: false
• debug
  • background: true
  • restartOnChange: false
• test
  • background: false
  • restartOnChange: true

Example

commands:
    - exec:
        id: install-deps
        component: dev 
        commandLine: "npm package"
        group:
          kind: build
          isDefault: true
    - exec:
        id: run
        component: dev
        commandLine: "npm run start"
        restartOnChange: true
        group:
          kind: run
          isDefault: true
    - exec:
        id: run-dev
        component: dev
        commandLine: "npm run debug"
        restartOnChange: true
        group:
          kind: run

[amisevsk]

@kadel I've left a review on the PR #96 (review) but also wanted to ask a question here: how does a command that is

background: false
restartOnChange: true

behave? Presumably we would check that the command hasn't exited yet, and restart it if changes are detected, but I'm not sure where this functionality is useful. Some cases for a test task:

• I'm writing tests for one Java class while testing another, independent class. This setting would continually restart my tests, running identical code
• I'm running a test command and want to make a change, but the "change detected" event races the completion of the test. I would need to be paying attention to the progress of my test to know whether my current changes have been tested, and the user flow is opposite depending on whether tests have completed (have to re-run command if it's completed, but don't if it hasn't)

Personally, I think restartOnChange doesn't make sense for non background tasks, since there is an intentionality to starting a completing task, that I think is the default mode for using such functionality.

If there's some use-case I'm not thinking of, I would like to put forth keeping restartOnChange as default false for background: false commands, as I believe this is the kind of flow typically expected from other tooling.