Currently the APPSODY_REGEX only is used against the file name or leaf directory rather than the full path.

It would be desirable to give users a choice.

Other Options:

It is also possible that we could default to the full path. But we would want to make sure we don't break existing stacks.

Currently we launch the watcher async right after we launch the RUN command which in turn does APPSODY_PREP.

We should pull out APPSODY_PREP so it runs sync prior to any of this. OR we should update the run commands logic to spin the func for watching after APPSODY_PREP runs,

Description:
In some cases, particularly with appsody run for a clean docker for desktop install on Mac Os or when doing:

appsody init-nodejs-express
appsody run
The first time in a new directory on the Che-emulator environment

We will see:

[Container] Running APPSODY_PREP command: npm install --prefix user-app && npm audit fix --prefix user-app
File watch event detected for: FILE "test.js" REMOVE [/project/user-app/test/test.js]
File watch event detected for: FILE "test.js" CREATE [/project/user-app/test/test.js]

It appears that something in the npm commands may cause the watcher to think there is no test.js file (and due to the 1 event per watcher cycle setting we use, it could be more than just test.js)

FYI: The watcher.go code uses filepath.walk() routine to construct a map of files and then compares the map previously obtained on the poll to the current poll's map.

One short term fix that was tested for this would be to run APPSODY_PREP serially before starting the watcher, note this was brought up in another issue, whether we should watch during APPSODY_PREP.

Longer term, we need to investigate why the watcher/commands exhibit this behavior.

It did not appear to happen with Java Microprofile in the che emulator environment.

It seems to happen with nodejs-express on MacOS when there is a clean docker environment every time with the first appsody run. It has been seen a couple of times after long disuse of appsody init/followed by appsody run.

Note that subsequent appsody run's do not see the behavior.

@kylegc raised this issue. This could happen if Jane has a bug in her code that prevents the server from starting, or the server crashed unexpectedly. The controller would still be watching for Jane to fix the issue with a file change, however the ON_CHANGE action will not be enough to start the server back up. In this scenario, the controller should run the start server command instead of the ON_CHANGE command.

An alternative solution is to watch for the server process to exit, and then exit the controller and container. This would require Jane to fix the code and re-run appsody dev run to restart the container.

-Change appsody-controller to init-controller in build.sh

-Remove the setController.sh file

-Remove references to the setControler.sh file in the Dockerfile

• Add the CMD to copy appsody-controller in the Dockerfile to /.appsody

CMD ["cp","/appsody-controller","/.appsody/appsody-controller"]

For the structure of documentation and discussion on the release processes, use https://github.com/appsody/docs/issues/56

Hi Team,

This question is with reference to the enhancement request raised few days back - #59

As I am a bit new to appsody and appsody-controller, please guide me on how can I work with ppc64le specific "appsody-controller" binary by leveraging the recently released "appsody" binary.

The link for appsody binary download is - https://github.com/appsody/appsody/releases/download/0.5.3/appsody-0.5.3-linux-ppc64le.tar.gz

Regards,
Vrushali

I am trying to pull the image of appsody/init-controller from docker on M1 chip but unable to pull the image. PFB the error

no matching manifest for linux/arm64/v8 in the manifest list entries

Currently the APPSODY_IGNORE_DIRS allows specifying the full path to a file, but the name of the variable, and documentation does not state this.

Much of the readme's content is now contained in the environment-variables document. It should be replaced with a link.

For each exec.Command cmd.Stdin must be set to os.Stdin for TTY to work.

1. The debug trace has diverged a lot from the CLI trace. Should they be made more similar
2. Controller outputs a large volume of trace. Is it all needed.
3. The controller test bucket is heavily dependent on trace output. Changes may break the test cases.

When testing #57, our CI/CD system tests fail because /bin/sh has a different error response when an invalid command is specified.

root@9a9fc7d528b1:/project/user-app# bad
bash: bad: command not found
root@9a9fc7d528b1:/project/user-app# sh

bad

sh: 1: bad: not found

echo $0

sh

exit

root@9a9fc7d528b1:/project/user-app# echo $0
bash

This issue updates the tests tolerate both variants.

In order for a tty to work, we need to change
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}
to.
cmd.SysProcAttr = &syscall.SysProcAttr{Setsid: true}

I addition, we can not post process all directory events out for ON_CHANGE, so we will remove that temporary change from the previous PR.

Hi Team,

We have recently built "appsody" binary from source on linux/ppc64le architecture. We found that ppc64le specific binary is not available for download under https://github.com/appsody/appsody/releases.

