Support building the browser client via Evergreen 'make'

Bug #1791162 reported by Bill Erickson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Wishlist
Unassigned

Bug Description

It should be possible for developers to build the browser client via Evergreen 'make' instead of having to run separate processes in the web directories. This option should be disabled by default, since most end users won't need it (or have the necessary prerequisites installed).

Patch to support this as a ./configure option and make_release support en route.

Revision history for this message
Bill Erickson (berick) wrote :

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/lp1791162-makefile-browser-client-build

1. Adds --enable-build-web-client configure option
2. Teaches make_release to use the configure option when browser client building is enabled.
3. Enable browser client building by default. -c now disables browser client building.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
status: In Progress → New
Revision history for this message
Bill Erickson (berick) wrote :

Note the branch linked sits atop the Angular6 branch, since it includes code related to that. Only the tip commit is for this bug.

Galen Charlton (gmc)
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Wishlist
assignee: nobody → Galen Charlton (gmc)
Revision history for this message
Galen Charlton (gmc) wrote :

Initial results of testing: I think this needs a little more time to bake and should not hold up the beta (though it makes sense to keep this in mind for the release candidate).

One minor problem (or request): it would be nice if a top-level 'make check' invoked the webstaff and eg2 unit tests.

Of more import: the npm build steps run /every/ time you do a make, including for a make install, which of course is usually done as sudo root. That means that node_modules and the like get their ownership changed to root, making subsequent makes as the dev user fail due to file permission issues. This is awkward, to say the least.

Also, Open-ILS/web/eg2 should be included in a clean.

Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Revision history for this message
Bill Erickson (berick) wrote : Re: [Bug 1791162] Re: Support building the browser client via Evergreen 'make'

On Thu, Sep 6, 2018 at 6:31 PM Galen Charlton <email address hidden>
wrote:

> Initial results of testing: I think this needs a little more time to
> bake and should not hold up the beta (though it makes sense to keep this
> in mind for the release candidate).
>

Thanks, Galen

>
> One minor problem (or request): it would be nice if a top-level 'make
> check' invoked the webstaff and eg2 unit tests.
>

+1

>
> Of more import: the npm build steps run /every/ time you do a make,
> including for a make install, which of course is usually done as sudo
> root. That means that node_modules and the like get their ownership
> changed to root, making subsequent makes as the dev user fail due to
> file permission issues. This is awkward, to say the least.
>

Ugh, yeah, needs fixing.

>
> Also, Open-ILS/web/eg2 should be included in a clean.
>

These files need to stick around so make_release can include them in the
final build. For what it's worth, the contents of the eg2 sub-directories
are wiped with each 'ng build'.

Changed in evergreen:
milestone: 3.2-beta → 3.2-rc
Changed in evergreen:
milestone: 3.2-rc → 3.2.1
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Revision history for this message
Jason Stephenson (jstephenson) wrote :

I bumped the target to 3.2.2 even though this should probably be targeted at 3.next as a new feature at this point.

Revision history for this message
Evergreen Bug Maintenance (bugmaster) wrote :

I agree with Jason's suggestion. Bumping this to 3.3-beta1.

- Remington

Changed in evergreen:
milestone: 3.2.2 → 3.3-beta1
Dan Wells (dbw2)
Changed in evergreen:
milestone: 3.3-beta1 → 3.next
tags: added: install-upgrade
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.