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 all eventlog entries to be full JSON objects #2128

Merged
merged 9 commits into from Apr 19, 2019

Conversation

@chu11
Copy link
Contributor

commented Apr 16, 2019

Per RFC18 update, this changes all eventlog entries to be full JSON objects. This is the second part of #2106.

Note that there is no refactoring here, just the basics to get flux-core to be RFC18 compliant. Part 3 will include a new libeventlog library to refactor things.

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 16, 2019

hmmm, haven't seen a hang in awhile. Restarting builder.


No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

The build has been terminated
@chu11 chu11 force-pushed the chu11:issue2106_part2 branch from 3278934 to cbcd9d7 Apr 17, 2019
@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

rebased

@garlick

This comment has been minimized.

Copy link
Member

commented Apr 17, 2019

So the context and event name max lengths went away in the RFC 18 updates.

How would you feel about adding the next PR to this one? Since we create our release notes from the merge commits, it's nice if a PR completely handles one thing rather than being split over several PRs. Is there a good reason to split it here?

(Apologies if we already discussed this and you made a good point that I've now forgotten!)

@grondo suggests if we agree that practice is what we want, we could add it to RFC 1.

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

So the context and event name max lengths went away in the RFC 18 updates.

Yup.

How would you feel about adding the next PR to this one? Since we create our release notes from the merge commits, it's nice if a PR completely handles one thing rather than being split over several PRs. Is there a good reason to split it here?

I just felt it was two different changes. Converting to RFC18 felt like one change (i.e. nothing wrong with keeping the code the way it is and can keep the flux_kvs_eventlog API). To me the inclusion of the libeventlog is a refactoring / cleanup that is separate from this one.

I can go either way on this.

@garlick

This comment has been minimized.

Copy link
Member

commented Apr 17, 2019

Sorry I was a bit terse above. I meant the PR doesn't quite get the code in sync with RFC 18 because the old API enforces the old length limitations. The argument for combining the PR's is that it accomplishes the entire "sync with RFC 18 changes" task in one go (one release notes entry), and some intermediate changes can be avoided (e.g. in a combined PR: add new libeventlog api + tests, convert users, drop old kvs/eventlog api + tests, thus avoiding updates the the old api and tests).

If thinking in the granularity of release notes, this seems like one part of a whole change, not an independent change.

Having said that, you've got this PR all prepared and the button is green. If you prefer, I'll hit the button and we can split hairs on the next topic :-)

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

Sorry I was a bit terse above. I meant the PR doesn't quite get the code in sync with RFC 18 because the old API enforces the old length limitations.

Ahhh. I get it now. I'll go ahead and push the bigger overall change.

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

re-pushed with the new libeventlog library and the removal of the old kvs_eventlog.

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

Lots of builders failed. All tests pass but I clearly screwed up something in the Makefile.am that travis is expecting with my new unit tests. Hmmm.

make  test_eventlog.t

  CC       test/test_eventlog_t-eventlog.o

  CCLD     test_eventlog.t

make  check-TESTS

           test_eventlog.t:  PASS: N=54  PASS=54  FAIL=0 SKIP=0 XPASS=0 XFAIL=0

ERROR: test_eventlog.t - missing test plan

tap-driver.sh: internal error getting exit status

tap-driver.sh: fatal: I/O or internal error

Makefile:1028: recipe for target 'test_eventlog.log' failed
@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

hmmm, Possible b/c the logs have bad output? I'll re-work and try again.

ok 70 - eventlog_entry_decode - decoded "{"timestamp":1.0,"name":"foo"}
" correctly
@chu11 chu11 force-pushed the chu11:issue2106_part2 branch from aa11402 to c609082 Apr 18, 2019
@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

oh wait

           test_eventlog.t:  PASS: N=54  PASS=54  FAIL=0 SKIP=0 XPASS=0 XFAIL=0

I have > 54 unit tests. Hmmmm, but little info to go off of.

@grondo

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

Yeah, that's weird. The fact that the test got a PASS implies that the test script issued the TAP protocol 1..54. Did you prematurely call test_done?

What does the test-suite.log output show?