Is it possible to make it available for download. We have built it from source by using following steps:

• Create following directory structure to build go based packages.
  $HOME/go/bin/src/github.com/appsody/Pkg
• Clone appsody-controller source code into appsody directory from https://github.com/appsody/controller.
• Install ‘go’ using steps mentioned at https://tecadmin.net/install-go-on-centos.
• Go into $HOME/go/src/github.com/appsody/controller directory.
• Execute go build command to build appsody-controller executable.
• copy both the binaries into /usr/bin directory.
• Execute appsody-controller version command to verify the binary.

Please let me know the feasibility.

Regards,
Vrushali

Is your feature request related to a problem? Please describe.
This will allow architectures different to x86 to use Appsody as they currently do not work.

Describe the solution you'd like
Use experimental docker daemon buildx across multiple platforms.

The default APPSODY_WATCH_REGEX expression is for all .java,.js, .go files.
This is the case if the APPSODY_WATCH_REGEX is set to "".

This should be reflected in the project documentation.

If one makes a change in the DEPS directory it is not seen by the watcher.

At this moment all DEPS directory related changes are to be IGNORED in existing stacks, however, this may change in new stacks in the future.

It is not known what the root cause of this is ATM.

Describe the bug

When --interactive is specified when running appsody run and the stack is not tty enabled, ctrl-c no longer causes the docker container to stop

To Reproduce
For a stack
Make a directory and cd to it
Run the following

1. appsody init nodejs-express
2. appsody run --interactive
3. ctrl-c

Expected behavior
The Controller will cause the container to stop with clean shutdown

Actual behaviour
The container will remain up after the shutdown steps.

Environment Details (please complete the following information):

• OS: mac catalina
• Browser NA

If applicable please specify:

• CLI version:- Version 0.5.0
• Stack you are using: nodejs-express, java-microprofile

Additional context
None.

We need to review and discuss this. Question.

APPSODY_PREP will replace APPSODY_INSTALL. APPSODY_INSTALL is now deprecated.

Is your feature request related to a problem? Please describe.
Please refer to appsody/appsody#31

Describe the solution you'd like
Please refer to appsody/appsody#31

Describe alternatives you've considered
Please refer to appsody/appsody#31

Additional context
appsody/appsody#338 is raised in appsody, a similar change in controller in this repo would compliment it

Cover the following aspects:

-Test:

• Building a test image
• Release Process
• Dependences of the CLI

Many stacks have ON_CHANGE commands that end the process by themselves and there is no need to kill them.

Currently the controller tries to kill them in this case, and prints out warning messages which say the kill failed and there is no such process

Outcome desired:
Either:

1. suppress the above messages

or

*2. Use a similar technique that we use to determine server failures and restarts in the on change events where we send a benign signal to determine if the process is alive.
Then we could avoid unnecessary kill actions.

In an earlier issue it was found it might be useful to ignore one of the six types of events, specifically DIR WRITE.

We could create additional APPSODY environment variables which allow our users to turn off any of the six actions for either FILES, DIRs or both

The six actions supported by the watcher include:

CREATE
WRITE
RENAME
MOVE
REMOVE
CHMOD

Is your feature request related to a problem? Please describe.

Stacks are inconsistent in the behavior of appsody test (some run through and quit, others run and then watch). For a script or other automation, you want to be able to run the tests and quit with the appropriate result based on failures. There isn’t anyway to specify this behavior via the appsody command line at the moment.

Doing any kind of manipulation on test output to determine when tests are done is language/stack specific and fragile. Trying to force all stacks to behave identically with appsody test is also not useful, as we expect further customization of stacks...

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

appsody test --no-watcher could work.

I want the stack specified tests to run, but for the process to terminate and return with the result of the executed command.

Related to appsody/stacks#308 —> appsody/stacks#323

Describe the bug
I am sshing to my windows 10 system as jenkinstest user (non-Azure) and I have the shell set to git bash for ssh and when I do an appsody run and then do a ctrl-c to exit out of the run the container does not get removed...

[Container] App started on PORT 3000
[Container] [ControllerDebug] The watch interval is set to: 2s seconds.
[Info] Running command: docker stop express-dev
[Debug] CLI exit error is:  exit status 2
[Info] Closing down, development environment was interrupted.
jenkinstest@DESKTOP-GRG3EVR MINGW64 ~/projects/013020/express
$ ~/bats_temp/temp/src/github.com/appsody/appsody/build/appsody-0.0.0-windows-amd64.exe ps
CONTAINER ID    NAME            IMAGE                                   PORTS                                           STATUS
26cb6c891a52    express-dev     docker.io/appsody/nodejs-express:0.4    0.0.0.0:3000->3000/tcp, 0.0.0.0:9229->9229/tcp  Up 28 seconds
$ echo $SHELL
/c/program files/git/bin/bash.exe

