{"action":"created","issue":{"url":"https://api.github.com/repos/snowleopard/hadrian/issues/628","repository_url":"https://api.github.com/repos/snowleopard/hadrian","labels_url":"https://api.github.com/repos/snowleopard/hadrian/issues/628/labels{/name}","comments_url":"https://api.github.com/repos/snowleopard/hadrian/issues/628/comments","events_url":"https://api.github.com/repos/snowleopard/hadrian/issues/628/events","html_url":"https://github.com/snowleopard/hadrian/pull/628","id":333078983,"node_id":"MDExOlB1bGxSZXF1ZXN0MTk1Mzg2OTk2","number":628,"title":"Remove validation errors","user":{"login":"chitrak7","id":21269382,"node_id":"MDQ6VXNlcjIxMjY5Mzgy","avatar_url":"https://avatars3.githubusercontent.com/u/21269382?v=4","gravatar_id":"","url":"https://api.github.com/users/chitrak7","html_url":"https://github.com/chitrak7","followers_url":"https://api.github.com/users/chitrak7/followers","following_url":"https://api.github.com/users/chitrak7/following{/other_user}","gists_url":"https://api.github.com/users/chitrak7/gists{/gist_id}","starred_url":"https://api.github.com/users/chitrak7/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chitrak7/subscriptions","organizations_url":"https://api.github.com/users/chitrak7/orgs","repos_url":"https://api.github.com/users/chitrak7/repos","events_url":"https://api.github.com/users/chitrak7/events{/privacy}","received_events_url":"https://api.github.com/users/chitrak7/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":14,"created_at":"2018-06-17T17:32:14Z","updated_at":"2018-06-19T14:09:04Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/snowleopard/hadrian/pulls/628","html_url":"https://github.com/snowleopard/hadrian/pull/628","diff_url":"https://github.com/snowleopard/hadrian/pull/628.diff","patch_url":"https://github.com/snowleopard/hadrian/pull/628.patch"},"body":"I have copied some files as required by testsuite.\r\n\r\nAlso, I have unsuccessfully attempted to resolve #626.\r\n\r\n@sighingnow @snowleopard @alpmestan "},"comment":{"url":"https://api.github.com/repos/snowleopard/hadrian/issues/comments/398412218","html_url":"https://github.com/snowleopard/hadrian/pull/628#issuecomment-398412218","issue_url":"https://api.github.com/repos/snowleopard/hadrian/issues/628","id":398412218,"node_id":"MDEyOklzc3VlQ29tbWVudDM5ODQxMjIxOA==","user":{"login":"alpmestan","id":119323,"node_id":"MDQ6VXNlcjExOTMyMw==","avatar_url":"https://avatars3.githubusercontent.com/u/119323?v=4","gravatar_id":"","url":"https://api.github.com/users/alpmestan","html_url":"https://github.com/alpmestan","followers_url":"https://api.github.com/users/alpmestan/followers","following_url":"https://api.github.com/users/alpmestan/following{/other_user}","gists_url":"https://api.github.com/users/alpmestan/gists{/gist_id}","starred_url":"https://api.github.com/users/alpmestan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alpmestan/subscriptions","organizations_url":"https://api.github.com/users/alpmestan/orgs","repos_url":"https://api.github.com/users/alpmestan/repos","events_url":"https://api.github.com/users/alpmestan/events{/privacy}","received_events_url":"https://api.github.com/users/alpmestan/received_events","type":"User","site_admin":false},"created_at":"2018-06-19T14:09:04Z","updated_at":"2018-06-19T14:09:04Z","author_association":"COLLABORATOR","body":"> An alternative is then, which you seem to suggest, is to require the user to run the testsuite with exactly the same flavour as during the build.\r\n>\r\n> For example, `build --flavour=user` must be followed by `build test --flavour=user`. This might work too.\r\n\r\nRight. Or really you'd just do `build test --flavour=something` (where something is an existing or user defined flavour). This is a quite common need. Say you investigate some ticket, write a patch and want to see if that fixes the failure of test `foo`. You can then just go ahead and do `build test --flavour=suitable_flavour --build-root=_test-foo --only=foo` and have a cup of tea/coffee, where `suitable_flavour` should be whatever is appropriate: quickest if the test doesn't need any fancy _way_, devel2/perf/prof/etc depending on what's needed.\r\n\r\nOne reason why I think this works rather nicely is that this is the most flexible approach. I see two alternatives. The first one, at the opposite end of the spectrum, is to just require all the ways of everything to be built before we can run any test. This is annoying as it will _significantly_ increase the duration of the build. The other one, sitting in the middle, is only conceptual but is the best one. It'd consist in building just what we need for just those tests the user is asking to run (as determined by command line options etc). However the testsuite doesn't really give us a way to discover this ahead of time, as far as I know. I mean, we could scan the .T files and try to inspect the source code to figure some things out but... I don't think we want to do this :-)\r\n\r\nNow... in this scheme that I'm suggesting, what if we call the `test` rule again on the same build root but with a different flavour than the one we called it on right before? I don't think this would rebuild things with the way our library/executable rules are implemented at the moment. It feels like we should rebuild everything so as to actually produce all the build artefacts variants that the _new_ flavour implies. A bit like how `cabal-install` does it. Thoughts?"}}
{"actor":{"display_login":"alpmestan"}}