search

connectivedx / Phoenix

http://connectivedx.github.io/Phoenix/
33 stars 5 forks source link

Analyze Build Redux #131

Open ajmueller opened 9 years ago

ajmueller commented 9 years ago

Before the current iteration of the build system was built by @kamsar, we had an "analyze" build. That build went the way of the Dodo due to the driver architecture of the build process (so @kamsar if this idea is totally impossible, let me know), but I think it may be worth discussing again considering our recent internal discussions around practice groups and standards. Those standards could be more easily enforced with a build process for analysis, especially during code reviews. Some ideas and packages to use:

Thoughts?

kamsar commented 9 years ago

tbh I think any sort of analysis is a bit toothless as long as it's something optional you have to run (which is why it was removed during the build update).

IMO, if analysis is brought in it should run as part of the build and fail the build if analysis finds problems. Yes, you may have to disable some analysis features you dont agree with. But the old analyze build was never used.

The scripts should support this idea fairly easily.

jbascue commented 9 years ago

That model works for Visual Studio.

I miss the analysis and liked where Alex was going with the idea of bringing it back, but I really like the idea of it being integrated right into the build like this a lot. It enforces standards that much better. On Sat, Apr 4, 2015 at 1:48 PM Kam Figy notifications@github.com wrote:

tbh I think any sort of analysis is a bit toothless as long as it's something optional you have to run (which is why it was removed during the build update).

IMO, if analysis is brought in it should run as part of the build and fail the build if analysis finds problems. Yes, you may have to disable some analysis features you dont agree with. But the old analyze build was never used.

The scripts should support this idea fairly easily.

— Reply to this email directly or view it on GitHub https://github.com/connectivedx/Phoenix/issues/131#issuecomment-89661916 .

stoff commented 9 years ago

Just would like to add to the chorus of "should be part of the build", however, we'd want to look a little more closely at annoyances this may cause in a watch build.

Specifically I'm thinking of times when an unnoticed JS error has stopped my watch and I don't notice until after I've already noticed the bad save, fixed the issue, and then refreshed my browser (only to discover, shock!, that my changes don't appear or that the css is not reloading)

Also useful might be writing a log since there are times when the error report may be longer than the user's terminal buffer.

ajmueller commented 9 years ago

:+1: for writing to a log. That was one feature about our previous analyze build that I wasn't a fan of: only console output.

kamsar commented 9 years ago

$ build-dev.command > build.log :)

Saucy console tricks aside, if your error list is really longer than your terminal buffer uh...that's a problem.

ajmueller commented 9 years ago

Ooooh, nice. That would seemingly be easy to incorporate into the shell scripts then, right? I personally find it nicer to read a file in a text editor than a console window, so having a consistent log would be nice.

kamsar commented 9 years ago

http://en.wikipedia.org/wiki/Tee_%28command%29 would work to send to console AND log Some of the validators may also have built in file logging options.