(Of course, there is also a chance there's a problem with our custom tap-driver script...)

@grondo

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

This branch fails for me with just plain make check, the test_eventlog.t is segfaulting after test 89:

ok 84 - eventlog_entry_create context="foo" fails with EINVAL
ok 85 - eventlog_entry_create context="["foo"]" fails with EINVAL
ok 86 - eventlog_entry_create context="{"data":"foo"}\n" fails with EINVAL
ok 87 - eventlog_entry_pack name=NULL fails with EINVAL
ok 88 - eventlog_entry_pack context="" fails with EINVAL
ok 89 - eventlog_entry_pack context="foo" fails with EINVAL
Segmentation fault (core dumped)

under gdb

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bce290 in ?? () from /usr/lib/x86_64-linux-gnu/libjansson.so.4
(gdb) where
#0  0x00007ffff7bce290 in ?? () from /usr/lib/x86_64-linux-gnu/libjansson.so.4
#1  0x00007ffff7bce785 in json_vpack_ex ()
   from /usr/lib/x86_64-linux-gnu/libjansson.so.4
#2  0x000055555555baeb in eventlog_entry_vpack (timestamp=1, 
    name=0x55555555c9c4 "foo", context_fmt=0x55555555ca26 "[\"foo\"]", 
    ap=ap@entry=0x7fffffffe2b0) at eventlog.c:276
#3  0x000055555555bc3f in eventlog_entry_pack (timestamp=<optimized out>, 
    name=<optimized out>, context_fmt=<optimized out>) at eventlog.c:298
#4  0x0000555555557338 in eventlog_entry_encoding_errors ()
    at test/eventlog.c:403
#5  0x0000555555555c55 in main (argc=<optimized out>, argv=<optimized out>)
    at test/eventlog.c:460

in case it is not reproducing for you

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

Yeah, that's weird. The fact that the test got a PASS implies that the test script issued the TAP protocol 1..54. Did you prematurely call test_done?

Don't think so. The main routine is pretty normal:

    plan (NO_PLAN);

    eventlog_entry_parsing ();
    eventlog_decoding ();
    eventlog_decoding_errors ();
    eventlog_entry_decoding ();
    eventlog_entry_decoding_errors ();
    eventlog_entry_encoding ();
    eventlog_entry_encoding_errors ();

    done_testing ();

What does the test-suite.log output show?

Now that you mention it, there is an odd thing in test-suite.log. There are no errors for test_eventlog.t, but there are errors for test_toml.t.

PASS: test_toml
===============
ok 1 - ex1: parsed simple example
PASS: test_toml.t 1 - ex1: parsed simple example
ok 2 - ex1: located server table
PASS: test_toml.t 2 - ex1: located server table
<SNIP>
not ok 111 - utf8_to_ucs: 0x80 converted from 2-char UTF8 # TODO https://github.com/cktan/tomlc99/issues/7
XFAIL: test_toml.t 111 - utf8_to_ucs: 0x80 converted from 2-char UTF8 # TODO https://github.com/cktan/tomlc99/issues/7
#   Failed (TODO) test 'utf8_to_ucs: 0x80 converted from 2-char UTF8'
#   at test/toml.c line 401.
not ok 112 - utf8_to_ucs: 0x7ff converted from 2-char UTF8 # TODO https://github.com/cktan/tomlc99/issues/7
XFAIL: test_toml.t 112 - utf8_to_ucs: 0x7ff converted from 2-char UTF8 # TODO https://github.com/cktan/tomlc99/issues/7
#   Failed (TODO) test 'utf8_to_ucs: 0x7ff converted from 2-char UTF8'
#   at test/toml.c line 403.
<SNIP - more errors>

Note that it indicates PASS for these tests, but there are clearly errors.

EDIT: i now clearly see these are XFAILS.

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

This branch fails for me with just plain make check, the test_eventlog.t is segfaulting after test 89:

Thanks. I'd been concentrating on mem corruption around test 55, but perhaps it's way earlier given you're seeing it at 90.

@grondo

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

Here's valgrind output from my system in case it helps:

