Pod updates…


Alex Zavatone
 

We just got through a mess in our process where the build Mac was using Fastlane to perform a pod update but it would do it without doing a pull first, and then pushed the changes, so many daily changes to project.pbxproj (such as build script order) were removed every day.

Thinking about this, I am considering a script that will run once a day locally to perform a pod update once per day on the first build of the day and write the date to an untracked file so that it only happens once per day. Each programmer is expected to pull from the remote so this should not cause any damage and only make sure that our pods are up to date once per day.

Before I waste my time and try this out, does anyone have any concerns about this approach or does it seem like I am missing something here?

Thanks in advance.

Alex Zavatone.


Ben Kennedy
 

On 05 Mar 2019, at 4:58 pm, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

We just got through a mess in our process where the build Mac was using Fastlane to perform a pod update but it would do it without doing a pull first, and then pushed the changes, so many daily changes to project.pbxproj (such as build script order) were removed every day.
What?

Your Podfile.lock is committed to the repo, right? `pod update` will install the precise versions of the pods indicated there. The project file might get modified trivially, depending on the version of CocoaPods available and the particulars of the committed pbxproj file, but those are transient changes that can get deleted after the build.

An automated process that makes regular commits to the development branch sounds like an unusual approach to me. What problem is it trying to solve?

-ben


Alex Zavatone
 

On Mar 5, 2019, at 7:03 PM, Ben Kennedy <ben-groups@zygoat.ca> wrote:


On 05 Mar 2019, at 4:58 pm, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

We just got through a mess in our process where the build Mac was using Fastlane to perform a pod update but it would do it without doing a pull first, and then pushed the changes, so many daily changes to project.pbxproj (such as build script order) were removed every day.
What?

Your Podfile.lock is committed to the repo, right? `pod update` will install the precise versions of the pods indicated there. The project file might get modified trivially, depending on the version of CocoaPods available and the particulars of the committed pbxproj file, but those are transient changes that can get deleted after the build.
Yeah, I know. I don’t have the time to do any more research into this, but for some odd (ill thought out) reasons, some processes on the build machine were doing several things incorrectly, including directly writing incremented version number into the the project.pbxproj file in several places and littering the git commit history with “Updated build version# to XXX”. Another Fastlane script was part of the build process and was performing a pod update through Fastlane and then pushing the changes.

The end result was that if anyone had made changes to master, like build script order, committed and pushed them to master, as soon as the processes on the build machine had run, those changes would have essentially been undone.

This build Mac is on the other side of the planet and I can not access it. Therefore, I am going through the work to create one that I do have access to and will replace the one that the other team used. Considering how the code that the other team had on the original build machine screwed up any changes in project.pbxproj (I had to make identical changes, commit and push 6 times before I told them that their build Mac was somehow erasing the changes committed), I want to make sure that…

1. My code doesn’t screw up their lives as their build server code screwed up mine.
2. We have a method that runs once per day that allows pod update to keep our pods up to date for everyone.

It’s been a fun month, with lots and lots of fustercluck caused by a team who doesn’t think about race cases and how distributed teams need to not screw up the work of the other parts of the team.

No, no. It hasn’t been a fun month. It’s been 2.

An automated process that makes regular commits to the development branch sounds like an unusual approach to me. What problem is it trying to solve?
Yeah, someone put a pod update and then a push as part of the build process, but only after also writing the version number in the wrong place and actually into the project.pbxproj because they thought it was a good idea to litter the commit history with version number updates. Variables like CFBundleShortVersionString and CFBundleVersion exist for a reason.

Someone instead wanted to write that to CURRENT_PROJECT_VERSION within the app build settings in the project.pbxproj. And they are also attempting to codesign all 3 build configs with a distro profile and think that’s there’s nothing wrong with that and with sharing developer creds. Who needs to be responsible for their own changes when you can check them in under another team member’s name?!

I just ask that you nuke me from orbit and remove all this pain. It’s the only to be sure.

Nuke twice good measure.

Thank you in advance.
Alex Zavatone.

-ben




Ben Kennedy
 

On 05 Mar 2019, at 8:35 pm, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

