flutter build fails on pod versioning issue with firebase_storage

Jenkins build stopped working after we checked in ios/Podfile.lock for consistency.

Building for device (ios-release)...
Running pod install...                                           1.1s
CocoaPods' output:
↳
      Preparing

    Analyzing dependencies

    Inspecting targets to integrate
      Using `ARCHS` setting to build architectures of target `Pods-Runner`: (``)

    Finding Podfile changes
      M Flutter
      - background_fetch
      - camera
      - cloud_firestore
      - connectivity
      - contacts_service
      - device_info
      - firebase_auth
      - firebase_core
      - firebase_messaging
      - firebase_storage
...

 Fetching external sources
    -> Fetching podspec for `Flutter` from `.symlinks/flutter/ios-release`
    -> Fetching podspec for `background_fetch` from `.symlinks/plugins/background_fetch/ios`
    -> Fetching podspec for `camera` from `.symlinks/plugins/camera/ios`
    -> Fetching podspec for `cloud_firestore` from `.symlinks/plugins/cloud_firestore/ios`
    -> Fetching podspec for `connectivity` from `.symlinks/plugins/connectivity/ios`
    -> Fetching podspec for `contacts_service` from `.symlinks/plugins/contacts_service/ios`
    -> Fetching podspec for `device_info` from `.symlinks/plugins/device_info/ios`
    -> Fetching podspec for `firebase_auth` from `.symlinks/plugins/firebase_auth/ios`
    -> Fetching podspec for `firebase_core` from `.symlinks/plugins/firebase_core/ios`
    -> Fetching podspec for `firebase_messaging` from `.symlinks/plugins/firebase_messaging/ios`
    -> Fetching podspec for `firebase_storage` from `.symlinks/plugins/firebase_storage/ios`
