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

Update build and serve APIs to make use of package:build_daemon #352

Open
natebosch opened this issue Aug 9, 2017 · 8 comments
Open

Update build and serve APIs to make use of package:build_daemon #352

natebosch opened this issue Aug 9, 2017 · 8 comments

Comments

@natebosch
Copy link
Member

No description provided.

@natebosch natebosch added this to the build_runner + DDC milestone Aug 9, 2017
@jakemac53
Copy link
Contributor

For now this is probably enough, but we need to come up with a design for the testing story as well, and that will require running a separate test command most likely while a regular build/serve are happening?

@natebosch
Copy link
Member Author

Yeah I think eventually we'll want to make them cooperate across processes somehow

@matanlurey
Copy link
Contributor

A simple mechanism could be a build.lock-file for now, no?

@jakemac53
Copy link
Contributor

yes for now something like that would be an improvement

@matanlurey matanlurey self-assigned this Dec 23, 2017
@jakemac53 jakemac53 added the P1 A high priority bug; for example, a single project is unusable or has many test failures label Jan 8, 2018
@jakemac53
Copy link
Contributor

Moving to M1, you have to be a bit careful about how you use watch/serve together with test today (among other scenarios) but solving this properly is going to take some work.

@jakemac53 jakemac53 modified the milestones: MVP: Replace `pub serve`, M1: Future priority Jan 10, 2018
@matanlurey matanlurey removed their assignment Feb 24, 2018
@aaronlademann-wf
Copy link
Contributor

aaronlademann-wf commented Feb 7, 2019

@jakemac53 can you elaborate on what you mean by

a bit careful about how you use watch/serve together with test today

What I'm seeing right now (and the core team that works on https://github.com/Workiva/over_react are trying to figure out) is... is it actually possible to be serving, lets say - the example/ dir, and then run tests via pub run build_runner test simultaneously - without first stopping the serving of the example dir - without destroying the asset graph?

Any guidance / current workarounds would be very appreciated and welcome.

cc/ @robbecker-wf @evanweible-wf @corwinsheahan-wf @greglittlefield-wf

@jakemac53
Copy link
Contributor

@aaronlademann-wf right now the only safe thing to do is kill the other server before running tests - which is obviously not a great solution.

However, @grouma has been actively working on the build_daemon which solves this problem (there is already a daemon command actually, and you can use the build_daemon package to create a client if you want to play with it). It is already integrated into the webdev package at HEAD, but is still a little ways off from being released as we are actively working through all the edge cases. We will integrate it with the built-in build_runner commands once it is ready for prime time as well.

This is a fairly fundamental change and there will be some restrictions - for instance you won't be able to provide different build flags from different clients (it will ask you to kill the existing server in that case before running tests).

@jakemac53
Copy link
Contributor

Assigning Gary as he has been the one working on this, I forgot we actually had an issue filed :).

@grouma grouma removed the P1 A high priority bug; for example, a single project is unusable or has many test failures label Jun 26, 2019
@grouma grouma changed the title Add some type of locking so multiple build/watch can't step on eachother Update build and serve APIs to make use of package:build_daemon Jun 26, 2019
@grouma grouma removed their assignment Jun 26, 2019
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

5 participants