To Reproduce
Steps to reproduce the behavior:

1. ssh [email protected]
2. mkdir express
3. cd express
4. appsody init nodejs-express
5. appsody run
6. ctrl-c

Environment Details (please complete the following information):

• OS: [e.g. iOS] ssh to windows 10 using non-Azure login

If applicable please specify:

• CLI version: 0.5.6
• Stack you are using: nodejs-express
• Controller version: 0.3.4

In order to eliminate issues with APPSODY_ REGEX and watching .*, etc. we should ignore directory events. Because those events aren't of interest and cause unnecessary ON_CHANGE calls.

We will revisit supporting directory events in a future sprint.

Describe the solution you'd like

• Change .travis.yml to support the process
• .travis.yml Call script build.sh as part of deploy
• Create build.sh script to build docker image and push it
• Update Travis variables for Docker hub (org, user, pwd)
• setController contributed script which will copy the appsody-controller to shared volume

Describe alternatives you've considered
See Appsody Issues

Describe the bug
Travis builds on Linux, and set CGO_ENABLED=1 by default. This makes the controller non-runnable on several popular Linux Docker images, such as alpine and busybox.

To Reproduce
Steps to reproduce the behavior:
See: appsody/appsody#531

Currently the controller limits the number of events it gets back to 1 per watch cycle.
This was originally done to cut down on the number of ON_CHANGE actions performed per cycle.
Unfortunately, this can cause some events which the stack does not consider "ON_CHANGE" events to be processed, and others which would be ON_CHANGE actions to be skipped.

Most of the stacks have APPSODY_REGEX expressions which effectively exclude directory events, so the limit of one event causes only file events of interest to be reported back. So the limit of 1 works to a fair degree in those scenarios.

Currently the REGEX is used to match against the filename or the leaf directory name.

The java-spring-boot2 stack has a REGEX that match on almost everything, and thus the directory events are not filtered out. The other stacks filter out the directory events for the normal/majority of case(s), because their REGEX requires the name to end with a file extension.

Update:

We believe the one event limit is valid as long as all the events are valid events. Therefore we do not want the controller to do any post processing of events, all matching of events needs to happen in the watcher.

The solution is this:

1. Create a FilterHook for the watcher that ignores any events related to APPSODY_IGNORE_DIR
2. Create a FilterHook for the watcher that ignores any directory events.
   The above require folking the watcher repo to add the new Filters.

As part of the work above, we can make two improvements:

1. Move the setting of the regex expression on the watcher prior to defining the watchers watch directories
2. Remove the controller post processing step on event.Name for non ignored events, (this was needed for a specific scenario for node based stacks, which moving the REGEX set on tthe watcher eliminates the need for).

Describe the bug
I'm using the python-flask stack and I changed its test file so it would cause appsody test to fail. When I do this i get the expected error message but the return code is 0.

To Reproduce
Steps to reproduce the behavior:

1. edit incubator/python-flask/image/project/test/apptests.py and remove the : from line 4: class ServerTestCase(unittest.TestCase)
2. from incubator/python-flask run appsody stack validate which will do a package and a test and you should see log messages that the test had problems but was still marked as passed
3. to isolate the issue you can do an appsody init dev-local/python-flask and then appsody test --no-watcher and once it completes do an echo $? which will return a 0
4. to isolate the issue further you can run the docker command the test runs which is docker run --rm -p 5678:5678 -p 8080:8080 --name python-dev -v /Users/tnixa/appsody/projects101019/python/:/project/userapp -v python-deps:/project/deps -v /Users/tnixa/.appsody/appsody-controller:/appsody/appsody-controller -t --entrypoint /appsody/appsody-controller dev.local/python-flask:SNAPSHOT --mode=test --no-watcher and when this completes do an echo $? which will return a 0
5. to isolate the issue further you can do and appsody extract and then cd ~/.appsody/extract/<project name> and then run python -m unittest discover -s test -p *.py and then run echo $? which will return 1

Environment Details (please complete the following information):

• OS: [e.g. iOS] iOS

If applicable please specify:

• CLI version: 0.4.6
• Stack you are using: python-flask