...

    Resolving dependencies of `Podfile`
    [!] CocoaPods could not find compatible versions for pod "Firebase/Storage":
      In snapshot (Podfile.lock):
        Firebase/Storage (= 5.14.0)

      In Podfile:
        firebase_storage (from `.symlinks/plugins/firebase_storage/ios`) was resolved to 0.0.1, which depends on
          Firebase/Storage

    It seems like you've changed the constraints of dependency `Firebase/Storage` inside your development pod `firebase_storage`.
    You should run `pod update Firebase/Storage` to apply changes you've made.

    /usr/local/lib/ruby/gems/2.5.0/gems/molinillo-0.6.6/lib/molinillo/resolution.rb:328:in `raise_error_unless_state'
    /usr/local/lib/ruby/gems/2.5.0/gems/molinillo-0.6.6/lib/molinillo/resolution.rb:310:in `block in unwind_for_conflict'
    /usr/local/lib/ruby/gems/2.5.0/gems/molinillo-0.6.6/lib/molinillo/resolution.rb:308:in `tap'
    /usr/local/lib/ruby/gems/2.5.0/gems/molinillo-0.6.6/lib/molinillo/resolution.rb:308:in `unwind_for_conflict'
    /usr/local/lib/ruby/gems/2.5.0/gems/molinillo-0.6.6/lib/molinillo/resolution.rb:257:in `process_topmost_state'
    /usr/local/lib/ruby/gems/2.5.0/gems/molinillo-0.6.6/lib/molinillo/resolution.rb:182:in `resolve'
    /usr/local/lib/ruby/gems/2.5.0/gems/molinillo-0.6.6/lib/molinillo/resolver.rb:43:in `resolve'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/resolver.rb:123:in `resolve'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/installer/analyzer.rb:781:in `block in resolve_dependencies'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/user_interface.rb:64:in `section'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/installer/analyzer.rb:779:in `resolve_dependencies'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/installer/analyzer.rb:88:in `analyze'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/installer.rb:243:in `analyze'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/installer.rb:154:in `block in resolve_dependencies'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/user_interface.rb:64:in `section'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/installer.rb:153:in `resolve_dependencies'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/installer.rb:116:in `install!'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/command/install.rb:41:in `run'
    /usr/local/lib/ruby/gems/2.5.0/gems/claide-1.0.2/lib/claide/command.rb:334:in `run'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/lib/cocoapods/command.rb:52:in `run'
    /usr/local/lib/ruby/gems/2.5.0/gems/cocoapods-1.5.3/bin/pod:55:in `<top (required)>'
    /usr/local/bin/pod:23:in `load'
    /usr/local/bin/pod:23:in `<main>'

Error running pod install
script returned exit code 1

Locally we can fix this by doing a pod update, and it works after that. But this is undesirable to do in every build in Jenkins because it will actually change the pod versions, and also it seems very cumbersome to do a pod update, then re-checkout the possibly changed Podfile.lock on every jenkins build.

I wonder if this issue is because the flutter plugins don't set a version in their podspecs?
e.g. here: https://github.com/flutter/plugins/blob/master/packages/firebase_storage/ios/firebase_storage.podspec#L19

Podfile for reference:

# Uncomment this line to define a global platform for your project
platform :ios, '9.3'

# CocoaPods analytics sends network stats synchronously affecting flutter build latency.
ENV['COCOAPODS_DISABLE_STATS'] = 'true'

def parse_KV_file(file, separator='=')
  file_abs_path = File.expand_path(file)
  if !File.exists? file_abs_path
    return [];
  end
  pods_ary = []
  skip_line_start_symbols = ["#", "/"]
  File.foreach(file_abs_path) { |line|
      next if skip_line_start_symbols.any? { |symbol| line =~ /^\s*#{symbol}/ }
      plugin = line.split(pattern=separator)
      if plugin.length == 2
        podname = plugin[0].strip()
        path = plugin[1].strip()
        podpath = File.expand_path("#{path}", file_abs_path)
        pods_ary.push({:name => podname, :path => podpath});
      else
        puts "Invalid plugin specification: #{line}"
      end
  }
  return pods_ary
end

target 'Runner' do
  use_frameworks!

  # Prepare symlinks folder. We use symlinks to avoid having Podfile.lock
  # referring to absolute paths on developers' machines.
  system('rm -rf .symlinks')
  system('mkdir -p .symlinks/plugins')

  # Flutter Pods
  generated_xcode_build_settings = parse_KV_file('./Flutter/Generated.xcconfig')
  if generated_xcode_build_settings.empty?
    puts "Generated.xcconfig must exist. If you're running pod install manually, make sure flutter packages get is executed first."
  end
  generated_xcode_build_settings.map { |p|
    if p[:name] == 'FLUTTER_FRAMEWORK_DIR'
      symlink = File.join('.symlinks', 'flutter')
      File.symlink(File.dirname(p[:path]), symlink)
      pod 'Flutter', :path => File.join(symlink, File.basename(p[:path]))
    end
  }

  # Plugin Pods
  plugin_pods = parse_KV_file('../.flutter-plugins')
  plugin_pods.map { |p|
    symlink = File.join('.symlinks', 'plugins', p[:name])
    File.symlink(p[:path], symlink)
    pod p[:name], :path => File.join(symlink, 'ios')
  }
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ENABLE_BITCODE'] = 'NO'
    end
  end
end

What do your dependencies in pubspec.yaml look like?
Are you using the same Flutter version locally and in Jenkins?

Our pubspec looks like the following:

name: my_app
description: My app

version: 0.1.0+1

environment:
 sdk: ">=2.0.0-dev.68.0 <3.0.0"

dependencies:
 flutter:
   sdk: flutter
 cloud_firestore: 0.8.2+1
 cupertino_icons: 0.1.2
 firebase_messaging: 2.0.3
 # Has dependency on  firebase_storage: 1.0.4
 my_storage_flutter:
     path: ../../pkgs/io/my_storage_flutter
...

In Jenkins we are using
Flutter (Channel stable, v1.0.0, on Mac OS X 10.14.1 18B75, locale en-US)

Locally we have a few versions among people, but the build works for everyone:

Flutter 1.0.0 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 5391447fae (3 weeks ago) • 2018-11-29 19:41:26 -0800

Flutter 1.0.0 • channel beta • https://github.com/flutter/flutter.git
Framework • revision 5391447fae (3 weeks ago) • 2018-11-29 19:41:26 -0800
Engine • revision 7375a0f414
Tools • Dart 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

Flutter 1.0.1-pre.72 • channel master • https://github.com/flutter/flutter.git
Framework • revision a039b2ca8c (3 days ago) • 2018-12-17 11:15:27 -0800
Engine • revision 5af435098d
Tools • Dart 2.2.0 (build 2.2.0-dev.1.1 f9ebf21297)

Quick update: someone who was on

Flutter 1.0.1-pre.72 • channel master • https://github.com/flutter/flutter.git
Framework • revision a039b2ca8c (3 days ago) • 2018-12-17 11:15:27 -0800
Engine • revision 5af435098d
Tools • Dart 2.2.0 (build 2.2.0-dev.1.1 f9ebf21297)

got the same issue after checking out the Podfile.lock. He also tried using stable channel and had the same issue.

pod update temporarily fixes it for now, but still doesn't explain why flutter build doesn't respect the Podfile.lock for versions and runs into issues with the podspec of the firebase_storage plugin.

I've been struggling with this while trying to set up a small CI setup at home using TeamCity. One of my two Macs works fine, but the other fails similarly to yours.

I then discovered a fix. If I run pod outdated on the one that fails, it updates some CocoaPods dependencies:

macncheese:ios teamcity-agent$ pod outdated
Updating spec repo `master`
  $ /usr/bin/git -C /Users/teamcity-agent/.cocoapods/repos/master fetch origin
  --progress
  remote: Enumerating objects: 50876, done.        
  remote: Counting objects: 100% (50876/50876), done.        
  remote: Compressing objects: 100% (3228/3228), done.        
  remote: Total 188793 (delta 48710), reused 49157 (delta 47424), pack-reused 137917
  Receiving objects: 100% (188793/188793), 22.09 MiB | 12.99 MiB/s, done.
  Resolving deltas: 100% (124939/124939), completed with 8449 local objects.
  From https://github.com/CocoaPods/Specs
     75906f81a2e..8d4878d7228  master     -> origin/master
   + 1f285e11d26...02443419999 indexes    -> origin/indexes  (forced update)
   * [new branch]              netlify    -> origin/netlify
  $ /usr/bin/git -C /Users/teamcity-agent/.cocoapods/repos/master rev-parse
  --abbrev-ref HEAD
  master
  $ /usr/bin/git -C /Users/teamcity-agent/.cocoapods/repos/master reset --hard
  origin/master
  Checking out files: 100% (18643/18643), done.
  HEAD is now at 8d4878d7228 [Add] BluetoothMessageProtocol 1.2.0
Analyzing dependencies
The color indicates what happens when you run `pod update`
<green>	 - Will be updated to the newest version
<blue>	 - Will be updated, but not to the newest version because of specified version in Podfile
<red>	 - Will not be updated because of specified version in Podfile

The following pod updates are available:
- Flutter 1.0.0 -> 1.0.0 (latest version 1.3.1)
- gRPC-Core 1.21.0 -> 1.21.0 (latest version 1.22.0-pre1)
- Protobuf 3.8.0 -> 3.8.0 (latest version 3.9.0-rc1)

[!] Automatically assigning platform `ios` with version `8.0` on target `Runner` because no platform was specified. Please specify a platform for this target in your Podfile. See `https://guides.cocoapods.org/syntax/podfile.html#platform`.

After doing this, pod install completed successfully as did my build-and-deploy configuration in TeamCity.

Looking at the various pod commands, I think that simply doing a pod repo update would do the necessary things to get things working. I'm going to add that to my CI steps and see if that keeps things working properly.

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

flutter build fails on pod versioning issue with firebase_storage #25592

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

flutter build fails on pod versioning issue with firebase_storage #25592

Description

Activity

zoechi commented on Dec 20, 2018

yanpingql commented on Dec 20, 2018

yanpingql commented on Dec 20, 2018

Daghis commented on Jun 29, 2019

github-actions commented on Aug 14, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions