Fastlane build not working

[digitaldan]

Hey @timbms @weakfl , out testflight build expired , and I'm having some trouble getting our fastlane actions to work to push to testflight now. it was complaining about build artifacts being present when tying to bump the local commit version, i think i fixed that, but now its complaining:

Please update using `bundle update fastlane`
Error: Error: Executing lane beta failed.
Error: Executing lane beta failed.

Any thoughts on this? I'll do some homework on it when i can today.

[digitaldan]

I guess one of the actions actually uploaded to Apple, and just failed to commit the version bump here, so i think we are ok for the time being on getting a build pushed out, so less of a fire right now.

[florian-h05]

I can confirm that I just received a new build: Version 2.4.61 (1580410539) via TestFlight.

[weakfl]

@digitaldan

Found unexpected uncommitted changes in the working directory. Expected these files to have changed: 
CHANGELOG.md
openHAB.xcodeproj/project.pbxproj
openHAB/openHAB-Info.plist
openHABWatch/Info.plist
openHABIntents/Info.plist
openHABTestsSwift/Info.plist
openHABUITests/Info.plist.
But found these actual changes: 
openHAB.xcodeproj/project.pbxproj
openHABUITests/OpenHABUITests.swift
openHABWatch Extension/Views/ContentView.swift.

Looks like OpenHABUITests.swift and ContentView.swift have been changed but maybe not formatted. When the code gets formatted during the CI build there are unexpected changes, hence the action fails. Maybe you changed the files but didn't compile locally before commiting them?

Personally I'd revert #745, imho the action should fail if there are unexpected changes and not just discard them.

A better way to fail the build might be to use ensure_git_status_clean before upload_to_testflight and just ignore the build artifacts required for the upload.

[david-pace]

Hi, it looks like the openHAB iOS Beta has expired. On the Testflight page, it says that currently the app does not accept any new testers so the app is unusable at the moment.

Is it possible to push a new Beta manually (in case the Fastlane build cannot be fixed)? Is there anything I can do to help?

[digitaldan]

We pushed a build yesterday , but had to remove the watch target as Apple tech support is working to figure out why our Watch ID has disappeared from their system (which is why we have not pushed a new build in a while) . Its still "under review" , hopefully that gets accepted soon.

[florian-h05]

Probably we could publish a new app version soon?
The last update is one year old and since then there are a few nice improvements, e.g. f7 and material icons support, always allow WebRTC …
IMO these are enough improvements to justify a new version. I’m only on the beta to get these improvements …

[hansbogert]

Also don't forget this issue which is at least partially fixed. Which, according to my wife ;), is also a big reason to push a new version.

[digitaldan]

I mentioned this on the forums , but we are prevented form pushing to the App store right now. Our provisioning ID for the watch app has disappeared from our account, which according to Apple should not be possible. This means we fail building and validation unless we remove the watch app completely. This ID can not be changed once an app is published. Apple has escalated our case to internal engineering , but we are now in a waiting period. As soon as we can resolve this, we can promote a testflight build to the app store.

[florian-h05]

Thanks for the info, haven‘t known that. That‘s not nice to hear …

[digitaldan]

Here's the latest news from Apple. I spoke with a developer support rep on Friday after months of back and forth emails. Basically, our watch ID has been claimed by another developer account, and they won't tell us who that is or reclaim it for us.
Because of this, we can no longer push our app with watchkit support any longer as that ID can not be changed once published in the app store. This seems to be confusing to Apple as well as we have gone through several back and forth with tickets escalated to their dev team.

Our case is still open and i sent a fresh batch of error logs to them after trying a few changes they recommended, but i have little to no confidence now that Apple is going to be able to help.

My suggestion is that we publish this as a new app and new app ID into the app store. I would also like to then push an update to our existing app that will direct users to download the new app, maybe a simple popup that gets triggered at launch stating the issue.

@weakfl @timbms let me know what you think.

[timbms]

Your proposal seems to be the most reasonable escape. I fully support it.
Ideally we should make some bold changes 1) raising the deployment target to iOS 14 2) discontinuing the support for openHAB v1

[weakfl]

Your proposal seems to be the most reasonable escape. I fully support it.
Ideally we should make some bold changes 1) raising the deployment target to iOS 14 2) discontinuing the support for openHAB v1

Agreed.

Looking forward to Apple rejecting the new App because it uses the same icon 😜

[digitaldan]

Yeah, i think its a good time to make some upgrades, I like both suggestions. Another thing i would like to do is have our app use Firebase (FCM) for the push notifications. We are switching the Android client over to a unified FCM account this Friday, and I already have this FCM account set up to talk with Apple APNS using our existing certificate. This will allow us to have one messaging path in the cloud service and hopefully speed up development of new features, right now supporting both is kinda a pain.

https://firebase.google.com/docs/cloud-messaging/ios/client

[weakfl]

We also have to add a privacy manifest and update all 3rd party dependencies that require them as well. This is now mandatory.

[timbms]

Great. Let's get things rolling. What is the next step? Branching off main?