Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fT1Ze-000408-Q7 for pgadmin-hackers@arkaria.postgresql.org; Wed, 13 Jun 2018 08:56:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fT1Zc-0004qV-Oh for pgadmin-hackers@arkaria.postgresql.org; Wed, 13 Jun 2018 08:56:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fT1Zc-0004qL-JQ for pgadmin-hackers@lists.postgresql.org; Wed, 13 Jun 2018 08:56:12 +0000 Received: from mail-wr0-x22c.google.com ([2a00:1450:400c:c0c::22c]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fT1ZT-0000ae-J8 for pgadmin-hackers@postgresql.org; Wed, 13 Jun 2018 08:56:11 +0000 Received: by mail-wr0-x22c.google.com with SMTP id d8-v6so1856158wro.4 for ; Wed, 13 Jun 2018 01:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sJYgF575XYxgwUkDhofFWbQCGqYczacOMuqxZkiA7wM=; b=spSVnp/4GWGe+QMtoCB+CW1JxaciH8smy0pfxj0wNSu/cW/t8u2BGaZz+C2AymjmUX ptK02REaDZ82VuAMG7SJB7wh9QE9OlAXWMDShTDVvWXHfycey63XUSuZt77lq7eJfqrk yOXGa9rINAouvNm+lGhRDsgyVewbgQW0oD3SUBSSsoypKoDJk6VNHIKciPz7lMexyWvP 5dpzpvgwObLw1vaJEetpYgz3DcDSji5S3MJ2+uYJAFb+3whN4YTVxdVy1ZvO5NfLYjmd 6kaFuMuHED8B02pojkrpuPy4d+zuxaBkA98zBk8khqOFofFnFwEvdCPXg4yYod3FLo9t 6Fpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sJYgF575XYxgwUkDhofFWbQCGqYczacOMuqxZkiA7wM=; b=O54pIX0Y3ULr43OmxEp1r1xG7TN2XNYgQ3Gg6h/Ar64MgbV4DiqnPlTM+hbHRfpTm6 A5j/UWXREcluV5HXdoz1pAtTFWf5Um9TLbIw1xuIYHEk6VTs2ChUmifMdUuwwAtMFDJK NGyKWoJ/1/n9EBDuKYGzeiqHkFWgLgcFYQyJaenRvC259DqrTj3L/4EgMTGESOXsz+F2 pbmF8AttorMEV4KBNx47mmIjnVrZFHPRBqDZBbVGdxLv4qGOLQiKB2nY6t/WdDo0kuja Oo6ppVzbW+vlT421U+r+FybM0NBGtncQpnyU2RlSdDZ/js8aZOAh7BBdEYS+1oh4Po0e YtfA== X-Gm-Message-State: APt69E1lf01b66+Y4DZPxDQHVAR09LM0lFcXPvU+ANINUq/W0M0bXn8g qyv7oA+voMmy+rK5s5cGeqChMyfrMBPvBW7cJTyqJw== X-Google-Smtp-Source: ADUXVKJ4ORKLbNVo+QSPEYzq7qaAd0jR1BB//3Z4S165XOllCXQ7ViRvATIwiO7nqep3APVq1HLjiqWttG6Ekyv2s0s= X-Received: by 2002:adf:9950:: with SMTP id x74-v6mr3260430wrb.135.1528880160931; Wed, 13 Jun 2018 01:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:2907:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 01:56:00 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Wed, 13 Jun 2018 09:56:00 +0100 Message-ID: Subject: Re: [pgadmin4][patch] Use pytest test runner for unit tests To: Victoria Henry Cc: Joao De Almeida Pereira , pgadmin-hackers , Anthony Emengo Content-Type: multipart/alternative; boundary="000000000000e59548056e8226b5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000e59548056e8226b5 Content-Type: text/plain; charset="UTF-8" Hi On Tue, Jun 12, 2018 at 8:39 PM, Victoria Henry wrote: > Hi Dave, > > >> >> No, because it's firewalled to the nines inside our network. There's no >> chance I'm making production build machines internet-accessible. >> > > For a Open Source project, if the community cannot see the place where the > tests are running it looses a huge part of the process. We believe that > removing this capability will have a negative impact on the development, > especially because we do not have a CI/CD. Before the code is merged we > will never know if master is broken or not. > This is one of multiple CI/CD systems; specifically it's the one that will be producing our official builds. Security always trumps developer convenience for build machines as far as I'm concerned - have you ever had to deal with a possibly-compromised build server and the PR fallout etc that can result from that? The existing public system will be replaced with one that mirrors a portion of the build system; specifically, the test jobs, but not the production build jobs or dependencies. It may be removed completely in the future if I can find a way to securely allow access to build info from the build system. > > >> >> >>> We have some examples from our pipeline that we can share: >>> Script that we use to run the UT + Feature tests on a docker image that >>> has python+yarn+selenium+postgres installed on it: >>> https://github.com/greenplum-db/pgadmin4-ci/blob/master/ >>> tasks/run-postgres-tests/run.sh >>> >>> This type of scripts can be added to the Jenkinsfile to create a >>> pipeline step. A good practice in a reproducible pipeline is to use Docker >>> to ensure that every test runs in a clean and predictable environment, this >>> make it easy to reproduce a problem found in testing. >>> >> >> Docker is of little use to us here, as 2 of the 4 build platforms cannot >> be run in Docker (macOS and the Docker container), and the 3rd would be >> extremely difficult to run that way (Windows) >> > > The docker files that we are talking about here is to run the tests, and > we believe that the tests are all running in a Linux environment. > No, I'm running tests on all platforms. We've proven numerous times that just running them on Linux is not enough. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --000000000000e59548056e8226b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Tue, Jun 12, 2018 at 8:39 PM, Victoria Henry <= ;vhenry@pivotal.io> wrote:
Hi Dave,
=C2=A0

No, because it's firew= alled to the nines inside our network. There's no chance I'm making= production build machines internet-accessible.

For a Open Source project, if the commu= nity cannot see the place where the tests are running it looses a huge part= of the process. We believe that removing this capability will have a negat= ive impact on the development, especially because we do not have a CI/CD.= =C2=A0 Before the code is merged we will never know if master is broken or = not.

This is one of multi= ple CI/CD systems; specifically it's the one that will be producing our= official builds. Security always trumps developer convenience for build ma= chines as far as I'm concerned - have you ever had to deal with a possi= bly-compromised build server and the PR fallout etc that can result from th= at?

The existing public system will be replaced wi= th one that mirrors a portion of the build system; specifically, the test j= obs, but not the production build jobs or dependencies. It may be removed c= ompletely in the future if I can find a way to securely allow access to bui= ld info from the build system.
=C2=A0
= =C2=A0


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

Ent= erpriseDB UK: htt= p://www.enterprisedb.com
The Enterprise PostgreSQL Company
--000000000000e59548056e8226b5--