Migrate this to a fastlane action instead of plugin

[ddralves]

In view of the fact that HockeyApp will soon be discontinued, is there any thoughts going into perhaps migrating this fastlane plugin so that it can be part of the set fastlane actions?

[dipree]

@ddralves sorry for the delay. We've discussed it briefly with @KrauseFx. Actions are legacy and there won't be new ones, that's what plugins are for.

[KrauseFx]

I don't have a say in this any more, but if there is high demand here, and Microsoft will keep supporting the built-in action by submitting PRs to fastlane/fastlane if they change their API, I believe it would be fine to migrate to the main fastlane code base.

cc @joshdholtz

[joshdholtz]

I used hockey all the time so its replacement not being in the core fastlane of actions does make the setup for new projects a bit more work. I'm not opposed to moving this into fastlane if provides a better experience for our fastlane users.

The benefit of having this owned by Microsoft is that they can make changes faster to this plugin as they are aware of them a head of time.

⚠️ this is a brand new thought ⚠️
There could potentially be a hybrid approach here where fastlane might be able to do a runtime lookup/install of plugins where:

1. if an action isn't found
2. if its a known plugin

I have no idea if this would work or how nice this approach would be but it could allow users to still have the "native fastlane action" feel and have Microsoft still maintain without the need to have the user know/install the plugin manually 😇 Thoughts?

[dipree]

Thanks @KrauseFx

@joshdholtz I like the idea. If this is something which you can make happen, we'd be happy about it 😊. If not we can still consider moving the plugin functionality to the core. Please let us know when you've decided about that idea. Thanks!

[ddralves]

Hi @derpixeldan , @joshdholtz and @KrauseFx

Firstly, thank you all for your thorough response.

My thoughts are similar to @joshdholtz 's as the benefit of actions is that they are always available whereas plugins have to be manually added/installed. Where this really shines is when one uses build slaves for a CI like Jenkins. Typically for Android systems, one can setup a container and specify that the plugin be added/installed each time the container starts up but for iOS we are stuck using physical machines and this requires a somewhat manual setup process, e.g. If you add, upgrade or format a build slave you have to remember to install a set of plugins which you properly will only find out are missing once the pipeline kicks off. Unless there is a easy way to auto-install plugins that I am not aware of?

I was not aware that actions were legacy and that plugins were preferred, in fact I thought it was the other way around. Is there a reason for this?

[ddralves]

Please ignore my "auto-install" question, I should've read up on the docs first but I see there is this: https://docs.fastlane.tools/plugins/using-plugins/ where one can use fastlane install_plugins

[joshdholtz]

@ddralves Plugins are preferred as they can be updated and maintained outside of the fastlane release cycles and also be maintained by developers that are experts of those plugins 😊 It always faster iterations for the plugins and also doesn't require approval of the fastlane maintainers for pull requests for new actions and updates to existing actions 👌

[ddralves]

@ddralves Plugins are preferred as they can be updated and maintained outside of the fastlane release cycles and also be maintained by developers that are experts of those plugins 😊 It always faster iterations for the plugins and also doesn't require approval of the fastlane maintainers for pull requests for new actions and updates to existing actions 👌

Thanks for the explanation, greatly appreciate it! Lets see what is decided with Microsoft for AppCenter

[ddralves]

fastlane/fastlane@9a4fd03

[joshdholtz]

Hey, all 👋 I just opened up fastlane/fastlane#15203 which will allow plugins to be used from Fastlane.swift now. I don't think this issue was specifically meant for Fastlane.swift concerns but one of the benefits before of moving this plugin to an action was because of the Fastlane.swift users not being able to use plugins. This should no longer be a concern now 😇

So all fastlane users (Ruby and Swift) will now be able to migrate over from hockey action to app center plugin 🚀

[ddralves]

Hey, all 👋 I just opened up fastlane/fastlane#15203 which will allow plugins to be used from Fastlane.swift now. I don't think this issue was specifically meant for Fastlane.swift concerns but one of the benefits before of moving this plugin to an action was because of the Fastlane.swift users not being able to use plugins. This should no longer be a concern now 😇

So all fastlane users (Ruby and Swift) will now be able to migrate over from hockey action to app center plugin 🚀

Thanks very much @joshdholtz

[joshdholtz]

@ddralves No problem at all! Let me know if there is anything else you need 😊