| 11:14 |
csharp_ |
ehrmagerd berg squersh |
| 11:15 |
Bmagic |
lol, took me a second |
| 11:15 |
Bmagic |
csharp_++ |
| 12:03 |
Bmagic |
what's the magic trick to get the nightwatch tests to run with gecko/firefox? This is the command i'm using: mkdir $HOME/tmp; MOZ_HEADLESS=1 TMPDIR=$HOME/tmp ng e2e |
| 12:03 |
Bmagic |
error: Failed to connect to GeckoDriver on localhost with port 4444. |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:13 |
Bmagic |
just found out that firefox isn't installed, gonna install it |
| 17:11 |
|
mmorgan left #evergreen |
| 17:35 |
Bmagic |
lol |
| 17:35 |
Bmagic |
JBoyer++ |
| 17:36 |
Bmagic |
for those of us who are still here: I'm running perl live tests via "make livecheck" - and it's all passing, but it's stumbling on the offline interface check. There's this grep command: 'wget --no-check-certificate -m https://localhost/eg/staff/offline-interface 2>&1 |grep -B 2 " 404 "|grep https|grep -v robots.txt|wc -l' |
| 17:36 |
Bmagic |
which in my case returns 13, bunch of js and css files in the build folder |
| 17:47 |
Bmagic |
nevermind, figured it out :) |
| 17:47 |
csharp_ |
what was it? |
| 17:48 |
csharp_ |
localhost/docker? |
| 17:48 |
Bmagic |
rsync -L -a --no-owner --no-perms --size-only /home/opensrf/repos/Evergreen-build/Open-ILS/web/js/ui/default/staff/ /openils/var/web/js/ui/default/staff |
| 17:49 |
Bmagic |
I had performed a step out of order, and the final /openils folder needed the results of "cd /home/opensrf/repos/Evergreen-build/Open-ILS/web/js/ui/default/staff/ && npm run build-prod" |
| 17:49 |
csharp_ |
ah |
| 17:50 |
csharp_ |
hooray for tests! |
| 17:50 |
Bmagic |
yeah, the more I run them, the more I want to write more |
| 17:50 |
Bmagic |
those nightwatch tests are spectacular because they click on the interface the way humans do |
| 17:51 |
csharp_ |
still haven't found time to get to that |
| 17:52 |
Bmagic |
I'm working on bug 2068740 |
| 17:52 |
pinesol |
Launchpad bug 2068740 in Evergreen "Concerto and Enhanced Concerto user passwords should be updated" [Undecided,Confirmed] https://launchpad.net/bugs/2068740 |
| 17:52 |
Bmagic |
which, has the nasty side-effect of ruining our test suite. perl, postgres and angular/nightwatch |
| 17:53 |
Bmagic |
and violla: I got real familiar with our tests |
| 17:55 |
csharp_ |
can we just pass environment vars or something? |
| 17:55 |
Bmagic |
yeah, I know what you mean. I had the same thoughts: our tests need to be smarter |
| 17:56 |
Bmagic |
lots of hardcoded ID numbers and assumptions of the concerto set |
| 17:56 |
Bmagic |
nightwatch, for example, expects to find "BR1" in the branch list when it's siumating all of the clicks to register a workstation |
| 17:57 |
csharp_ |
ick |
| 17:57 |
Bmagic |
siumataing/simulating # lol |
| 17:57 |
Bmagic |
so, automatically, the nightwatch test requires the old concerto set and doesn't work with enhanced |
| 18:01 |
csharp_ |
Bmagic++ # doing God's work |
| 18:05 |
|
kmlussier left #evergreen |
| 18:11 |
sleary |
I have not had time to play with Nightwatch as much as I would like, but there is a recording of Jane explaining the tests somewhere in the New Devs meeting archives |
| 18:12 |
sleary |
as soon as I figure out how to make it take screenshots automatically, I will acheive documentation nirvana |
| 10:27 |
Dyrcona |
If you were hosting Aspen also, I'd suggest getting into Solr. That way there is only 1 to support. But... I suppose one could always add ES to Aspen... :) |
| 10:28 |
Rogan |
I need a face melting emoji to reply to Dyrcona's comment there |
| 10:30 |
Rogan |
joking aside, I've been working with Aspen on a mostly application end user level but hoping to dig into the guts more |
| 10:32 |
* Dyrcona |
has PRs added to Aspen. :) I have yet to set up a test Aspen installation, but it's on my list of things that I'll (probably) never get to. |
| 10:35 |
redavis |
Y'all are the best ever. Also, pretty sure my husband wasn't expecting a long diatribe aboue databases, indexes, and search when he asked how my studying for the master gardener class was going. |
| 10:35 |
berick |
ooh, Master Gardener |
| 10:35 |
berick |
nice |
| 11:22 |
redavis |
mmorgan, Bmagic, once y'all get your branches, I'll send out an email that the merge pause has been lifted. |
| 11:22 |
Bmagic |
redavis++ # rock'n roll branch'n emailer |
| 11:23 |
* mmorgan |
is just going into a meeting, will have to grab it after. |
| 11:23 |
Dyrcona |
csharp_: I have not seen that on my test systems, but granted, I don't update a whole lot of bibs all at once. We probably should consider forcing serialized updates on bibs. |
| 11:23 |
berick |
csharp_: see also the description of bug 1880726. |
| 11:23 |
pinesol |
Launchpad bug 1880726 in Evergreen "MARC Batch Edit Angular Port" [Wishlist,Fix released] https://launchpad.net/bugs/1880726 |
| 11:23 |
redavis |
I ain't got a lot of skillz, but I can email like a master...typer (with typos included) |
| 15:02 |
|
halloy1408 joined #evergreen |
| 15:05 |
|
adam_reid joined #evergreen |
| 15:09 |
|
Stompro joined #evergreen |
| 15:17 |
Dyrcona |
Hm... I should probably update the Redis branch on the server where I'm testing it. |
| 15:24 |
Dyrcona |
I wonder if I can just install it while things are running. Well, I guess I'll find out. |
| 15:30 |
Dyrcona |
That seemed to work. |
| 15:30 |
Dyrcona |
Nothing has gone boom so far.... |
| 15:11 |
mmorgan |
sandbergja++ abneiman++ redavis++ Dyrcona++ |
| 15:11 |
sleary |
Dyrcona++ |
| 15:11 |
redavis |
Dyrcona++ sandbergja++ abneiman++ mmorgan++ |
| 15:11 |
Bmagic |
#info abneiman will review existing EOLI PRs for test plans |
| 15:11 |
shulabramble |
Dyrcona++ sandbergja++ abneiman++ mmorgan++ |
| 15:12 |
abneiman |
I reviewd them but did not add test plans to any. Will do so in advance of BSW. |
| 15:13 |
Bmagic |
abneiman++ |
| 15:13 |
sandbergja |
abneiman++ # that's awesome |
| 15:13 |
shulabramble |
abneiman++ |
| 15:13 |
Bmagic |
want that carried? |
| 15:14 |
jvwoolf |
abneiman++ |
| 15:14 |
abneiman |
nah |
| 15:14 |
Bmagic |
#info abneiman will add a discussion item for next meeting: test plans for big features |
| 15:14 |
abneiman |
I ninja-edited that into the agenda 10 minutes ago :) |
| 15:14 |
Bmagic |
I see that, lol |
| 15:14 |
* redavis |
was also ninja editing |
| 15:34 |
Bmagic |
#info Needstestplan tag Added - 0 |
| 15:34 |
Bmagic |
#info Needsrebase tag Added - 5 |
| 15:34 |
Bmagic |
#info Fix Committed - 22 |
| 15:34 |
Bmagic |
#topic New Business - (Jane) How can we encourage more automated testing?, What are current barriers to writing and running the automated tests? |
| 15:34 |
sandbergja |
ok, my turn to paste some stuff: |
| 15:34 |
Bmagic |
#link https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
| 15:34 |
sandbergja |
During the 3.12 and 3.13 release process, we found a number of big issues that we were able to resolve before cutting the release, for example: |
| 15:34 |
sandbergja |
an unpredictable intermittent failure in search, a bug that prevented users from adding new action trigger event defs, a case where I had committed the wrong patch from a launchpad ticket, one where the holdings view wouldn't load, and a major accessibility regression that detached form inputs from their labels across the client. |
| 15:35 |
sandbergja |
And the way we found those was by one of our automated tests failing, alerting us to the issue, which is great! Very nice that we discovered those before they were in production. |
| 15:35 |
sandbergja |
However, it makes me think how many more regressions we could be catching if we'd been writing and running tests more often over the past 9 years. |
| 15:35 |
sandbergja |
So... I'd like to know: how can we get there? What barriers can we iron out around automated testing? |
| 15:36 |
redavis |
sandbergja++ |
| 15:36 |
shulabramble |
sandbergja++ |
| 15:37 |
Bmagic |
those node nightwatch tests are clever. Automating the process of clicking on the interface like a human would. Not sure what the barriers are? Hard to write? |
| 15:38 |
sleary |
IIRC there are two (maybe three?) different QA/guideline documents for contributions that have different instructions, and we need to consolidate them into one coherent process. |
| 15:38 |
Bmagic |
consolidate! +1. Got links? |
| 15:38 |
Stompro |
For me personally it is just the time it takes to create the tests, but I know if I do it more often it wouldn't take me as long. |
| 15:39 |
sleary |
working on links |
| 15:40 |
sandbergja |
Stompro++ sleary++ Bmagic++ |
| 15:41 |
Bmagic |
giving sleary a minute |
| 15:43 |
Bmagic |
sleary++ |
| 15:43 |
sandbergja |
consolidating and refining those seems like a great place to start |
| 15:43 |
sleary |
https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:common_qa_problems might also be relevant |
| 15:44 |
terranm |
+1 to a single page just about writing tests |
| 15:44 |
Bmagic |
do we need to make assignments around this? |
| 15:44 |
sleary |
sandbergja I will be happy to help with that... about a month from now, lolsob |
| 15:44 |
Bmagic |
sleary++ |
| 15:44 |
terranm |
sleary++ sandbergja++ |
| 15:44 |
shulabramble |
+1 to a page about writing tests |
| 15:44 |
sandbergja |
a month sounds great! And I'm also happy to help as needed! |
| 15:45 |
mmorgan |
+1 to a page about writing, and also running them |
| 15:45 |
jeff |
do we need to do anything to remove barriers to running the tests? i.e., is setting up an environment where you can run the tests challenging or not-well-documented? |
| 15:45 |
redavis |
sandbergja++ sleary++ |
| 15:45 |
sleary |
I know that sandbergja has given a couple of talks in New Devs about test-driven development, and we can pull things from those meeting archives |
| 15:45 |
redavis |
jeff, good question |
| 15:45 |
Bmagic |
#action sleary and sandbergja will create/consolidate the test writing wiki page(s) |
| 15:45 |
terranm |
It always makes sense when I watch Jane do it, but then confusion returns |
| 15:46 |
Bmagic |
jeff: the docker container image now days is including the pre-reqs which is nice |
| 15:46 |
sleary |
jeff I think there is one quirk around Firefox, but it's mentioned in the eg2 CHEAT SHEET doc |
| 15:46 |
Bmagic |
Imma preserve those wiki urls |
| 15:46 |
sandbergja |
for me, reloading a test database from scratch can take a while, and a clean db is necessary for some of the tests |
| 15:46 |
Bmagic |
#link https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:common_qa_problems |
| 15:47 |
Bmagic |
#link https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
| 15:47 |
Bmagic |
I added a feature to the the dev container, which I find myself using a bunch, that automates the creation of new databases by editing a text file |
| 15:47 |
sleary |
the e2e tests take a while to run, and the syntax for running them on a single file or directory is not easy to remember |
| 15:48 |
sandbergja |
true sleary |
| 15:48 |
sleary |
we can probably script our way out of that problem :) |
| 15:48 |
sandbergja |
Bmagic I know you've told me this before, but I gotta start using the dev containers! |
| 15:49 |
Bmagic |
sandbergja: the water is fine, lol |
| 15:49 |
Bmagic |
the takeaway was consolidating the wiki pages |
| 15:50 |
Bmagic |
shall we add something else? |
| 15:50 |
sleary |
maybe step 2 can be writing some simple example tests or pinpointing old ones as good examples for basic tasks |
| 15:50 |
sandbergja |
maybe as part of that process we can look into the syntax for nightwatch on a single file or directory -- whether it is a docs fix or a script fix? |
| 15:51 |
sleary |
sandbergja++ |
| 15:52 |
Bmagic |
making sure I'm understanding: making the test run differently depending on what was committed? |
| 15:52 |
sleary |
running the tests on only the files you changed rather than the whole Angular project |
| 15:52 |
Bmagic |
gotcha, and what's missing for that to work? |
| 15:52 |
sleary |
memorable syntax |
| 15:53 |
Bmagic |
documentation is missing basically? |
| 15:53 |
sleary |
sheet |
| 15:53 |
eeevil |
I would appreciate a how-to, for sure. fwiw |
| 15:53 |
sandbergja |
so better syntax and better docs perhaps |
| 15:54 |
Bmagic |
maybe a wrapper that takes some evergreen-community arguments. like ./wrapper --one-test path/to/file |
| 15:54 |
sleary |
that's what I was thinking, but docs would be simpler :) |
| 15:54 |
Bmagic |
docs would be simplier :) |
| 15:55 |
dluch |
docs++ ;-) |
| 15:56 |
sleary |
that should probably be a separate action from the wiki page consolidation |
| 15:56 |
Bmagic |
would you like to have it? |
| 15:56 |
sandbergja |
you could put my name on it |
| 15:56 |
Bmagic |
#action sandbergja will make it easier for folks to know how to run the tests in single file mode and all-mode |
| 15:57 |
Bmagic |
sandbergja++ |
| 15:57 |
sleary |
sandbergja++ |
| 15:57 |
sandbergja |
thanks everyone! |
| 15:57 |
dluch |
sandbergja++ |
| 15:58 |
berick |
count me in for helping with Hatch work. hopefully i can pitch in starting next week |
| 15:58 |
* berick |
runs off to another meeting |
| 15:58 |
jeff |
happy to help / help test. |
| 15:58 |
Bmagic |
berick++ |
| 15:58 |
Bmagic |
jeff++ |
| 15:58 |
sandbergja |
berick++ jeff++ |
| 16:01 |
sleary |
csharp_ most likely. I think I can, but I'm reluctant to touch things without taking time to make my own backups |
| 16:02 |
Bmagic |
I can help too :) |
| 16:02 |
Bmagic |
#action Bmagic will work on upgrading the version of DokuWiki |
| 16:03 |
Bmagic |
#topic (ABN) Test plans for big features? |
| 16:03 |
Bmagic |
We're almost done... sorry we're going over |
| 16:03 |
abneiman |
yes, so, briefly |
| 16:03 |
abneiman |
what does the community want to / need to see out of test plans for new features? |
| 16:04 |
abneiman |
things that are beyond the scope of "X is broken, install patch Y, follow steps 1 2 3, profit" |
| 16:04 |
Bmagic |
are you finding that certain things need more than our bsw and bff ? |
| 16:04 |
abneiman |
asking because several EOLI feature PRs are either forthcoming soon, or carryovers from 3.13, and I want to make sure I'm doing what is needed to facilitate review & commit of those things |
| 16:05 |
Stompro |
I always appreciate notes on how to configure the system if certain lib settings need to be enabled, etc. |
| 16:05 |
jeff |
varies, but maybe starting with: "here is a summary of / pointer to description of what this code should add/change/fix; here is a recommended way to test / how we tested; here are special considerations / gotchas"? |
| 16:05 |
abneiman |
Stompro++ jeff++ |
| 16:05 |
mmorgan |
What Stompro said. Also if certain data is needed. |
| 16:05 |
abneiman |
both helpful thanks |
| 16:05 |
abneiman |
mmorgan++ |
| 16:06 |
redavis |
Stompro++ jeff++ mmorgan++ |
| 16:06 |
abneiman |
and Bmagic, regarding BSW, I acknowlege that it's hard to test big features when there's a lot of other fixes flying around ... which is fine, IMO, that's what BSW is about. |
| 16:06 |
Bmagic |
Stompro++ jeff++ mmorgan++ |
| 16:07 |
Bmagic |
abneiman++ # I think I took your query the wrong direction after reading Stompro, jeff and mmorgan's ideas |
| 16:07 |
abneiman |
like I said, I want to make sure we're doing what we can to faciliate merges of features. And to maybe offer similar guidelines to other feature developers |
| 16:41 |
Bmagic |
csharp_: that sounds super easy |
| 16:41 |
csharp_ |
yep, and quick |
| 16:41 |
csharp_ |
just back up the folder for safety |
| 16:41 |
Bmagic |
do you have an reservations about clicking on it without testing it on a cloned env? |
| 16:41 |
csharp_ |
nah, I've done it several times |
| 16:42 |
Bmagic |
ok then, sounds like it's in good hands! |
| 16:42 |
csharp_ |
we do keep backups for 30 days on that server at ITS also |
| 10:03 |
|
kworstell_isl joined #evergreen |
| 10:07 |
Dyrcona |
Stompro: It's all right you missed the meeting. We discussed the 3.next target and some bugs. |
| 10:07 |
Dyrcona |
Also the Perl MARC code tries to deal with bad files like that. Not sure how it deals with that many nuls in a row, though. |
| 10:12 |
Stompro |
Dyrcona, if there are any specific bugs that need sign offs or more testing let me know. |
| 10:13 |
Dyrcona |
Well, there are 12 signed off bugs in total. I was going to have a look at those this week. If you want to take some, feel free. |
| 10:14 |
Dyrcona |
I'm on vacation next week. |
| 10:28 |
Stompro |
I'll take a look at them. |
| 12:09 |
jeffdavis |
disable_email_change rather, but you've found the right setting anyway :) |
| 12:09 |
* jeffdavis |
-> coffee |
| 12:27 |
|
collum joined #evergreen |
| 12:37 |
Stompro |
Dyrcona, do you have your timezone set, that was the test file that failed for me when I had the wrong timezone set. |
| 13:09 |
|
ian1 joined #evergreen |
| 13:13 |
Dyrcona |
Stompro: I do have it set. |
| 13:14 |
Dyrcona |
Reloaded the db and ran make livecheck again and everything passed. |
| 13:25 |
|
cbrown joined #evergreen |
| 13:30 |
Dyrcona |
I should not be testing this. I don't know what I'm doing, but anyway.... |
| 13:32 |
Dyrcona |
Like, how do I make a new call number prefix in the client? |
| 13:48 |
Dyrcona |
Ugh! Lp madness... There's a bug that has ended up with 2 distinct branches that were applied at different times. |
| 13:49 |
Dyrcona |
The earlier branch is basically a fix and the latter should have been a new bug, imnsho. |
| 14:18 |
Bmagic |
thats frustrating |
| 14:33 |
Dyrcona |
jeff: I am summarily removing your name from "Assigned to" on bugs you don't appear to be actively looking at. |
| 14:50 |
Dyrcona |
Grabbing 1423. |
| 14:56 |
pinesol |
News from commits: LP2048425: Increase test coverage for circ limit sets <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=221725a66032d2087481798db6c77b7bd7b7eccc> |
| 15:00 |
|
mantis left #evergreen |
| 15:11 |
jeff |
Dyrcona: sounds good. any bugs in particular, or are you just removing me from everything? |
| 15:26 |
pinesol |
News from commits: LP2065448 Stamp DB upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0d306102f3480042647c92cacf01fde329a0bc6b> |
| 15:36 |
Dyrcona |
Don't think the Lp advanced search URLs survive getting pasted into IRC. |
| 15:37 |
Dyrcona |
jeff: Turns out it is only 1 bug so far. |
| 15:38 |
|
SREtds-lib joined #evergreen |
| 15:52 |
Dyrcona |
JBoyer | Bmagic: Do you know if anyone is using Lp 1613335 in production? I'm going to test it and if it works, I'll push it for 3.14. |
| 15:53 |
pinesol |
Launchpad bug 1613335 in Evergreen "SIP Return Screen Message OK" [Low,Confirmed] https://launchpad.net/bugs/1613335 - Assigned to Jason Stephenson (jstephenson) |
| 15:54 |
Bmagic |
awesome, I'm using it in production |
| 15:56 |
Dyrcona |
Bmagic: Your branch or JBoyer's? I'm going to push the one that makes it optional. |
| 16:02 |
jeff |
(behind a config option for existing installs, i should say) |
| 16:02 |
Dyrcona |
jeff: Yeah, it's a setting on the login element. |
| 16:02 |
jeff |
yup, reviewed. :-) |
| 16:02 |
Dyrcona |
I'm going to test with two of ours copied from production: one I'll add the setting the other I won't. |
| 16:05 |
Dyrcona |
Oof. I might not have my SIP test code on this vm any more... |
| 16:16 |
Dyrcona |
Then, I have to modify the script for different file locations.... :) |
| 16:21 |
Dyrcona |
And, it works for me! |
| 16:21 |
Dyrcona |
After all these years.... :) |
| 10:58 |
|
ian1 joined #evergreen |
| 11:32 |
|
ian1 joined #evergreen |
| 11:32 |
|
mantis joined #evergreen |
| 11:32 |
mantis |
could use some guidance on this error I got when applying 3.11.7 to our servers from 3.11.4 |
| 11:32 |
mantis |
/usr/share/perl5/Error.pm:465', ilsevent: '', textcode: 'RESOURCE_IN_USE', desc: 'Resource is in use at this time'} |
| 11:33 |
mantis |
I ran a browser test after compiling the Angular files |
| 11:33 |
mantis |
We never use the booking module so this is kind of new to me |
| 11:33 |
mantis |
'/usr/local/share/perl/5.30.0/OpenILS/Application/Booking.pm:213 /usr/local/share/perl/5.30.0/OpenSRF/Application.pm:628 |
| 11:35 |
Dyrcona |
mantis: Disable booking in the configuration. |
| 11:35 |
Dyrcona |
If you don't use it. |
| 11:35 |
mantis |
thanks! |
| 11:52 |
mantis |
Firefox 128.0 (Ubuntu 0.0.0) CashReportsComponent alerts the user if end date is before start date FAILED |
| 11:52 |
mantis |
NullInjectorError: R3InjectorError(DynamicTestModule)[PrintService -> PrintService]: |
| 11:52 |
mantis |
NullInjectorError: No provider for PrintService! in vendor.js (line 66717) |
| 11:52 |
mantis |
error properties: Object({ ngTempTokenPath: null, ngTokenPath: [ 'PrintService', 'PrintService' ] }) |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:07 |
mantis |
I'm also testing out Hatch and the Print button within Cash Reports |
| 12:07 |
Dyrcona |
Don't know. Open a bug on Lp. |
| 12:07 |
mantis |
okie doke |
| 12:08 |
mantis |
Dyrcona++ |
| 12:08 |
Dyrcona |
I am almost never run those tests. |
| 12:13 |
mantis |
looks like we need a template for the cash reports now because as far as I know, with Hatch enabled, it doesn't print |
| 12:50 |
Stompro |
Anyone here work with Cloudlibrary? |
| 12:51 |
Stompro |
I've been asked to setup auth, and I'm having trouble with them not being willing to explain how they want to encrypt sip2. |
| 15:27 |
Dyrcona |
No, commit isn't necessary with cherry-pick. |
| 15:29 |
mantis |
thank you ! Dyrcona++ |
| 15:30 |
Dyrcona |
Oh. I just noticed it looks like your original branch was based on something else... |
| 15:32 |
Dyrcona |
hey! That's already a lot of signoffs. I wonder if I should even bother testing this... :) |
| 15:32 |
Dyrcona |
mantis++ |
| 15:32 |
mantis |
ah I see |
| 15:32 |
mantis |
that must had been it then |
| 09:30 |
|
Guest14 joined #evergreen |
| 09:52 |
|
cbrown joined #evergreen |
| 10:01 |
|
mantis joined #evergreen |
| 10:01 |
mantis |
running through the 3.11.6 ver install on a test server and I got a lot of these errors when building our Angular files |
| 10:01 |
mantis |
ex; Error: src/main.ts:1:32 - error TS2307: Cannot find module '@angular/core' or its corresponding type declarations. |
| 10:01 |
mantis |
not sure why this is a problem now |
| 10:03 |
JBoyer |
mantis, that looks like you're either running the "build from git" instructions when you don't need to or if you are installing from git maybe missed one of the pre-req install steps? |
| 10:03 |
mantis |
this is the command |
| 10:03 |
mantis |
ng build --configuration production |
| 10:04 |
JBoyer |
The npm install step is what I'm wondering about, that's what pulls down things like angular core and friends. |
| 10:04 |
mantis |
I know it's technically outdated |
| 10:05 |
mantis |
also run into this after running CHROME_BIN=/usr/bin/chromium-browser npm run test |
| 10:05 |
mantis |
23 07 2024 09:59:20.061:ERROR [karma-server]: Error: Found 1 load error |
| 10:05 |
mantis |
at Server.<anonymous> (/home/opensrf/Evergreen-ILS-3.11.6-biblio/Open-ILS/src/eg2/node_modules/karma/lib/server.js:243:26) |
| 10:05 |
mantis |
at Object.onceWrapper (node:events:631:28) |
| 10:05 |
mantis |
at Server.emit (node:events:529:35) |
| 10:05 |
mantis |
at Server.emit (node:domain:489:12) |
| 10:05 |
mantis |
at emitListeningNT (node:net:1851:10) |
| 10:05 |
|
ian1 joined #evergreen |
| 10:06 |
JBoyer |
is there anything in /home/opensrf/Evergreen-ILS-3.11.6-biblio/Open-ILS/src/eg2/node_modules and was a different version of Evergreen installed previously? |
| 10:06 |
mantis |
I'll check |
| 10:18 |
mantis |
Yeah it had Evergreen 3.11.4 on here |
| 10:18 |
mantis |
though I am comparing angular/core directories and there are a couple of differences |
| 10:18 |
Dyrcona |
Well, that's not old enough to cause issues with different node versions. |
| 10:18 |
mantis |
esm2020 and testing folders are not in evgtest2 |
| 10:19 |
mantis |
Dyrcona++ |
| 10:19 |
mantis |
I'll try the reinstallation |
| 10:20 |
Dyrcona |
I wonder if something made it into 3.11.6 that should not have? I built it. It installed fine from the tarball, but I did not attempt an upgrade. |
| 10:20 |
mantis |
should I remove the node_modules before or after running the build commands? |
| 10:21 |
Dyrcona |
BTW, I am working on Lp2060734 again today. I've made a couple of releases with it, and I'm about to test the results of those releases on Debian Bookworm and Ubuntu 24.04, so I'm also in the middle of doing installations. |
| 10:21 |
Dyrcona |
Lp 2060734 |
| 10:21 |
pinesol |
Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 10:23 |
Dyrcona |
I should build one from git, maybe. |
| 11:37 |
|
ian1 joined #evergreen |
| 11:45 |
|
Christineb joined #evergreen |
| 11:50 |
|
ian1 joined #evergreen |
| 11:52 |
Dyrcona |
Does anyone know OTTOTH of a branch with a database upgrade other than the reports permissions branch? (I've applied it already for my test purposes.) |
| 11:52 |
Dyrcona |
I think I have one hanging around maybe. It might have gone in. |
| 11:56 |
Dyrcona |
I can use Lp 1835953 |
| 11:57 |
pinesol |
Launchpad bug 1835953 in Evergreen "Circulation auto renewal remaining should not be nullable" [Medium,Confirmed] https://launchpad.net/bugs/1835953 |
| 11:57 |
Dyrcona |
Hm... something wrong with my configuration. The two tests that depend on apache failed. |
| 11:59 |
Dyrcona |
I'll look into it after lunch. |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:19 |
JBoyer |
To this day I do not understand rooibos tea. (At least that one, I know there's more than one type.) |
| 12:40 |
Dyrcona |
Looks like my problem was nginx needed a restart. |
| 12:41 |
* Dyrcona |
has never had rooibos tea. |
| 12:42 |
Dyrcona |
Ok. gonna test my fake upgrade from 3.14.0 to 3.14.1, then I'll do 3.14.1 to 3.14.2.... :) |
| 12:46 |
Dyrcona |
Think I'll do somethin' unorthodox... I'll reinstall the 3.14.0 schema and data, then run the db upgrade, and then install 3.14.1. After that, I'll run the tests. |
| 13:01 |
|
cbrown_isl joined #evergreen |
| 13:03 |
Dyrcona |
So, that works... |
| 13:05 |
|
cbrown joined #evergreen |
| 14:18 |
sandbergja |
It looks good to me! |
| 14:19 |
Dyrcona |
OK. I moderately prefer deleting the line over modifying it. |
| 14:19 |
sandbergja |
agree, it does seem cleaner |
| 14:21 |
Dyrcona |
OK. That's the one we'll go with. I'm basically done. I'll update the Lp bug and add some instructions for testing it in a comment. I exercised just about everything it does. |
| 14:24 |
Dyrcona |
I'm going to give that commit another test or two first. |
| 14:25 |
sandbergja |
woo hoo! Thanks so much, Dyrcona! |
| 14:33 |
Dyrcona |
sandbergja++ This branch will make certain aspects of the releases so much easier. |
| 14:34 |
sandbergja |
I'm glad! And we as a community can keep chipping away at it. |
| 10:06 |
mmorgan |
mantis: Point releases are out! https://evergreen-ils.org/ |
| 10:08 |
mantis |
sweet thanks! |
| 10:17 |
|
redavis joined #evergreen |
| 10:27 |
ian1 |
It appears we may not have postgresql logs enabled for our test servers. I was able to get this log from `/openils/var/log/osrfsys.log`: |
| 10:27 |
ian1 |
[2024-07-22 09:59:55] /usr/sbin/apache2 [ACT:20655:Search.pm:480:17214480092065521] EGWeb: [bre search] item_lang:por filter_group_entry(4) depth(0) |
| 10:28 |
ian1 |
lol. It grabbed ':' 'p' and made an emoji, but let it be known that was not in the logs. |
| 11:03 |
Dyrcona |
ian1: Emojis depend on the client. I turned them off for this reason. |
| 11:07 |
Dyrcona |
ian1: PostgreSQL also doesn't log much by default, sometimes not even bad queries. In this case I think you have a long-running query. |
| 11:07 |
Dyrcona |
Oh, bummer. |
| 11:14 |
|
ian1 joined #evergreen |
| 11:16 |
ian1 |
Just walked away and I see I missed some chat in the logs. The query is definitely very long running. I don't know why that might be and I don't know why the results are empty. If I used the `item_lang` field in a traditional search in opac it returns results no problem. |
| 11:17 |
Dyrcona |
KPAC might not run the exact same query. It probably add audience filters. If you can get PostgreSQL to log the query, you can attempt to see what's wrong. |
| 11:18 |
ian1 |
I assumed that and added audience filters in my OPAC search in an attempt to simulate that. Let me check on enabling the logs and once again come back to you guys. Thank you as always. |
| 11:30 |
ian1 |
It looks like the postgreSQL log options for our test servers are outside my jurisdiction for now. I can try to test this locally for now and ping my server admin when hes back in office. I'm using the dev version of the evergreen-ils docker image. As far as I can tell, it doesnt have test data by default, but if I can load some up, I can definitely change the log settings there. Any suggestions? |
| 11:38 |
Dyrcona |
Test data is not the same as production data. My suspicion is you likely need to do a vacuum analyze or possibly a reindex in production. You might also be missing an index. |
| 11:40 |
ian1 |
Makes sense. This might have to wait until I have access to someone with the authority to do that here. Appreciate the discussion. |
| 11:42 |
Dyrcona |
It might be good to ask about getting a test environment with production data for situations like this. |
| 11:45 |
mmorgan |
ian1: As Dyrcona says, production data is the ultimate test, but testing on a limited dataset is valuable also to confirm the logic works. |
| 11:52 |
ian1 |
Heard. Thanks everyone. :-D |
| 12:00 |
|
ian1 joined #evergreen |
| 12:01 |
|
jihpringle joined #evergreen |
| 08:53 |
|
Dyrcona joined #evergreen |
| 08:53 |
|
mantis joined #evergreen |
| 09:32 |
|
jvwoolf joined #evergreen |
| 10:55 |
Dyrcona |
stompro: I'm going to have another look at Lp 2054842. I want to rebase the branches and run the tests again. Don't let that stop you from looking at them if you wish. |
| 10:55 |
pinesol |
Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,In progress] https://launchpad.net/bugs/2054842 - Assigned to Jason Stephenson (jstephenson) |
| 11:00 |
Dyrcona |
I think the issue is that some test fail on a remote database, but they succeed if the test is local, and IIRC, I've seen that not just on Ubuntu 24.04, but other distros as well. |
| 11:01 |
Dyrcona |
Ugh. I mean if the database is on a remote server, some of the tests seem to fail, and if the database is local, they succeed. |
| 11:02 |
pinesol |
News from commits: LP2018014: Add release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=588da520d3def40fdf89f586b920d6e65502543a> |
| 11:04 |
jeff |
are the failing tests failing because they have pre-reqs that aren't in the database server pre-req Makefile target(s)? |
| 11:55 |
|
ian1 joined #evergreen |
| 12:32 |
|
redavis joined #evergreen |
| 12:41 |
|
Christineb joined #evergreen |
| 13:17 |
Dyrcona |
jeff: I don't think so. I pasted it here before. One of them doesn't find as many bills as it expects. |
| 13:20 |
Dyrcona |
Here's one place I mentioned the failing tests before and eliminated Pg 16 as the culprit: http://irc.evergreen-ils.org/evergreen/2024-06-24#i_555023 |
| 13:27 |
Dyrcona |
I was also considering the possibility that Lp 2060734 caused it. I had that one, Lp 2054842 and Lp 2037656 applied. I also tested wit an older release, IIRC, and got failures on a remote database with all the prerequisites installed. (I have a test db server with everything installed that I use all the time and it works for normal operations.) |
| 13:27 |
pinesol |
Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 13:27 |
pinesol |
Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,In progress] https://launchpad.net/bugs/2054842 - Assigned to Jason Stephenson (jstephenson) |
| 13:27 |
pinesol |
Launchpad bug 2037656 in Evergreen "Add Support for PostgreSQL 16" [Wishlist,Confirmed] https://launchpad.net/bugs/2037656 |
| 13:29 |
|
kworstell_isl_ joined #evergreen |
| 13:30 |
|
kworstell_isl_ joined #evergreen |
| 13:32 |
|
kworstell_isl joined #evergreen |
| 13:58 |
Dyrcona |
Testing on Ubuntu 24.04 with local Pg 16, make check and make livecheck pass. |
| 14:25 |
Dyrcona |
Sure is slow running the tests over the Internet. :) |
| 14:30 |
Dyrcona |
Up to 24-login-ap.t and it looks like they've all passed so far. I was getting failures before this in the past. Maybe it's just one of those things? Maybe jeff was right about something missing, but the failing tests didn't seem like ones where it would matter. |
| 14:32 |
|
jvwoolf joined #evergreen |
| 14:49 |
Dyrcona |
Hey! make livecheck passed this time. |
| 14:59 |
|
kworstell-isl joined #evergreen |
| 15:29 |
sandbergja |
I was hoping we could go back to the previous discussion, and pull out one or two bitesize items that we could make progress on *in this meeting* |
| 15:29 |
abneiman |
ok - did you have your eye on a couple items in particular? |
| 15:29 |
redavis |
fer sure. But I do like the idea of someone being able to checkout a virtual machine. Just used that in a class and it was delightful. |
| 15:29 |
sandbergja |
so not like move git hosting or setting up a VM checkout system, but... like more guidance on backporting. Or doing something proactive about existing pull requests without test plans |
| 15:30 |
jeffdavis |
Would a "needstestplan" tag be useful or is that just kicking the can down the road some more? |
| 15:30 |
redavis |
jeffdavis++ |
| 15:30 |
sleary |
was just thinking that, jeffdavis |
| 15:31 |
abneiman |
it's certainly a start |
| 15:31 |
abneiman |
jeffdavis++ |
| 15:31 |
Dyrcona |
For testing, we do have this old document: https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
| 15:31 |
Dyrcona |
It basically says, you must include tests. |
| 15:32 |
jeffdavis |
I think " a plan for how to test if the fix works" is not necessarily the same as the automated tests contemplated there. |
| 15:32 |
jeffdavis |
Although automated tests are certainly ideal. |
| 15:32 |
sleary |
correct. |
| 15:32 |
abneiman |
yes, I was going to say - not everything is automatically-testable |
| 15:32 |
redavis |
I think there are both code tests and feature tests. |
| 15:33 |
sleary |
and I think that document is not entirely up to date with our current translation process. |
| 15:33 |
abneiman |
and in fact, we do have a "needstest" LP tag which indicates that an automated test is needed (and is often misapplied by people who think it means "please test this") |
| 15:34 |
sandbergja |
It seems to me that the automated test part of that document has been more or less ignored for 9 years... It is pretty unusual to see any code submitted _with_ automated tests. |
| 15:34 |
|
kworstell-isl joined #evergreen |
| 15:34 |
Dyrcona |
True. We have not been enforcing it. Commit messages explaining how to test have been acceptable, too. |
| 15:34 |
redavis |
there's a nuance differentiating needstest and needstestplan |
| 15:44 |
Dyrcona |
sandbergja: In keeping the bazaar atmosphere, I think anyone could offer a test plan, though it would be better coming from the original patch author. |
| 15:44 |
abneiman |
yes, I was basically typing what Dyrcona just said re test plan |
| 15:44 |
redavis |
Dyrcona++ |
| 15:44 |
mmorgan |
I also think anyone could offer a test plan. |
| 15:44 |
sandbergja |
Dyrcona++ |
| 15:44 |
shulabear |
Dyrcona++ |
| 15:44 |
abneiman |
and +1 to the tag being only applicable to pr'd items |
| 15:45 |
jeffdavis |
IMO it should be an expectation that the author provides the test plan, but I agree anyone could do it. |
| 15:45 |
abneiman |
OK, so, I think we have a few items of agreement here: |
| 15:45 |
redavis |
And maybe worth noting that there might be people who excel at test plans but not other stuff and vice versaish. |
| 15:45 |
shulabear |
redavis++ |
| 15:59 |
Dyrcona |
sandbergja++ Thanks for taking it on. |
| 15:59 |
sandbergja |
abneiman: good question |
| 16:00 |
Dyrcona |
yeah, bug fix tests should be easier than new features, unless the feature is really simple. |
| 16:00 |
abneiman |
because with features, it's not as simple as "do A and get B" - which is why we (Equinox) try to include documentation and tech ref docs with new features, along with extensive commit messages |
| 16:01 |
abneiman |
but, if you all would rather us put out more formal test plans, I can work on that as well |
| 16:01 |
|
rlefaive joined #evergreen |
| 16:01 |
abneiman |
however, we are at the top of the hour so maybe "test plans for big features" could be a future topic |
| 16:02 |
sandbergja |
yeah, that might be where it gets trickier |
| 16:02 |
dluch |
+1 |
| 16:03 |
redavis |
also +1 |
| 16:03 |
abneiman |
#action discussion item for next meeting: test plans for big features |
| 16:03 |
abneiman |
that even might be a worthy hackaway topic |
| 16:03 |
abneiman |
anyway. |
| 16:04 |
abneiman |
anything else to discuss? Anything that I forgot? Any parting words of wisdom? |
| 16:04 |
redavis |
stay hydrated |
| 16:04 |
eeevil |
never start a land war in ... oh, nevermind |
| 16:04 |
abneiman |
#agree we're all gonna stay hydrated |
