| Time |
Nick |
Message |
| 01:27 |
|
sandbergja joined #evergreen |
| 01:41 |
|
dbwells__ joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-27T04:58:30,783957438-0400 -0> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
Dyrcona joined #evergreen |
| 08:19 |
|
agoben joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:48 |
|
bos20k joined #evergreen |
| 08:54 |
|
bos20k joined #evergreen |
| 09:16 |
|
yboston joined #evergreen |
| 09:26 |
|
sandbergja joined #evergreen |
| 09:41 |
dbwells |
Does anyone have a good idea why the live tests are failing? |
| 09:42 |
dbwells |
We have the June release waiting in the wings, but I've been hoping someone would step up and poke at that. |
| 09:44 |
|
aabbee joined #evergreen |
| 09:52 |
JBoyer |
I'm trying to load master on one of my test machines so I can look at that. |
| 09:52 |
JBoyer |
I'm having issues unrelated to Evergreen at the moment though, so it's taking longer than I'd hoped. |
| 09:54 |
Dyrcona |
I've had live tests, in particular, fail for seemingly random reasons. Sometimes, a db reload of concerto resolves it, sometimes it fixes itself after a couple of reloads. |
| 09:55 |
|
Christineb joined #evergreen |
| 09:55 |
Dyrcona |
Our test coverage is weak, and the tests themselves are dependent on all of the preconditions being just so. |
| 09:55 |
JBoyer |
This one has been annoyingly consistent and shouldn't involve the database in any real way. |
| 09:56 |
Dyrcona |
My previous statement still applies. :) |
| 09:57 |
JBoyer |
True, I was (slowly) replying to your previous previous statement, heh. |
| 09:57 |
|
stephengwills joined #evergreen |
| 09:58 |
Dyrcona |
Someone forget --create-offline when doing eg_db_config? |
| 10:21 |
csharp |
trying to recreate the test failure on my dev machine - I ran "prove" in the perlmods directory and all the tests passed |
| 10:21 |
csharp |
(on 3.1.13) |
| 10:22 |
Dyrcona |
I'm setting up a vm with our production branch on it. After yesterday's weird errors, I decided I should rebuild the vm from scratch. |
| 10:22 |
Dyrcona |
I'll try the failing test on it. |
| 10:25 |
csharp |
same with the master branch |
| 10:25 |
csharp |
All tests successful. Files=25, Tests=3250, 18 wallclock secs ( 0.43 usr 0.06 sys + 16.57 cusr 1.12 csys = 18.18 CPU) Result: PASS |
| 10:26 |
csharp |
(this is on Ubuntu 16.04, perl 5.22.1 |
| 10:26 |
csharp |
) |
| 10:29 |
Dyrcona |
Funn thing: While installing OpenSRF, I forgot the ldconfig step and OpenSRF still worked for the srfsh test. This is on Ubuntu 16.04. I've since done the ldconfig test, 'cause I suspect Evergreen and the Apache stuff depends on it. |
| 10:32 |
* Dyrcona |
is having one of those mornings... |
| 10:37 |
csharp |
oh - duh - those are live tests |
| 10:38 |
csharp |
hmm - not remember how to run those... |
| 10:41 |
csharp |
ah - make livecheck |
| 10:41 |
jeff |
This is how the qatests run the live tests: https://git.evergreen-ils.org/?p=working/random.git;a=blob;f=installer/stretch/eg_stretch_installer.sh;h=fdc96c54a9ec1d9b5701ac0ee4475a40589b8837;hb=2997e070d001c2448baad643e1d00560bd7a82f2#l1012 |
| 10:43 |
csharp |
jeff++ # thanks |
| 10:43 |
csharp |
mine are failing because my admin user doesn't have the password expected by the testes |
| 10:43 |
csharp |
tests |
| 10:50 |
Dyrcona |
csharp: You can also run prove on the live test directory or run them individually with prove or perl |
| 10:50 |
csharp |
Dyrcona: oh - good to know |
| 10:50 |
csharp |
I figured it was simple - I just haven't done it much and for a long time |
| 10:51 |
jeff |
when running individually, i'm pretty sure there are still assumptions that they all run once, in order. |
| 10:51 |
jeff |
i.e., later tests rely on the state left behind by earlier tests. |
| 10:52 |
jeff |
though we may have gotten away from that, in which case i missed it. |
| 10:56 |
Dyrcona |
jeff: They really should be totally independent of each other, but the offline test doesn't depend on any others. |
| 10:57 |
Dyrcona |
Like I said before.... :( |
| 10:57 |
Dyrcona |
But no one is paying to write tests, so... |
| 11:04 |
csharp |
might be something to consider for some of the dev-funding coops |
| 11:06 |
|
khuckins joined #evergreen |
| 11:24 |
JBoyer |
Writing the specs for writing test could be a fun one. dev:"This is just a sheet of paper with the words '100% codepath coverage' on it." user:"Yes. How much is that?" dev:"How much money exists?" |
| 11:26 |
csharp |
JBoyer++ |
| 12:04 |
Dyrcona |
So, for the logs 24-offline-all-assets.t succeeds for me on 3.2.4-custom+backports. |
| 12:05 |
Dyrcona |
Fun thing... Using haproxy on my test vm, I know get 504 Gateway Timeout instead of no search results. :) |
| 12:06 |
Dyrcona |
Now, to see if the complete rebuild resolves my missing web client files issue from yesterday morning's tests. |
| 12:07 |
Dyrcona |
Apparently, it did, so the breakage was unrelated to haproxy. |
| 12:08 |
Dyrcona |
So far, haproxy++ |
| 12:09 |
Dyrcona |
Oh, look at that! Time for lunch! :) |
| 12:22 |
|
jihpringle joined #evergreen |
| 12:22 |
|
nfBurton joined #evergreen |
| 12:58 |
Dyrcona |
So, I see something today that contradicts what I swear I saw in the code...It looks like doing a --process-hooks with no granularity does pick up events that have a granularity set. I swear that I saw the query deliberately looking for null granularity, though. |
| 13:03 |
csharp |
I thought you had to say --granularity-only to pick up ones with granularity, but it's been a while since I looked closely |
| 13:04 |
csharp |
maybe that's not for --process-hooks |
| 13:08 |
Dyrcona |
csharp: I'm testing some things. I removed --process-hooks from the one that runs with a granularity. |
| 13:08 |
Dyrcona |
s/with/without/ |
| 13:08 |
Dyrcona |
The others have a granularity but not --granularity-only and they seem to work OK. |
| 13:09 |
Dyrcona |
The only that has --granularity-only in my current set up is the password reset. |
| 13:10 |
Dyrcona |
I've deleted an event that was created earlier and I want to see if the hourly granularity picks it up. |
| 13:10 |
csharp |
interestingly, I don't see --granularity-only referred to in the script or the help |
| 13:10 |
Dyrcona |
Must be an appendix... :) |
| 13:11 |
csharp |
ah - I see it now |
| 13:11 |
csharp |
(in the code, not the help) |
| 13:11 |
csharp |
)@ana grep fail |
| 13:11 |
csharp |
@ana grep fail |
| 13:12 |
pinesol |
csharp: Flip rage |
| 13:12 |
Dyrcona |
:) I was about to say.... |
| 13:12 |
Dyrcona |
I see it in 3.2.4. |
| 13:13 |
Dyrcona |
Looks like it only affects pending events. |
| 13:13 |
Dyrcona |
And the lockfile name. |
| 13:20 |
Dyrcona |
I see.... If --granularity-only is used, it will only run pending events for that granularity. |
| 13:21 |
Dyrcona |
If that option is omitted, it will run pending event for that granularity or no granularity. Pending events with a different granularity are not run. |
| 13:22 |
Dyrcona |
If no granularity is specified, then only pending events with no granularity are run. |
| 13:26 |
Dyrcona |
--process-hooks also pays attention to the granularity. |
| 13:26 |
Dyrcona |
It won't run hooks for events whose granularity does not match the --granularity argument. |
| 13:27 |
Dyrcona |
It looks like all hooks will be processed if no granularity is specified. |
| 13:28 |
Dyrcona |
You can also pass a comma separated list of hooks to the undocumented --hooks option of action_trigger_runner.pl and it will only consider those hooks. |
| 13:28 |
Dyrcona |
I learned something today! ;) |
| 13:31 |
Dyrcona |
@ana granularity only |
| 13:31 |
pinesol |
Dyrcona: In your gallantry |
| 13:48 |
csharp |
Dyrcona++ |
| 13:51 |
Dyrcona |
I think it's more like I relearned something today.... |
| 13:53 |
csharp |
yeah, I was just saying to terran earlier that I think I've forgotten way more than I currently know |
| 13:53 |
csharp |
I look at reports I created a couple of years ago and can't figure out what I did |
| 13:54 |
Dyrcona |
:) |
| 14:17 |
|
yboston joined #evergreen |
| 14:39 |
|
khuckins joined #evergreen |
| 14:54 |
Dyrcona |
Well, that's not helpful... All haproxy tells me on Ubuntu 18.04 is fatal errors found in the config file. Doesn't even point to a line number. |
| 14:54 |
Dyrcona |
The config works on Ubuntu 16.04 with haproxy 1.6, but not with haproxy 1.8. |
| 14:57 |
Dyrcona |
Guess I'll have to do some more research. |
| 15:08 |
|
sandbergja joined #evergreen |
| 15:11 |
Dyrcona |
Well, the original configuration doesn't work, either.... |
| 15:16 |
|
khuckins joined #evergreen |
| 15:40 |
|
jvwoolf joined #evergreen |
| 16:12 |
|
jihpringle joined #evergreen |
| 17:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-06-27T16:58:17,850933386-0400 -0> |
| 17:04 |
csharp |
I look at reports I created a couple of years ago and can't figure out what I did |
| 17:04 |
csharp |
urg - arrow-up strikes again |
| 17:13 |
|
sandbergja joined #evergreen |
| 17:54 |
jeff |
deja vu all over again. |
| 20:41 |
|
sandbergja joined #evergreen |
| 21:08 |
|
book`_ joined #evergreen |