2. We have a method that runs once per day that allows pod update to keep our pods up to date for everyone.
I made a major blunder in my previous reply: I said `pod update` when I meant to say `pod install`. These are very different.

You should never be running `pod update` on an automated basis, because that will just bring random new code into the branch, without any human integration or testing.

With Podfile.lock committed, anyone checking out a particular branch should get whatever pods are specified at that commit. On the build machine, `pod install` should run as part of the build process, after checking out the branch and before running xcodebuild. Any side effects should be temporarily local to the workspace, and not affect the remote repo nor anyone else.

It almost sounds like you might be confusing `pod update` with `pod install`.

-ben

(P.S. I am having déjà vu writing this, because I feel as though we had a variant of this conversation a couple of years ago -- complete with my making the same blunder and typing `pod update` when I meant `pod install`, and having to correct myself...)


Alex Zavatone
 



On Mar 5, 2019, at 11:10 PM, Ben Kennedy <ben-groups@...> wrote:

On 05 Mar 2019, at 8:35 pm, Alex Zavatone via Groups.Io <zav@...> wrote:

2. We have a method that runs once per day that allows pod update to keep our pods up to date for everyone.

I made a major blunder in my previous reply: I said `pod update` when I meant to say `pod install`. These are very different.

You should never be running `pod update` on an automated basis, because that will just bring random new code into the branch, without any human integration or testing.

I know, I know, I know.  You’re not wrong.  

This is how the team has chosen to operate and if one team member updates their pods, everyone does or we get pod update mismatches.  This is the lesser evil of solutions that we have at the moment,  

The problem is that once pod update runs - either manually or automatically, it moves the [CP] Check Pods Manifest.lock file ahead of every other build script for that target.  We didn’t ask it to do that, but it does.  

Is there any documentation that you are aware of on project.pbxproj, specifically the target file build script order?  

I’ve moved the script to the build settings pre-action script and have gotten that working, but I’d still like to keep most everything in one place when possible.  


With Podfile.lock committed, anyone checking out a particular branch should get whatever pods are specified at that commit. On the build machine, `pod install` should run as part of the build process, after checking out the branch and before running xcodebuild. Any side effects should be temporarily local to the workspace, and not affect the remote repo nor anyone else.


I’m not sure on that, because the team will not necessarily have been coding using the most updated pods, while the build server is building against the latest pods.

You don’t mention if you expect the build server to discard the changes after performing an update or if you expect it to check in the changes.

We have a problem where our build server was checking in the changes.  Our build server is on the other side of the planet and builds ran at midnight.  This meant that if I made a branch in the morning, the build server ran and checked in the updated pods, which meant that a conflict was caused midday our time.  By the time I commit my branch and issue a pull request at the end of the day, the build server had run, performed a pod update, checked those changes in and blammo, instant set of 30 something conflicts in project.pbxproj.

It almost sounds like you might be confusing `pod update` with `pod install`.

-ben

(P.S. I am having déjà vu writing this, because I feel as though we had a variant of this conversation a couple of years ago -- complete with my making the same blunder and typing `pod update` when I meant `pod install`, and having to correct myself…)

Sure did, Ben,   We did and I am on a different team that updates their pods daily.  I strongly wish that I was on your team with your build server, but that is not world in which I live.

Cheers and thanks for getting me into at least getting this to work in the build pre action script

exec > ${PROJECT_DIR}/prebuild.log 2>&1
echo "Starting build scheme Pre-actions"
${PROJECT_DIR}/Build-Phases/Pods_setup_verification.sh



Ben Kennedy
 

On 20 Mar 2019, at 1:31 pm, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

This is how the team has chosen to operate and if one team member updates their pods, everyone does or we get pod update mismatches. This is the lesser evil of solutions that we have at the moment,
I don't understand why. Don't you employ a code review before merging to `development` or whatever your common trunk branch is?

