feat: Create List Command

[mrgnhnt96]

Description

This PR adds a new command for shorebird_cli, shorebird list, which would print the releases uploaded to the console.

By getting the list of releases, we can see the latest version & build number and which platforms have been successfully uploaded.

This could help (me):

• Determine whether a previous job was successful for any particular platform.
• Keep the build numbers in sync across platforms

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore
• 🧪 Tests

[bryanoltman]

I don't disagree with this on principle, but what problem is this intended to solve? Releases can currently be viewed in the Shorebird console at https://console.shorebird.dev/apps/[app-id]

[felangel]

Thanks for the PR! Fwiw we previously had this functionality and deprecated and removed it since it was already available in the console:
#932

[StarProxima]

@felangel

Fwiw we previously had this functionality and deprecated and removed it since it was already available in the console:

But why was this functionality removed, even if similar functionality is available via console? Sometimes it can be convenient to do everything through cli, when the main actions (creating releases, patches) are also done through cli.

[eseidel]

@felangel

Fwiw we previously had this functionality and deprecated and removed it since it was already available in the console:

But why was this functionality removed, even if similar functionality is available via console? Sometimes it can be convenient to do everything through cli, when the main actions (creating releases, patches) are also done through cli.

I believe it was removed almost a year ago, when we first introduced the console (and probably had 10x or 100x fewer users). It's mostly just a question of complexity budget. Like all teams, we can also only maintain so many things, so whenever we have a chance to delete something, we do. :) We certainly could add it back (and that might be the right decision).

[mrgnhnt96]

What problem is this intended to solve?

TLDR; So we can sync our version & build numbers on our CI.

Here is a summary of our GHA

env:
  RELEASE_MODE: patch
  BUILD_NUMBER: 2 # retrieved from Play Console

steps:
  build-ios:
    run: |
      if (RELEASE_MODE == patch) {
        create_shorebird_patch
      } else {
        BUILD_NUMBER += 1
        create_shorebird_release
      }

  build-android:
    run: |
      if (RELEASE_MODE == patch) {
        create_shorebird_patch
      } else {
        BUILD_NUMBER += 1
        create_shorebird_release
      }

The issue we have is that iOS can detect a native change while Android doesn't (or visa-versa). Since these two jobs are independent, this could causes a patch to be uploaded for Android and a release for iOS. If nothing changes, iOS will fail on all following jobs because native changes will continue to be detected, which will cause a release to be built, but cannot be uploaded because a release already exists for that version + build number. iOS won't be successful again unless Android detects a native change to create a new release, or we choose to create a new release.

We observed that iOS detects native changes more frequently. So we decided to have Android wait until iOS has successfully built and then mirror the RELEASE_MODE that ios-build emits. However, we could still run into the issue where Android detects a native change when iOS doesn't (during a patch attempt).

What we are looking for is a way to synchronize our build & version numbers between iOS and Android without depending on App Store Connect & Google Play Console. This PR would introduce a solution for us where we could retrieve the version & build numbers and determine which platforms successfully created a release.

[felangel]

If we agree that we would like to bring back this functionality (I'm not fully convinced 🤷), then I'd recommend just cherry-picking the previous functionality in order to be conscious of everyone's time and to maintain consistency. We already had this functionality and it would be fairly easy to reapply the changes without having to rewrite it from scratch (unless there's value in doing so).

[felangel]

What we are looking for is a way to synchronize our build & version numbers between iOS and Android without depending on App Store Connect & Google Play Console. This PR would introduce a solution for us where we could retrieve the version & build numbers and determine which platforms successfully created a release.

I'm not sure I understand why it's insufficient to use the result from the create release step to determine whether a release succeeded. You can also use shorebird release --platforms=ios,android to release to both platforms and if one fails, the whole process will exit with a non-zero status code. If the goal is to synchronize releases to platforms then I suspect we should improve our release process instead. Wdyt?

[mrgnhnt96]

What we are looking for is a way to synchronize our build & version numbers between iOS and Android without depending on App Store Connect & Google Play Console. This PR would introduce a solution for us where we could retrieve the version & build numbers and determine which platforms successfully created a release.

I'm not sure I understand why it's insufficient to use the result from the create release step to determine whether a release succeeded. You can also use shorebird release --platforms=ios,android to release to both platforms and if one fails, the whole process will exit with a non-zero status code. If the goal is to synchronize releases to platforms then I suspect we should improve our release process instead. Wdyt?

Its more about knowing the state of the previous releases/patches as opposed to the result in the current job.

Atm, we have separated steps to create the ios and android builds (in efforts to limit the use of mac minutes). So we would need to move everything to a mac runner to leverage shorebird release --platforms-ios,android, which isn't off the table, but it would be nice to avoid that.

Since we run the jobs separately, we don't have any visibility to the release success between android & ios. We could choose to have ios depend on android or visa versa, but then we still have the problem if the latter of the 2 jobs fails and how to react to that when the GHA gets triggered again.

[mrgnhnt96]

I'd recommend just cherry-picking the previous functionality in order to be conscious of everyone's time and to maintain consistency.

@felangel if you would like for me to do this, I'd be happy to!

[nateshmbhat]

waiting for this commandt o drop

[bryanoltman]

I'd recommend just cherry-picking the previous functionality in order to be conscious of everyone's time and to maintain consistency.

@felangel if you would like for me to do this, I'd be happy to!

I believe this would be preferred. Sorry for the confusion!