| Message ID | 20170905161323.24422-1-dja@axtens.net |
|---|---|
| State | Accepted |
| Headers | show |
| Series | travis: switch to using root user | expand |
On Wed, 2017-09-06 at 02:13 +1000, Daniel Axtens wrote: > When I pushed the last change, I noticed that Travis was beginning > to fail due to db permission errors. This is a trivial fixup. > > Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Stephen Finucane <stephen@that.guru> Probably worth backporting too. If we don't have Travis enabled on that branch we probably should fix that.
> When I pushed the last change, I noticed that Travis was beginning > to fail due to db permission errors. This is a trivial fixup. As this is: - a trivial fix - needed to get Travis to work - tested in my postgres work ... I have merged it to master at 10a132f134cef46aabb01ca88a32d06bdc8cf320 Because we'll do at least one 2.0.n point release, I figure it's worth having in stable, too. So I have merged it to stable/2.0 at 8940289eeec123b9f8330bb54d8a3ee8b98c83af Happy to revert or modify if this is problematic. Regards, Daniel > Signed-off-by: Daniel Axtens <dja@axtens.net> > --- > .travis.yml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/.travis.yml b/.travis.yml > index 25d150e3e3db..1f898f3733b5 100644 > --- a/.travis.yml > +++ b/.travis.yml > @@ -12,7 +12,7 @@ services: > > env: > global: > - - PW_TEST_DB_USER=travis > + - PW_TEST_DB_USER=root > - PW_TEST_DB_PASS="" > - PW_SKIP_BROWSER_TESTS=yes > > -- > 2.11.0
On Wed, 2017-09-06 at 02:35 +1000, Daniel Axtens wrote: > > When I pushed the last change, I noticed that Travis was beginning > > to fail due to db permission errors. This is a trivial fixup. > > As this is: > - a trivial fix > - needed to get Travis to work > - tested in my postgres work > ... I have merged it to master at 10a132f134cef46aabb01ca88a32d06bdc8cf320 > > Because we'll do at least one 2.0.n point release, I figure it's worth > having in stable, too. So I have merged it to stable/2.0 at > 8940289eeec123b9f8330bb54d8a3ee8b98c83af > > Happy to revert or modify if this is problematic. Nope, that makes sense. If Travis isn't testing stable/2.0 then I should probably fix that. Will investigate today. I'll review the PostgreSQL patches you sent this evening and see which of backportable. After that, I think v2.0.1 is probably in order. Stephen
Stephen Finucane <stephen@that.guru> writes: > On Wed, 2017-09-06 at 02:35 +1000, Daniel Axtens wrote: >> > When I pushed the last change, I noticed that Travis was beginning >> > to fail due to db permission errors. This is a trivial fixup. >> >> As this is: >> - a trivial fix >> - needed to get Travis to work >> - tested in my postgres work >> ... I have merged it to master at 10a132f134cef46aabb01ca88a32d06bdc8cf320 >> >> Because we'll do at least one 2.0.n point release, I figure it's worth >> having in stable, too. So I have merged it to stable/2.0 at >> 8940289eeec123b9f8330bb54d8a3ee8b98c83af >> >> Happy to revert or modify if this is problematic. > > Nope, that makes sense. If Travis isn't testing stable/2.0 then I should > probably fix that. Will investigate today. As you have probably discovered by now, it is testing that - indeed it automatically tests all branches: https://travis-ci.org/getpatchwork/patchwork/branches > I'll review the PostgreSQL patches you sent this evening and see which of > backportable. After that, I think v2.0.1 is probably in order. Agreed. We're going to need to make some tough choices on the v2 performance regression caused by the django bug too - do we want to monkeypatch that or push it to sysadmins? Regards, Daniel > > Stephen
On Wed, 2017-09-06 at 23:59 +1000, Daniel Axtens wrote: > Stephen Finucane <stephen@that.guru> writes: > > > On Wed, 2017-09-06 at 02:35 +1000, Daniel Axtens wrote: > > > > When I pushed the last change, I noticed that Travis was beginning > > > > to fail due to db permission errors. This is a trivial fixup. > > > > > > As this is: > > > - a trivial fix > > > - needed to get Travis to work > > > - tested in my postgres work > > > ... I have merged it to master at > > > 10a132f134cef46aabb01ca88a32d06bdc8cf320 > > > > > > Because we'll do at least one 2.0.n point release, I figure it's worth > > > having in stable, too. So I have merged it to stable/2.0 at > > > 8940289eeec123b9f8330bb54d8a3ee8b98c83af > > > > > > Happy to revert or modify if this is problematic. > > > > Nope, that makes sense. If Travis isn't testing stable/2.0 then I should > > probably fix that. Will investigate today. > > As you have probably discovered by now, it is testing that - indeed it > automatically tests all branches: > https://travis-ci.org/getpatchwork/patchwork/branches Yup, no extra configuration necessary, which is great. > > I'll review the PostgreSQL patches you sent this evening and see which of > > backportable. After that, I think v2.0.1 is probably in order. > > Agreed. We're going to need to make some tough choices on the v2 > performance regression caused by the django bug too - do we want to > monkeypatch that or push it to sysadmins? I haven't looked into this fully yet, but my gut feeling (not always to be trusted) is that this is a sysadmin/packaging problem. ozlabs could carry the patch locally, but we should probably be looking for Debian/Django to backport the change. I do still need to look into it in depth, however. Stephen
diff --git a/.travis.yml b/.travis.yml index 25d150e3e3db..1f898f3733b5 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,7 +12,7 @@ services: env: global: - - PW_TEST_DB_USER=travis + - PW_TEST_DB_USER=root - PW_TEST_DB_PASS="" - PW_SKIP_BROWSER_TESTS=yes
When I pushed the last change, I noticed that Travis was beginning to fail due to db permission errors. This is a trivial fixup. Signed-off-by: Daniel Axtens <dja@axtens.net> --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)