The problem is that once pod update runs - either manually or automatically, it moves the [CP] Check Pods Manifest.lock file ahead of every other build script for that target. We didn’t ask it to do that, but it does.
Interesting. A couple of years ago, in the project I was working on at the time, we had some custom script phases into which I put the equivalent “check Manifest.lock” script because that was desirable, for some reason or another, over having CocoaPods insert its own build phase. In that day, it seemed to work; I suppose CocoaPods only added its own phase on first-time integration, or something. But indeed it looks like current versions re-generate that build phase as the first one every time. Sounds like a question to pursue with the CocoaPods folk, to see if that can be suppressed. I don't know the answer.

I’m not sure on that, because the team will not necessarily have been coding using the most updated pods, while the build server is building against the latest pods.
How does this differ from any other feature branch being out of date with its trunk? Take CocoaPods out of the equation. This sounds like a workflow problem.

You don’t mention if you expect the build server to discard the changes after performing an update or if you expect it to check in the changes.
I would never expect my build server to perform a `pod update`, nor would I ever expect it to check in random automated changes to my dependencies.

Sure did, Ben, We did and I am on a different team that updates their pods daily.
🍻 Well, I'm on a different team now too, but we still update our pods manually, and periodically. :)

b


Alex Zavatone
 

On Mar 21, 2019, at 6:27 PM, Ben Kennedy <ben-groups@zygoat.ca> wrote:


On 20 Mar 2019, at 1:31 pm, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

This is how the team has chosen to operate and if one team member updates their pods, everyone does or we get pod update mismatches. This is the lesser evil of solutions that we have at the moment,
I don't understand why. Don't you employ a code review before merging to `development` or whatever your common trunk branch is?
Yeah, it’s not worth spending your time on.

I’m changing the process as the word, intractable, has become part of the development process.


The problem is that once pod update runs - either manually or automatically, it moves the [CP] Check Pods Manifest.lock file ahead of every other build script for that target. We didn’t ask it to do that, but it does.
Interesting. A couple of years ago, in the project I was working on at the time, we had some custom script phases into which I put the equivalent “check Manifest.lock” script because that was desirable, for some reason or another, over having CocoaPods insert its own build phase. In that day, it seemed to work; I suppose CocoaPods only added its own phase on first-time integration, or something. But indeed it looks like current versions re-generate that build phase as the first one every time. Sounds like a question to pursue with the CocoaPods folk, to see if that can be suppressed. I don't know the answer.

I’m not sure on that, because the team will not necessarily have been coding using the most updated pods, while the build server is building against the latest pods.
How does this differ from any other feature branch being out of date with its trunk? Take CocoaPods out of the equation. This sounds like a workflow problem.
It doesn’t, BUT this literally guarantees that there will be a merge conflict every day, creating a clunky and cumbersome work process. Even if there is one conflict because someone wrote a poor build # increment script that is updating every setting that might be thought of as a build version number, it’s adding an unnecessary conflict to the process. We use VSTS as our git repo, so, we have to go through a certain flow in VSTS with pull requests, no matter what.

Now, when pods is introduced into the mix, the format of changes that are made to project.pbxproj when the updated pod info is written (line feeds vs everything on one line type stuff) create large blocks of annoying conflicts and with 14 pods, this ends up creating a simple mess for anyone simply trying to check in changes if pod updates happened before they checked their changes in.

Yes, I am changing this too. The pods project.pbxproj should be where these changes should be, but… So much not correct.


You don’t mention if you expect the build server to discard the changes after performing an update or if you expect it to check in the changes.
I would never expect my build server to perform a `pod update`, nor would I ever expect it to check in random automated changes to my dependencies.

Sure did, Ben, We did and I am on a different team that updates their pods daily.
🍻 Well, I'm on a different team now too, but we still update our pods manually, and periodically. :)
This rational approach to updating dependencies. It is so…

Rational.

That would never work on my team. We just hardcode random additional user defined properties into the build settings and make commits from the build server back into master on a daily basis so we can build up resistance to greater build setting instability and branch merge conflicts.

Oh, yes. I almost forgot. And set all code signing options to Distribution and the provisioning profiles for all build configurations to iOS Distribution, because we don’t know any better and then refuse to insist on changing it, while we have added a user defined build setting to attempt to override provisioning to something, and which of course mysteriously is sitting in our build settings, because why not?