==32145== Invalid read of size 8
==32145==    at 0x4E43290: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==32145==    by 0x4E43784: json_vpack_ex (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==32145==    by 0x10FAEA: eventlog_entry_vpack (eventlog.c:276)
==32145==    by 0x10FC3E: eventlog_entry_pack (eventlog.c:298)
==32145==    by 0x10B337: eventlog_entry_encoding_errors (eventlog.c:403)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145==  Address 0x544e748 is 8 bytes inside a block of size 53 free'd
==32145==    at 0x4C30D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32145==    by 0x10B8C6: vok_at_loc (tap.c:85)
==32145==    by 0x10BAE6: ok_at_loc (tap.c:93)
==32145==    by 0x10B311: eventlog_entry_encoding_errors (eventlog.c:398)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145==  Block was alloc'd at
==32145==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32145==    by 0x10B779: vstrdupf (tap.c:29)
==32145==    by 0x10B824: vok_at_loc (tap.c:61)
==32145==    by 0x10BAE6: ok_at_loc (tap.c:93)
==32145==    by 0x10B311: eventlog_entry_encoding_errors (eventlog.c:398)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145== 
==32145== Invalid read of size 8
==32145==    at 0x4E432A5: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==32145==    by 0x4E43784: json_vpack_ex (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==32145==    by 0x10FAEA: eventlog_entry_vpack (eventlog.c:276)
==32145==    by 0x10FC3E: eventlog_entry_pack (eventlog.c:298)
==32145==    by 0x10B337: eventlog_entry_encoding_errors (eventlog.c:403)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145==  Address 0x544e748 is 8 bytes inside a block of size 53 free'd
==32145==    at 0x4C30D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32145==    by 0x10B8C6: vok_at_loc (tap.c:85)
==32145==    by 0x10BAE6: ok_at_loc (tap.c:93)
==32145==    by 0x10B311: eventlog_entry_encoding_errors (eventlog.c:398)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145==  Block was alloc'd at
==32145==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32145==    by 0x10B779: vstrdupf (tap.c:29)
==32145==    by 0x10B824: vok_at_loc (tap.c:61)
==32145==    by 0x10BAE6: ok_at_loc (tap.c:93)
==32145==    by 0x10B311: eventlog_entry_encoding_errors (eventlog.c:398)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145== 
ok 90 - eventlog_entry_pack context="["foo"]" fails with EINVAL
ok 91 - eventlog_entry_pack context="{"data":"foo"}" fails with EINVAL
ok 92 - eventlog_entry_pack context="{"data":"foo"}\n" fails with EINVAL
ok 93 - eventlog_entry_vpack name=NULL fails with EINVAL
ok 94 - eventlog_entry_vpack context="" fails with EINVAL
ok 95 - eventlog_entry_vpack context="foo" fails with EINVAL
==32145== Invalid read of size 8
==32145==    at 0x4E43290: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==32145==    by 0x4E43784: json_vpack_ex (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==32145==    by 0x10FAEA: eventlog_entry_vpack (eventlog.c:276)
==32145==    by 0x10ABAE: test_eventlog_entry_vpack (eventlog.c:288)
==32145==    by 0x10B507: eventlog_entry_encoding_errors (eventlog.c:434)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145==  Address 0x544ed58 is 8 bytes inside a block of size 54 free'd
==32145==    at 0x4C30D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32145==    by 0x10B8C6: vok_at_loc (tap.c:85)
==32145==    by 0x10BAE6: ok_at_loc (tap.c:93)
==32145==    by 0x10B4E1: eventlog_entry_encoding_errors (eventlog.c:429)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145==  Block was alloc'd at
==32145==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32145==    by 0x10B779: vstrdupf (tap.c:29)
==32145==    by 0x10B824: vok_at_loc (tap.c:61)
==32145==    by 0x10BAE6: ok_at_loc (tap.c:93)
==32145==    by 0x10B4E1: eventlog_entry_encoding_errors (eventlog.c:429)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145== 
==32145== Invalid read of size 8
==32145==    at 0x4E432A5: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==32145==    by 0x4E43784: json_vpack_ex (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==32145==    by 0x10FAEA: eventlog_entry_vpack (eventlog.c:276)
==32145==    by 0x10ABAE: test_eventlog_entry_vpack (eventlog.c:288)
==32145==    by 0x10B507: eventlog_entry_encoding_errors (eventlog.c:434)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145==  Address 0x544ed58 is 8 bytes inside a block of size 54 free'd
==32145==    at 0x4C30D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32145==    by 0x10B8C6: vok_at_loc (tap.c:85)
==32145==    by 0x10BAE6: ok_at_loc (tap.c:93)
==32145==    by 0x10B4E1: eventlog_entry_encoding_errors (eventlog.c:429)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145==  Block was alloc'd at
==32145==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32145==    by 0x10B779: vstrdupf (tap.c:29)
==32145==    by 0x10B824: vok_at_loc (tap.c:61)
==32145==    by 0x10BAE6: ok_at_loc (tap.c:93)
==32145==    by 0x10B4E1: eventlog_entry_encoding_errors (eventlog.c:429)
==32145==    by 0x109C54: main (eventlog.c:460)
==32145== 
ok 96 - eventlog_entry_vpack context="["foo"]" fails with EINVAL
ok 97 - eventlog_entry_vpack context="{"data":"foo"}" fails with EINVAL
ok 98 - eventlog_entry_vpack context="{"data":"foo"}\n" fails with EINVAL
1..98
==32145== 
==32145== HEAP SUMMARY:
==32145==     in use at exit: 0 bytes in 0 blocks
==32145==   total heap usage: 689 allocs, 689 frees, 152,099 bytes allocated
==32145== 
==32145== All heap blocks were freed -- no leaks are possible
==32145== 
==32145== For counts of detected and suppressed errors, rerun with: -v
==32145== ERROR SUMMARY: 8 errors from 4 contexts (suppressed: 0 from 0)
grondo@asp:~/git/flux-core.git/src/common/libeventlog$ 
@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

Hmmm. What version of jansson is on your machine @grondo? I'm wondering if my tests like:

    errno = 0;
    ok (eventlog_entry_pack (1., "foo", "[\"foo\"]") == NULL
        && errno == EINVAL,
        "eventlog_entry_pack context=\"[\"foo\"]\" fails with EINVAL");

are creating problems b/c the o in foo is being mistaken for a format specifier. The test was supposed to be a simple "pass in an json array" test leading to EINVAL.

@grondo

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

What version of jansson is on your machine @grondo?

Ubuntu 18.04:

libjansson-dev:amd64	2.11-1

This matches what we've got in the bionic docker env:

$ docker run fluxrm/testenv:bionic dpkg-query -W libjansson-dev     
libjansson-dev:amd64    2.11-1

while CentOS 7 has 2.10. Maybe that is why the centos builds seem to succeed?

$ docker run fluxrm/testenv:centos7 rpm -q jansson-devel                                                                        
jansson-devel-2.10-1.el7.x86_64
@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

while CentOS 7 has 2.10. Maybe that is why the centos builds seem to succeed?

Yeah. It appears my guess that the o in foo was being confused as a format specifier was the issue. Thanks for the help!

One builder hit a valgrind issue, but no info beyond just this. Hmmm.

==1668== 
==1668== HEAP SUMMARY:
==1668==     in use at exit: 23,615 bytes in 57 blocks
==1668==   total heap usage: 28,349 allocs, 28,292 frees, 19,706,125 bytes allocated
==1668== 
==1668== LEAK SUMMARY:
==1668==    definitely lost: 0 bytes in 0 blocks
==1668==    indirectly lost: 0 bytes in 0 blocks
==1668==      possibly lost: 0 bytes in 0 blocks
==1668==    still reachable: 23,615 bytes in 57 blocks
==1668==         suppressed: 0 bytes in 0 blocks
==1668== Reachable blocks (those to which a pointer was found) are not shown.
==1668== To see them, rerun with: --leak-check=full --show-leak-kinds=all
@chu11 chu11 force-pushed the chu11:issue2106_part2 branch from df454cf to 7ad6808 Apr 18, 2019
@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

re-pushed, for whatever reason, jansson 2.10 was able to correctly tell that a format like [\"foo\"] was invalid and return EINVAL. But in jansson 2.11, I believe the f and o are interpreted as format specifiers and badness occurs.

Copy link
Member

left a comment

Nice work Al! Some minor comments inline.

I think you can squash out of existence the changes to libkvs/eventlog.[ch] and its test by reordering commits?

Note that newlines in the name or in strings embedded in context are no longer a problem since they will be escaped when serialized. (And the RFC no longer explicitly forbids them)

if (name)
(*name) = n;

if (!json_unpack (entry, "{ s:o }", "context", &c)) {

This comment has been minimized.

Copy link
@garlick

garlick Apr 18, 2019

Member

There probably needs to be a check that 'o' is a JSON object and not an array.

}

if (!(copy = strdup (s)))
goto enomem;

This comment has been minimized.

Copy link
@garlick

garlick Apr 18, 2019

Member

strdup sets ENOMEM so just return NULL?

return true;
}

static json_t *eventlog_entry_decode_wrapper (const char *entry,

This comment has been minimized.

Copy link
@garlick

garlick Apr 18, 2019

Member

Different name? It's not a wrapper for event_decode(), it's the other way around right?

if (timestamp < 0.
|| !name
|| !strlen (name)
|| strchr (name, ' ') != NULL

This comment has been minimized.

Copy link
@garlick

garlick Apr 18, 2019

Member

RFC 18 doesn't actually impose any restrictions on what is in the "name" string anymore, so prob OK to skip these checks for white space. (note embedded newlines are escaped in JSON strings and cannot be confused with the event end of line)

int save_errno;

if (context) {
if (strchr (context, '\n')) {

This comment has been minimized.

Copy link
@garlick

garlick Apr 18, 2019

Member

embedded newline check not needed.

int save_errno;

if (context_fmt) {
if (strchr (context_fmt, '\n')) {

This comment has been minimized.

Copy link
@garlick

garlick Apr 18, 2019

Member

check for embedded newline not needed

if (!(s = json_dumps (entry, JSON_COMPACT)))
goto enomem;
if (asprintf (&rv, "%s\n", s) < 0)
goto enomem;

This comment has been minimized.

Copy link
@garlick

garlick Apr 18, 2019

Member

asprintf sets errno so might want to not re-set it here.

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 19, 2019

I think you can squash out of existence the changes to libkvs/eventlog.[ch] and its test by reordering commits?

Ahhh yes, now that I've put the two PRs into one, that initial change makes less sense. I'll see how I can piece things together into a more sensible commit series.

@chu11 chu11 force-pushed the chu11:issue2106_part2 branch from 7ad6808 to fb4bd54 Apr 19, 2019
@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 19, 2019

just re-pushed with suggested fixes above and squashed changes into a smaller set of commits. Added new tests such as e = eventlog_entry_pack (1., "foo", "{ s:s }", "data", "foo\n"); to ensure newlines in contexts work as expected.

@garlick

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

LGTM! Just needs a rebase.

chu11 added 3 commits Apr 12, 2019
Library contains convenience functions for parsing eventlogs and
eventlog entries per RFC18 changes, where eventlog entries are complete
JSON objects.
Per changes in RFC18, events are now full JSON objects, so adjust
appropriately by utilizing new libeventlog functions.

As a side effect, json_t pointer representing an eventlog entry
is now passed around between many functions instead of a
const char * to an event.

Collapse event_job_post() and event_job_post_pack() into a single
function call.

Update unit tests accordingly.
Per changes in RFC18, events are now full JSON objects, so adjust
all event creation to be compliant.  When appropriate, utilize
new functions in libeventlog.

Rename several functions by adding pack/vpack suffix, so it is more
clear that they take jansson style pack arguments.
chu11 added 6 commits Apr 11, 2019
Per changes in RFC18, events are now full JSON objects, so adjust
appropriately by utilizing new libeventlog functions.
Per changes in RFC18, events are now full JSON objects, so adjust
appropriately by utilizing new libeventlog functions.

As consequence, util.[ch] are no longer needed.
With new libeventlog internal convenience library, there is no
need for the public flux_kvs_eventlog library.
Update tests per RFC18 changes, events are now full JSON
objects.
With RFC18 changes that make all events JSON objects, update by using
new libeventlog library.

Rename the --context-format option to --format.  When --format=json, output
the entire event as JSON.

Update tests.
Per changes in RFC18, events are now full JSON objects, so adjust
appropriately by utilizing new libeventlog functions.

Add additional test for invalid format context.
@chu11 chu11 force-pushed the chu11:issue2106_part2 branch from fb4bd54 to d5dd344 Apr 19, 2019
@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Apr 19, 2019

rebased

@codecov-io

This comment has been minimized.

Copy link

commented Apr 19, 2019

Codecov Report

Merging #2128 into master will decrease coverage by 0.03%.
The diff coverage is 84.07%.

@@            Coverage Diff             @@
##           master    #2128      +/-   ##
==========================================
- Coverage   80.42%   80.38%   -0.04%     
==========================================
  Files         201      200       -1     
  Lines       31742    31701      -41     
==========================================
- Hits        25529    25484      -45     
- Misses       6213     6217       +4
Impacted Files Coverage Δ
src/modules/job-info/lookup.c 67.85% <ø> (ø) ⬆️
src/modules/job-manager/submit.c 79.77% <100%> (+5.24%) ⬆️
src/modules/job-manager/start.c 73.45% <100%> (ø) ⬆️
src/modules/job-manager/alloc.c 76.23% <100%> (ø) ⬆️
src/modules/job-manager/job.c 93.75% <100%> (-0.19%) ⬇️
src/modules/job-info/watch.c 73.01% <100%> (+0.88%) ⬆️
src/modules/job-manager/event.c 74.77% <69.44%> (+0.46%) ⬆️
src/modules/job-info/allow.c 85.71% <81.25%> (-0.5%) ⬇️
src/modules/job-ingest/job-ingest.c 74.42% <81.81%> (-0.3%) ⬇️
src/modules/job-exec/job-exec.c 74.36% <82.14%> (+0.14%) ⬆️
... and 13 more
@garlick garlick merged commit 881f236 into flux-framework:master Apr 19, 2019
4 checks passed
4 checks passed
Mergify — Summary 1 potential rule
Details
codecov/patch 84.07% of diff hit (target 80.42%)
Details
codecov/project Absolute coverage decreased by -0.03% but relative coverage increased by +3.64% compared to a1ebb9c
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@garlick

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

Awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.