[02:22] wgrant: using zope interfaces, is it possible to express that a concerete class should implement one _or_ another method but not both? [02:30] blr_: No. [02:30] blr_: What are you trying to do? [02:32] wgrant: oh, not trying to do that, was discussing zope interfaces with someone and that came up. [07:54] wgrant: have added a new doctest for product +setbranch, however I'm matching elements against browser.contents [07:54] assuming it would be better to have a helper? [07:54] blr: There are a few helpers around already. None did what you need? [07:55] well, I want it to match a specific element for vcs [07:56] e.g. I currently have ">>> '

' in browser.contents" [07:56] blr: A number of tests use BeautifulSoup for that. [07:57] I'll dig around and look at more of the doctests. [08:21] hmm, lots of gpg-coc stories blowing up, would be surprised if they're regressions [08:32] wgrant: does bin/retest work reliably for you? it seems to hang with no output. [08:33] blr: You need to give it the list of failures from bin/test in one of two ways: a file specified at the commandline, or the raw text given to stdin. [08:34] If you don't specify a filename it will await input. [08:36] hah ok, not as magical as I had hoped :) [08:37] If you want properly magical, consider testrepository. [09:17] blr: Does it have to be a doctest, notwithstanding the existing stuff that does that? You can often do this pretty well in unit tests. [10:58] wgrant: webhooks proxy> good idea. I'd be inclined to just use squid as then we don't have to write a new charm at all. [10:59] I'm sure we can control requests' proxy settings accurately enough. [11:00] Yep, as long as we're careful that should be fine. [11:00] I'll get an RT in for an initial sanity check and a stagingstack tenant. [11:00] Need to check the PS4 egress firewalls thoroughly, but it should be fine. [11:01] block 10.0.0.0/8 and all our IP ranges except archive and blah blah blah [11:01] Yeah [11:01] (except when people want to webhook internal hosts. but then we can open those up.) [11:02] I'll raise it on the IS call in 9 hours. [11:02] Thanks. [11:37] wgrant: https://rt.admin.canonical.com/Ticket/Display.html?id=81258 [11:41] (I forgot to specifically mention the needed access from ackee, but we can sort that out as we go.) [11:55] cjwatson: The instances probably want floating IPs if only so they have sane reverse DNS, but otherwise that looks good. Thanks. [12:50] wgrant: Indeed, just didn't mention that because that can't be done until we have a spec deployed. [15:39] bigjools: William made the change you asked for to default new private archives to 20GiB rather than 2GiB; that's live now. [20:32] cjwatson: I added doctests to mirror the existing ones for series setbranch. Do we want to consider them generally deprecated at his point? [20:32] blr: Yes, doctests are quite deprecated. [20:32] I'm not that fond of them tbh [20:32] It's okay to add to them when that's substantially lower friction than adding a unit test, but it is discouraged. [20:33] I'll get the unit tests in place this morning, and perhaps you can judge if we should just drop the new doctests entirely when you review the branch [20:35] wgrant: oh, regarding push instructions, was thinking the nicest thing to do perhaps is display them based on the toggle state of default vcs on project setbranch [20:42] wgrant, cjwatson: one other wee thing, in the case where we infer vcs default from BranchCollection, git will be set as the default in the case where there are both bzr and git branches - is that acceptable? I figured that was the right approach given we want to generally consider bzr deprecated. [20:43] That sounds reasonable to me. [20:43] blr: Which push instructions? [20:44] Agreed, also we can mostly assume that people will be migrating from bzr to git rather than the other way round. [20:44] push intructions at the top of +setbranch [20:44] currently only for bzr [20:45] Similar for Product:+branches and probably various other places [20:46] Product:+branches isn't really affected; it'll show whatever the current view is. [20:46] True, +setbranch has a more awkward choice to make [20:46] I just thought that might be nice, to toggle between git and bzr intructions on the right hand side based on the vcs default selected [20:48] possibly it isn't even useful there, the code index view is really where you expect to see it. [20:56] +setbranch should have it, as that's probably the place you go when you create a new project. [21:38] cjwatson: wgrant: thanks a million, that's awesome [21:40] bigjools: np [23:23] wgrant: added a view test for default vcs to TestProductView - is there an equivalent set of tests for setbranch somewhere, or only doctests? [23:25] blr: I can't see any non-doctests. [23:25] ok, thanks for confirming, that's what I thought. [23:54] wgrant: `bin/test -cvvt xx-` should be catching all doctests yes? [23:56] blr: That should catch most of the browser doctests. [23:57] But that's not usually an interesting pattern. [23:57] -t registry.*product or something might be more interesting. [23:57] Or -t code.*product [23:58] wgrant: I found some regressions in translations, which I probably would not have noticed. I should probably just run the entire suite. [23:58] blr: That's buildbot's job. [23:58] Running the entire test suite takes more than three hours on my overclocked Haswell desktop. [23:58] But you could grep for tests that reference setbranch, for example. [23:59] okay, thanks