[tahoe-lafs-trac-stream] [Tahoe-LAFS] #4098: CircleCI is Broken

[Tahoe-LAFS]

#4098: CircleCI is Broken
-------------------------+-----------------------
     Reporter:  meejah   |      Owner:
         Type:  task     |     Status:  new
     Priority:  normal   |  Milestone:  undecided
    Component:  unknown  |    Version:  n/a
   Resolution:           |   Keywords:
Launchpad Bug:           |
-------------------------+-----------------------

Comment (by btlogy):

 I've recently spent some time on this issue because it has hit us at
 PrivateStorage in other related repositories.

 E.g.: https://github.com/PrivateStorageio/ZKAPAuthorizer/issues/462

 The problem describe in this Track ticket seems very similar and seems to
 be still present in the last merge commit (15 checks failed : all
 CircleCI):

 https://github.com/tahoe-lafs/tahoe-
 lafs/commit/6cf67471f1ccb00bf72cd6574fdd1deb9259df9e

 While the most of those checks have all passed for the related PR:

 https://github.com/tahoe-lafs/tahoe-lafs/pull/1383

 Our findings in short:

 * CircleCI does not checkout the same way the code from a fork repo and a
 local branch!
 * If the org. on CircleCI has been created using GitHub OAuth, one need to
 be GitHub/Tahoe-LAFS admin/owner to be a CircleCI/Tahoe-LAFS admin for the
 project/org.
 * There is an alternative way to create an org. on CircleCI using mostly
 email and password, but it involved a lot of manual steps and does not
 cover (easily) all the usual workflows (e.g.: PR from fork)
 * CircleCI should checkout the code of a project using HTTPS, unless there
 is a private SSH key available in the CircleCI settings.
 * There is at least 3 different way CircleCI can have that key setup:
   1. a CircleCI/Tahoe-LAFS admin user manually add an authorized private
 key (preferably a deploy key unique to the project/repo)
   2. a CircleCI/Tahoe-LAFS admin gives (way too many) permissions to
 CircleCI/OAuth to automatically create and authorize a new key.
 * However, we've found a few projects where there is currently no SSH key,
 maybe automatically removed by someone leaving the project (unlikely
 IMHO), and regardless, CircleCI tries and fails to checkout via SSH (`Load
 key "/tmp/nobody/.ssh/id_rsa": error in libcrypto`).
 * As we are suspecting for other project, adding a new SSH key and
 removing it directly after seems to cleanup the dirt in the pipe and
 forces CircleCI to using HTTPS to checkout (WiP).
 * Alternatively, it is "only" possible to avoid SSH and force HTTPS by
 implementing a custom checkout step as done once here in ZKAPAuthorizer:
 https://github.com/PrivateStorageio/ZKAPAuthorizer/blob/999c7c05f6131dfedcef360234fc4556e76ba755/.circleci/config.yml#L27-L45)

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4098#comment:17>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage