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

ACNA-882 - Rewriting files during app run is error prone, and leads to unexpected issues #309

Merged
merged 6 commits into from
Nov 4, 2020

Conversation

shazron
Copy link
Member

@shazron shazron commented Oct 23, 2020

Fixes #275

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

…pected issues

1. during --verbose, java version is not shown since that output is to stderr (and we use stdout). fixed.
2. 100% test coverage
@adobe adobe deleted a comment from codecov bot Oct 27, 2020
@shazron shazron changed the title WIP - ACNA-882 - Rewriting files during app run is error prone, and leads to unexpected issues ACNA-882 - Rewriting files during app run is error prone, and leads to unexpected issues Oct 27, 2020
@codecov
Copy link

codecov bot commented Oct 27, 2020

Codecov Report

Merging #309 into master will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##            master      #309   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           27        29    +2     
  Lines         1259      1255    -4     
  Branches       219       206   -13     
=========================================
- Hits          1259      1255    -4     
Impacted Files Coverage Δ
src/lib/app-helper.js 100.00% <100.00%> (ø)
src/lib/cleanup.js 100.00% <100.00%> (ø)
src/lib/config-loader.js 100.00% <100.00%> (ø)
src/lib/poller.js 100.00% <100.00%> (ø)
src/lib/runDev.js 100.00% <100.00%> (ø)
src/lib/vscode.js 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef6c2a3...f868c95. Read the comment docs.

@shazron shazron marked this pull request as ready for review October 27, 2020 05:39
@purplecabbage
Copy link
Member

purplecabbage commented Oct 28, 2020

I find this potentially more confusing. Now I don't have a .vscode/launch.json and then I do, and then I don't ...
Why can't launch.json be persistent? It does not change between aio app run and aio app run --local

Also, with .env file now in dist/ ... we have one which is a copy of ../.env when run without --local, and one with ... can we just keep a local.env and prod.env in the dist/ folder instead?

@shazron
Copy link
Member Author

shazron commented Oct 29, 2020

I find this potentially more confusing. Now I don't have a .vscode/launch.json and then I do, and then I don't ...
Why can't launch.json be persistent? It does not change between aio app run and aio app run --local

I didn't change the existing functionality, so this behaviour is consistent with the previous behaviour. Not sure the rationale for this functionality.

Also, with .env file now in dist/ ... we have one which is a copy of ../.env when run without --local, and one with ... can we just keep a local.env and prod.env in the dist/ folder instead?

Not sure I follow exactly. When you run with --local it uses dist/.env. When run without --local it uses your root .env and nothing has changed there.

@shazron
Copy link
Member Author

shazron commented Nov 2, 2020

Windows 10 manual tests have been done (via a local patch, see Description), and local debugging etc works.

Copy link
Member

@moritzraho moritzraho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One inline question about the stop log arg.
Didn't tested, just looked at the code for now, but this looks mostly fine to me.

I agree with @purplecabbage about the vscode file, that it should be generated via generator-aio-app (on init), but I think this could be addressed in another PR

About the dist/.env discussion, I guess one potential enhancement would be, if possible, to pass wskdebug vars via environment instead of dist/.env, so that we can rename dist/.env to dist/.env.local (makes the intent clearer for advanced devs looking at dist/) and only have it generated on --local. But again not sure if it's possible or should be done as part of this PR

Also thanks for the extra refactoring and cleanup work !

@shazron
Copy link
Member Author

shazron commented Nov 2, 2020

I agree with @purplecabbage about the vscode file, that it should be generated via generator-aio-app (on init), but I think this could be addressed in another PR

I left this precisely for another PR, since I saw that comment somewhere about moving to the generator eventually.

About the dist/.env discussion, I guess one potential enhancement would be if possible to pass wskdebug vars via environment instead of dist/.env, so that we can rename dist/.env to dist/.env.local (makes the intent clearer for advanced devs looking at dist/) and only have it generated on --local. But again not sure if it's possible or should be done as part of this PR

We could pass it in as env vars instead of dist/.env, but I'm not sure what the advantage is since dist/.env is functionally equivalent and cleaner. We can rename dist/.env to anything so that is not a problem in renaming it.

@moritzraho
Copy link
Member

We could pass it in as env vars instead of dist/.env, but I'm not sure what the advantage is since dist/.env is functionally equivalent and cleaner. We can rename dist/.env to anything so that is not a problem in renaming it.

I meant to limit the cases where we generate the extra file, but ok might be more confusing to have multiple means of setting env variables indeed. Maybe we can add some comments in the generated .env instead ?

@shazron
Copy link
Member Author

shazron commented Nov 3, 2020

Ok I think I get what you mean Moritz.

  1. for --local generate the dist/.env.local with comments
  2. if --local not present, use the root .env

I will keep the existing .vscode/launch.json functionality since it was the same behaviour before (most likely so we don't potentially clobber their changes).
I will leave the vscode file generation to the generator for another PR.

@moritzraho
Copy link
Member

ok agree to do this in incremental steps 🙂

@moritzraho moritzraho self-requested a review November 3, 2020 16:13
…se dist/.env.local (file rename, with comments)
@shazron
Copy link
Member Author

shazron commented Nov 4, 2020

Travis-CI builds have stopped on this org. Migrating to Github Actions in another PR, and when that is integrated, we can merge it into this PR.

@shazron shazron merged commit 6c7f62d into master Nov 4, 2020
@shazron shazron deleted the ACNA-882 branch November 4, 2020 22:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants