[Proposal] Resolve Deployment of new CocoaPods on a Community-level

[freak4pc]

This is in continued discussion to #29 & #27.

The Problem

People who are the sole owners of a Cocoapod abandon their - still active - project, leaving the community without an ability to deploy new Pod versions of a library. This is a huge issue in RxGoogleMaps and has the potential to be an issue in other repos as well.

Proposed Solution

It might've seemed this discussion have "died", but I had a thought on how to resolve this for a while now, but just had to go through several steps to "get the needed resources".

After several thoughts back and forth about this, I believe I've found a relatively "perfect" solution to make sure deploys can always be done by the community and not "tied" to a single owner.

This solution is composed of two parts : Community-Controlled Deploys (mandatory), and Auto Deploys (optional, but extremely cool).

Community-Controlled Deploys

As some of you may know, we have a community domain for RxSwift, aptly named www.rxswift.org. It has been inactive for a while due to some issues but thanks to the very generous help of @bontoJR, it is now active again and I also have secondary access to it so I could work through some of the related details (and also http://slack.rxswift.org is now back, woohoo!)

The first part of the solution is extremely simple - Amend the Checklist for Transferring Ownership to include an extra step:

• Add [email protected] as an owner of your project's Cocoapod by using pod trunk add-owner [email protected].

The email address [email protected] is a simple email forwarder, currently forwarding only to myself, but it could forward to an arbitrary list of Highly-Active Community Leaders (such as @ashfurrow etc), and will let us address pushing a podspec up if an owner goes missing leaving us "hanging dry"

Auto Deploys

This is all great and solves the problem in the most basic of levels, but there is a second step we can go through to take this to the next level and make things really neat and smooth and that's Auto Deploys.

This description will be relevant to CircleCI, but should be applicable to Travis as well.

Whenever [email protected] is added as an owner, one of the forwarded-to owners will "register" a session for that repo (using pod trunk register [email protected] "RxSwift Community"), in order to generate a token (found in ~/.netrc) that can be used to deploy the Podspec later.

This token will be added as a Secured Environment Variable to your CI of choice with the key COCOAPODS_TRUNK_TOKEN. This will let the CI push a Podspec to trunk as RxSwift Community.

To neatly wrap up this entire thing, adding a "Tag-level" deployment script in CircleCI to make sure only when a new tag (release) is pushed, CircleCI will build and also push an updated podspec.

I've made a Fake Repo to test this and it works extremely well, as you can see in this build: https://circleci.com/gh/RxSwiftCommunity/FakeRepo/30 (see the "pod trunk push" phase at the bottom)

You can also experiment with my Fake Repo yourself, if you'd like. You can modify the podspec, push it to master and then creating a new "Release" will trigger a build on CircleCI and push up a podspec. Super smooth and makes sure all deploys of Podspecs are done automatically and are always coming from "RxSwift Community".

I'd really appreciate your opinions on this (@ashfurrow @bobgodwinx @fpillet @RxSwiftCommunity/contributors) on if you think this is a viable solution, as I think it would easily resolve all of the issues we've been having around this.

Thanks for reading !

[esttorhe]

👏 This sounds like a good solution.

The simplest easiest of modifying the template when transferring ownership will definitely help.
Having the automated deploys would be the icing on the cake!!

Great work @freak4pc !

[freak4pc]

Dang you're a quick reader @esttorhe , thanks !

[ashfurrow]

Hey! Yes I agree, using a common email is a good idea, feel free to add me to the email forwarder. Let's make sure if we move forward with this solution (I think/hope we should) that we document everything appropriately. We'll also have to follow-up with all our existing repos.

Okay so automating deploys is trickier... I have a small security concern. For the repos that I switched to CircleCI a few months ago, I had to explicitly enable two settings:

• Build CI for pull requests made from forks.
• Pass the encrypted environment variables to builds for pull requests.

If we move to auto-deploys, which I agree are Very Cool, we would have to disable the second option and stop passing environment variables to PRs from forks, because someone could easily write a PR to extract the value from the CI build and then they'd be able to maliciously push new versions of all our libraries.

Why does this matter? The reason I initially enabled that second option was to future-proof to install Danger on those repos. Danger needs a GitHub access token in an environment variable which, for open source projects is just used to leave comments on GitHub pull requests. We never ended up adding Danger to those repos, and instead went for a Peril installation (see #28), so I think it's fine to disable this, but it will mean we can't add regular Danger to any of our repos. Again, that's totally fine but I wanted to raise it as a concern. Let me know if I can clarify any of this.

So yeah! Let's see what the rest of the community thinks (sure would be nice to be able to easily @ mention all the point-people for all our repos, but...). I'm very excited about this solution!

[freak4pc]

Thanks for the feedback @ashfurrow :)

I had similar security conern, but I felt like Peril entirely solves this, and I was also sort of "blacklisting" this option up until when you set-up Peril.

Repos that already have a Dangerfile won't have to run Danger locally since they get it "for free" with Peril, there would be no need for a repo-level secret since Peril has org-wide organization and runs Danger per-repository.

I think we'd be 100% good to turn this option off for all of our Repos. 💯

The other "Security concern" is anyone who is a RxSwiftCommunity member could attain the secret and do deploys with it, but this isn't something we can worry about because a member could, just as well, wipe out an entire project, or cause other serious damage. We can always swap out tokens AFAIK.

Any other community feedback would be highly appreciated :)

[orta]

Yeah, Peril does fix that.

TBH, I think this is great idea 👍

[devxoul]

- Cocoapods
+ CocoaPods

🤓

[freak4pc]

Haha :) Fair @devxoul

In my defense, I usually get it right 😉

[bobgodwinx]

@freak4pc I give my blessing to this solution 💯 I think it's fine when deployment happens only on new tags, which the most important thing. So I vote for this solution 👍

[freak4pc]

Our first Auto-Deploy was successful 🎉
https://circleci.com/gh/RxSwiftCommunity/RxGoogleMaps/13

[ashfurrow]

How exciting! Very well-done 😄 Looks like the pod trunk is really verbose, any way we can trim it down? Or is it verbose on purpose? Either way, looks good!

[freak4pc]

@ashfurrow Sure! We can definitely --silent it 👍
I sort of left it there to see "stuff is happening" since it was the first build ever.

When writing the docs for how to set this up (as its an optional step), we can link to that CircleCI file as an example, possibly

[ashfurrow]

Cool! I wonder if we can redirect the verbose output to an artefact directory is it's available for inspection if we need it, but still have like an inline quiet output?

[freak4pc]

Nothing built-in to that pod trunk push command but we can just pod trunk push --verbose ... > pod_trunk_push.log

[freak4pc]

@ashfurrow I did this here https://circleci.com/gh/RxSwiftCommunity/FakeRepo/34#artifacts/containers/0

But TBH - I have no idea why it's so verbose. it's not doing that locally for me and I didn't have that verbose flag on the original build on RxGoogleMaps 🤔

[ashfurrow]

Yeah I was surprised by that too. Normally pod trunk push is really parsimonious with its output. Maybe it detects its on a CI environment? Hmm.

[freak4pc]

Seems like it ... hm
This is how it looks locally for me:

[freak4pc]

@ashfurrow This seems OK. I really have no good idea of why this is happening: https://github.com/CocoaPods/cocoapods-trunk/blob/1a28c0957d00e6c679abbf037b2447080b3a8e26/lib/pod/command/trunk.rb#L74

EDIT: Ohh this is interesting https://discuss.circleci.com/t/cocoa-pods-is-running-in-verbose-mode/18112

[ashfurrow]

Mmmm okay. Could it be that we're not specifying a podspec for pod trunk push, so the spec param there is nil?

[freak4pc]

@ashfurrow Look at the second link there - it seems to be a known issue. I'll shoot an email to one of the support engineers and see if we can get some clarity.

[freak4pc]

@ashfurrow some info from Circle CI :

The CoacoaPods config file should be located in the homepath
~. You can edit it as you like prior to running anything. Though take note that if a build fails without the verbose logging it will be almost impossible for us to provide support. If you're okay with that then feel free to edit the file as needed in a config step.

I think its fine practically. We could potentially edit the config only for that part of the job (e.g. pod trunk push)

[ashfurrow]

Okay, sounds good. We can always change our minds later 🙃

[freak4pc]

@ashfurrow Just FYI, this is what I did:
https://github.com/RxSwiftCommunity/FakeRepo/blob/master/circle.yml#L24

It is quite the hack, but it works for that specific purpose :)

https://circleci.com/gh/RxSwiftCommunity/FakeRepo/42

What do you think?

[ashfurrow]

Makes sense! Good commenting 👍

[freak4pc]

@ashfurrow Funny enough, but I think this calls for a --noverbose flag to override the config file ;)

One day ...

[freak4pc]

I feel pretty confident closing this right now. It is not yet wide-spread across the entire existing community repos, but every new repo adds [email protected] as an owner, making it possibly to deal with owners that leave the community, which was the number concern around here.

For automatic deploys, several repos have this but it would take much more effort and community help to make this happen across all repos. The groundworks for this has been laid out with examples in RxSwiftExt, RxMKMapView, etc. so I don't think this issue is needed for now.

Thanks for all the feedback!