My iOS project includes some private pods. I have gone through the steps on my local machine (as well as team members) to use private pods outlined here.
How do I add the same process for VS App Center to update and retrieve the repo?
Currently, I get this in the build output:
[command]/usr/local/bin/pod install --repo-update
Updating local specs repositories
Cloning spec repo fooBar from git#github.com:fooBar/Podspec.git
[!] Unable to add a source with url git#github.fooBar/Podspec.git named fooBar.
You can try adding it manually in ~/.cocoapods/repos or via pod repo add.
[error]/usr/local/bin/pod failed with return code: 1
[error]The 'pod' command failed with error: /usr/local/bin/pod failed with return code: 1
Recently I was trying the same and it looks like it's impossible to achieve what you want in way you want.
TL;DR:
Use Carthage for your private dependencies and GIT LFS to store compiled dependency frameworks.
I've used GIT LFS to store Carthage/Build directory (that's actually all you need to compile your app).
I'm still using Cocoapods in my project to maintain public dependencies (somehow it's required in my project).
Why this way?
Because I've found this in AppCenter's docs:
Is your app fairly simple, without many customizations, and is the build pretty straightforward?
In App Center, if your app follows the usual standard layout on the respective platform and does not rely on a lot of external build steps, App Center finds the app automatically in your repository and builds it right away.
(see: Choose the right service for app builds)
So I realised that I really should use the simplest way to build the app on AppCenter. Hope that helps, even thought the answer came after such a long time :)
Related
I have a project using a Cocoapods as dependency manager and I am trying to create an Xcode Cloud workflow for it, everything look simple to configure and I added the ci_post_clone.sh to run the pod install command before start building.
Based on the logs all the dependencies are downloaded but whenever it starts building I have the No such Module X error, I am not sure what i did wrong but it looks like xcode Cloud misses the step of Building targets in dependency order and it starts building the main project before building the dependencies
Did anyone face this problem and how did you fix it
Thank you for your help
I found a temporary solution by adding the pod folder to my repository, this is not what most people are willing to do but for now it is working
do you have a screenshot for how you set this up? Because the script file ci_post_clone.sh needs to exist in a repository named ci_scripts that is at the same level as your workspace / xcode project. You also need to be sure to mark that file as executable
then you can brew install cocoapods and run pod install on that script. cheers! just got this working this morning by following notes found here: https://developer.apple.com/documentation/xcode/making-dependencies-available-to-xcode-cloud
I have a project and:
the company I'm working with is self-hosting their git
the CI can communicate only with company's network
That being said, if I want to install any dependency, I have to ask their dev ops to mirror the target repository and only then I can use it.
The problem arises when I want to implement Crashlytics which has a lot of dependencies. When I import the Firebase, it's fetched from the mirrored repo correctly, but it's dependencies are still being fetched from the original URLs (which makes perfect sense).
The question is - How do I tell Swift Package Manager to swap each URL with mirrors? I have all the dependencies mirrored. I only need to tell SPM to use it.
I have found this proposal which was implemented in Swift 5, but when I go to root of my project and run:
$ swift package config set-mirror --package-url <original URL> --mirror-url <mirror URL>
I get this error:
error: root manifest not found
Any ideas how to do this correctly? Thank you
EDIT:
As Florian correctly pointed out, the proposal works from the package's repository, not my projects! So:
I do clone mirrored repo in my project's root
I run set of commands to set mirror url for each dependency:
swift package config set-mirror \
--original-url https://github.com/google/GoogleAppMeasurement.git \
--mirror-url <company's url>/mirrors/githubcom-google-GoogleAppMeasurement
I go back to projects root and run:
xcodebuild -resolvePackageDependencies -project MyProject.xcodeproj -scheme MyAppScheme
But it's still fetching from original urls, not the mirrors!
Having an Xcode project makes this task basically impossible (at the time of writing). Xcode's integration with SPM works fine for most things, but is not (yet?) at par with what SPM can do in pure SPM packages.
The problem is, that swift package config is always only local to the package and does not have any effect on projects / packages that depend on the package. And with Xcode currently having no counterpart to swift package config, it's not possible to do this at the moment.
What you could do, however, is to clone all your dependencies locally and then reference them as local packages from Xcode (simply dragging the package folder into the open Xcode project will do so). Xcode will be smart enough to take the dependencies from the local local checkout (or at least it was smart enough last time I tried this).
Let's hope for a future Xcode version with full SPM support!
I work on a team that is an iOS contractor for a larger company. We are helping the large company build a iOS app with Xcode and we use Cocoapods to manage our dependencies in the project. However, the large company has internal Cocoapods that are hosted behind their firewall that we, the contractors, cannot see or touch. This produces many issues for the developers outside the firewall not the least of which is that 'pod update' and 'pod install' both fail with:
Update all pods
Cloning spec repo `xxx-podName` from `https://xxxx.git`
[!] Unable to add a source with url `https://xxxxx.git` named `xxx-podName`.
You can try adding it manually in `~/.cocoapods/repos` or via `pod repo add`.
Because these repos/pods rarely are changed outside of our project we don't usually need to actually pull down new/updated code from them. Still there are many important side-effects from the 'pod' commands that our team would like to be able to accomplish, such as the re-structuring/regeneration of the workspace and project files along with other the auto-magic processes that occur when 'update' or 'install' are run (such as the building of shell scripts).
Is there a 'contactless' way to rebuild or create the correct project/target/workspace structuring for an Xcode project with cocoapods that can succeed even if the machine running the command cannot access the hosted pods?
I'm trying to create a new pod (Cocoapod) for an iOS library and have followed the tutorial instructions at https://guides.cocoapods.org/making/using-pod-lib-create. I currently don't have a remote repo, but have a local project with git history. After running the pod lib create command (running Cocoapods v.0.37.2), and opening up the resultant project, it looks similar to the example pictured on the above tutorial link:
My questions are:
As I don't have my project hosted remotely (i.e., Github), and referencing the image above, should I use the Example for MyLib part for my remote repo, obviously adding anything else to it that I would need? If so, how should I include my library that I want to make into a pod? I noticed that the example project was initialized as a git repo. Edit: I did see on http://nshipster.com/cocoapods/ that invoking pod try will use the created example project, so I'm guessing I should use the created example project for my remote repo if I want that feature?
Or should I configure my pre-existing MyLib project with the newly created podspec file, etc, and push that to my remote repo, following the instructions at https://guides.cocoapods.org/making/making-a-cocoapod.html?
Under "Making a Demo Application" on the pod lib create tutorial link it's stated:
"The template will generate an Xcode project for your library. This means you don't have to go through creating a new project in Xcode.
If you want to have an example project for pod try MyLib or need to have your library's tests run inside an application ( interaction tests, custom fonts, etc ) then you should say yes. A good metric is "Should this Pod include a screenshot?"; if so, then you should have a demo."
Thanks!
After doing more research and trying a few things out, I ended up going with my first option: using the example project created by the pod lib create command. From consulting numerous sources and tutorials, I found this one to be the most accurate and helpful in this process (at least at the time of this being written): "Your First CocoaPod".
Specifically, the line:
Add the Demo/Pods folder, which includes all the pods installed from pod install, to .gitignore.
addressed one of my concerns about what to do with the Pods folder. After that, I was able to push my example project to my remote repo, and then ultimately to publish my pod. In summary, it appears I could have either used the pod lib create command to create my example project, or generated a podspec file manually to be used with my pre-existing library that contained a sample project.
I am working on a project which includes other repositories from Git.
I would like to keep up to date with these repositories. Know what are the latest features, bug fixes etc.
Qu 1) What is the best way to keep up to date with a repository on Git without receiving emails of all issues reported etc?
After this is complete I would like to know the best way to include these into your project. I understand you can copy the source code into the project, but what are cocoapods/sub modules used for? For example, what is the correct way to update your project with the latest changes to that included repository?
Are there any GUIs for either of these methods as opposed to terminal?
Cocoapods is a great way to include other projects in your Xcode project. The Cocoapods project maintains a list of pod spec files for a many open source libraries, which specify where to download the code and how to integrate them into an existing project. As you noted, you'd traditionally have to add a git submodule, manually add the source files to your project, update your build settings, and so forth. Cocoapods takes care of all of this for you.
I'm not sure of a way to track updates for Github projects without also being notified about issues, but Cocoapods can certainly tell you if any of your 'pods' have become outdated. It's then one command to update them to the latest versions. That said, it's generally best practice to 'lock' your external dependencies to a specific version that you know works correctly.
Using Cocoapods
To get started, first install Cocoapods. You then simply need to create a file in your root project directory (the same directory that contains your .xcodeproj file) called Podfile. Inside, you can specify your target OS, and your dependencies:
platform :ios, '5.0'
pod 'AFNetworking', '0.9.1'
pod 'OHAttributedLabel', '0.1.1'
The example above is targeting iOS 5.0, and pulling in the AFNetworking and OHAttributedLabel projects.
Then, in the Terminal, change to your project directory:
> cd path/to/my/project
And run pod install.
> pod install
This will check out the latest version of your dependencies for you. It will also generate you a .xcworkspace file. From now on, when you work on your project, you must open the .xcworkspace, not the .xcodeproj file.
Inside your new workspace, you'll have your existing Xcode project and a new Pods project - this contains all of your third party libraries. Just build and run your app as normal, and the Pods project will also be built and included.
Some other useful Cocoapods commands:
> pod outdated
Will list all dependencies that have an update available.
> pod search query
Will search all known Pod specs for 'query'. Useful for finding new libraries!
Tutorials
Looks like Tutsplus have a nice tutorial on getting started with Cocoapods
There's a free episode of NSScreencast on Cocoapods
GUIs
I'm afraid I don't know of any GUIs for Cocoapods, but there really aren't many Terminal commands that you need to know. It's worth getting comfortable with the command line, as it's such a useful developer tool.
That said, as far as I know, Appcode (Jetbrains' alternative IDE for Objective-C) is planning on adding Cocoapods support in their next update.
Good luck!
James Frost's answer is an excellent explanation of how to work with Cocoapods and their advantages over submodules.
A few important advantages submodules have over Cocoapods are:
submodules are sub-repos - not only does this mean that git and git GUIs implicitly recognize them and more and more support easily working with them, it also means that your dependencies stay connected the wonderful world their git repos, Cocoapods or not, reside in. This means that you are able to collaborate and test changes from within your project, your project usually being the source of inspiration for elaboration of a dependency.
Unfortunately Cocoapods do not maintain this link, to work on a dependency means to clone it from git, outside of the range of Cocoapods.
Edit: It's worth noting that Cocoapods does allow working on a local pod with the path or local fields or even building your own Spec repo but it still isn't as simple a process.
one less tool dependency - as mentioned in the previous bullet, submodules are a function of git and your using git means they are available to you. Any software's adoption of git implies that they will eventually support either all (important) features of git or all features that cover common use cases. Xcode 5 has brought in a basic support for git and GUIs (which are tool dependencies, it's true, but hopefully just dictate how information is surface, git dictates how it works) like Git Tower make working with sub-repos straightforward.
Cocoapods has come a long way and everyday is taking steps to becoming a stable, indispensable tool. However it hasn't yet gotten a nod from Apple and there isn't any reason why Apple won't release a change to Xcode that breaks Cocoapods. Additionally Cocoapods is dependant on Ruby. Aside, considering how much attention and community has been generated around Cocoapods it would be silly for Apple to ignore it.
It's also worth noting that using one does not lock you out of using the other. It might be a headache or it might be what you need, perhaps using Cocoapods for tiny one class libraries or libraries with complex dependancies and submodules for libraries with that you will be interacting with often.