How can I automate deployment to the App Store (not just build, or release)

Hello!

Problem

I'd like to publish an update to a watchface to the app store via the command line.

I've stumbled around the internet a bit searching for answers related to the above subject. I came across some related questions and scripts, but nothing seems to go as far as actually publishing to the app store without needing to manually go to the app store. I've even considered writing my own tool to help publish apps and watchfaces, but I stopped before investing too much time into it...

Potential solution thoughts

Whether such functionality would be included in the actual "monkey" branded CLI tools is not super important, as if there was just a separate endpoint we could `post` data to (https://apps.garmin.com/en-US/developer/{developerId}/apps/{appStoreId}/update), that would be great (the tricky part about using the previous URL in any script is that it isn't really meant to be automated, both from the form filling perspective, and from an authentication perspective).

My grand plan is/was to wrap up some functionality in an Azure DevOps task (and/or GitHub Action) so that I wouldn't have to go through the manual process of uploading a new version to the store.

Closing

I hope everyone's new year is off to a great start!

-Josh

  • I suspect that trying to automate this will take longer and be much more difficult than just doing it manually.  Updating the store is more than just uploading a new .iq, as you need to handle things like a new version number, adding text to "What's New", dealing with potential errors, etc.

  • Hey!

    I'm a little rusty with responding on forums, so please bear with me as I figure out a good format Sweat smile Also, if I type a lot, I blame it on the excessive amount of coffee I've had today.

    Upside down TLDR: I'm really looking for official support from Garmin for automation. All of the information you mentioned above could be kept in the manifest (again, would require official support from Garmin), or in a separate file that one would need to update whenever one makes changes to the code (similar to DevOps tasks in the Visual Studio Marketplace). This manifest could then just be parsed when passing an update to the store.

    Addressing "updating the store is more than just uploading a new .iq"

    Definitely true! However, there are already many solutions and techniques out there that address this. Furthermore, most of the information we need is present in the manifest, and if it isn't, then a different sort of manifest could be added (an official solution would be great though).

    To extrapolate on the updating process, as it stands today, it is actually two separate steps:

    1. Upload .iq file and add version number
    2. Optionally, update store listing (definitely should update store listing though)

    Now, as far as step 1 goes, the manifest already contains a spot for version. I would say that this could be used to populate the version number. Many stores and code packaging solutions use this technique, where the version number is actually set via the package/app manifest (NPM, NuGet, Visual Studio Marketplace, etc).

    Step 2 of course is slightly more complicated at this point in time, but only because the manifest does not contain fields for Description, What's New, the images, etc (Title is already in the manifest). Again, this information could be added to the manifest (for an official solution), or contained within a separate file that is stored alongside the source code itself. I currently perform the second option myself, albeit without the automation, where I have all of the store information kept within a json file so that I can clearly tie the store page to a specific version of my code.

    Why it is difficult today to hack a solution

    Automating this today is difficult because of two things:

    1. Garmin does not seem to officially support this, so there is no endpoint that accepts the required information in a nicely formatted way (nicely formatted, in my opinion, being JSON).
    2. One cannot easily hack together a solution due to how authentication currently works. If there was a different way to authenticate, maybe something similar to how Azure's Service Principles work, then one could hack together a solution that would allow for automation. I say hack because the solution would still rely on POSTing form data, instead of hitting some endpoint that accepts JSON/XML content in the request body.

    In the end

    I'm basically looking for a similar experience to a lot of other app stores that I interact with- Google's Play Store, Microsoft's Store, and the Visual Studio Marketplace (to name a few). I would argue that allowing for publishers to automate their releases is something any top-tier app store should strive to allow (that's more of a feature request for the Garmin folks :) )

    If you read this far, thanks for hanging in there,

    -Josh