#questions/roadblocks with shorebird patch with multiple platforms

1 messages · Page 1 of 1 (latest)

paper fiber
#

Like a lot of other people, we definitely want to use the same patch number when the same code is applied to different platforms. I saw that a —-platforms flag was added to the shorebird patch command, but I’m running into a few issues that I’d love any insight on if possible.

#
  1. the shorebird_patch command from the shorebird fastlane plugin that I was trying to use does not seem to support multiple platforms even though the underlying shorebird patch does. I can file an issue about this if useful but wasn't sure if I'm just missing the correct way to pass them.
#
  1. When I try shorebird patch -—platforms directly instead, I can’t seem to include any iOS- or platform-specific args like —no-codesign. Since I ran shorebird release with —no-codesign for example, I get `✗ Failed to build: [ +7 ms] Could not find an option named "no-codesign”. If I omit these iOS-specific parameters that I used to run the release command, my iOS patch fails just like this other user's recent report: #1330965648653680721 message so it does seem that the args are necessary, plus using these args is suggested in other messages from the Shorebird team like this one #1264236145282383893 message .
#
  1. assuming i do get this working, would shorebird patch —-platforms be building each platform serially under the hood? Since my flutter builds can take a hefty amount of time, I release all my platforms in parallel GitHub Actions workflows, which worked fine with the switch to shorebird release because I’m able to programmatically give each platform the same correct version to use. Since patching is even more likely to be time-sensitive, it would be great to be able to reduce the time it takes to have patches out in the wild for all platforms. I’m guessing there is no way planned to be able to store or pass a patch number to the command, or be able to parallelize the shorebird patch command across GitHub Actions in some other way? I do understand the difficulties since patches can be against any release and behave quite differently from a fixed version number that can be stored in the repo, but I just wanted to see if there are any workarounds here I’m not thinking of. I had initially implemented each platform in its own parallel job, which worked well in terms of minimizing time to patch, but then realized that shorebird was assigning a different patch number to each, which is how I got here.
azure palm
#
  1. You're correct that this is not supported. We certainly could add that support.
  2. This makes sense, as we just forward args to the flutter tool, and iOS args are not always the same as Android args. Providing multiple platforms just runs patch commands in series, so you might just want to run the patch commands for each platform separately.
  3. Yes, it does build them in series. As mentioned earlier, you're probably better off creating your patches as separate shorebird patch invocations for each platform.

I’m guessing there is no way planned to be able to store or pass a patch number to the command
This is correct, you cannot number your own patches

Even using the --platforms arg, patches for different platforms will receive different numbers. We could maybe change this, but we have thus far assumed that each patch will map to a single platform.

plain knoll
#

Thank you for the feedback!

paper fiber
#

for #2 maybe it'd be useful to add a doc note that --platforms can't be used if you are using any platform-specific flags

#

if i want to implement code using shorebird_code_push that forces an update of all the platforms to a certain commit, how could i accomplish that if each platform produces a different patch number? it seems like from the suggested dev workflow the commit tag would then not have a relationship with theh patch numbers (or it would only match the patch number of the first platform), so do i have to somehow store my own mapping of patch numbers to commits or tags?

azure palm
#

What do you need to do with the patch numbers?

#

Maybe I'm not totally understanding your workflow

paper fiber
#

in certain cases, force an update if the client is below that patch number (so block the interface, not just wait for the double restart from auto-update)

#

just like you might do with a release version that is associated with a particular commit

azure palm
#

I think that would work the same as if the patch numbers were the same for each platform

#

Say you patch ios and android, that produces patches 3 and 4

paper fiber
#

how would i know what the patch number is programmatically?

azure palm
#

your app logic would say "if the patch is less than 3, update"

paper fiber
#

it suggests tagging e.g. 1.0.0+12345-hotfix.1 for patch 1

#

but that would actually trigger patch 1, 2, and 3 if you had 3 platforms

azure palm
#

Sure

paper fiber
#

so you can't tell what commit produced what patch

azure palm
#

You can tag the same commit with multiple tags

paper fiber
#

true, but the workflow is suggesting that you tag first and that this kicks off the patch workflows

#

so your suggestion would be to then you tag after the workflows complete

azure palm
#

Sure, that workflow doesn't sound like a great fit for your use case

#

But say you did tag with 1.0.0+12345-hotfix.1

#

It looks like that would still kick off a release

paper fiber
#

yeah it might not be! i'm just trying to figure out how i could accomplish what i'd need

azure palm
#

And you'd have patches 1, 2, and 3 associated with that commit

#

Let's maybe start with that—what is it you're trying to accomplish?

#

As I understand, you want a way to automate releasing to multiple platforms

#

You had previously been doing this in parallel, which I think is still the right approach

#

shorebird patch --platforms just patches the provided platforms in series, so you don't save any time by using that instead of shorebird patch ios followed by shorebird patch android, etc

#

How did you start this before shorebird?

paper fiber
#

yeah i realize that now about series vs parallel -- i had only switched because i thought the closed issue had also changed the behavior to use the same patch number

#

let me try to explain in better detail

#

i was able to implement both shorebird release and shorebird patch ok in my workflows, but the main thing that i'm trying to figure out now is the patch number piece (my mental model was that the same patch number matches to a commit since it reflects the same code, but i see now that's not the case). in our flutter app now, we have a way to block the interface to ask the user to update to a later release version based on an external config that has a minVersion concept (similar to what's being suggested here https://docs.shorebird.dev/update-strategies/#triggering-updates-via-notification except just for the versions distributed in the app/play store of course, because this was pre-shorebird)

Shorebird
Update Strategies

Ways to use Shorebird to update your app

#

i was hoping to add to that something like minPatchNumber so that if needed we can do a forced update without waiting for auto-update

#

so let's say i commit a hot fix in commit A, i had hoped to be able to easily apply the code in A to all platforms with one patch number. but since for now it's multiple patch numbers, i get that there will be patch 1, 2, and 3 and I could use number 3 as my min shorebird patch number, but i'm not clear on how i could tell that patch 3 is for commit A without maintaining my own mapping somewhere (like you said, maybe i would need to do some extra tagging after shorebird patch completes or something else)?

#

even if i couldn't do it programmatically, i'm not sure how to tell in the console that different patches are generated from the same commit or what commit they are from, so i guess the idea is that i have to maintain whatever mapping i need at the time of doing the patch on my own?

azure palm
#

i'm not clear on how i could tell that patch 3 is for commit A without maintaining my own mapping somewhere
I think this is correct, although I'm still a bit unclear why that's necessary other than bookkeeping?

#

We have an open issue somewhere to add support for "patch notes", which I think might help you here

paper fiber
#

ah ok, thank you. yes it's possible my mental model is just wrong and i'm not understanding how it should work, or shorebird might not be a fit for us. appreciate the help!

paper fiber
#

what i was hoping to do was have a force-update config file that is conceptually like this:

{
“minVersion”: "1.0.0+1234",
“minShorebirdPatch”: 3
}```

but i think based on how shorebird works I would actually need to store something that is platform-specific like this:
```{
minShorebirdPatch: {
    iOS: 1
    Android: 2
    MacOS: 3
}
} ```
I think maybe the root is that I would like to think of the patch as a bit of code that has an ID of sorts and is the same across platforms, and for development purposes it is very useful to think of the patch as more similar to the release version in that it represents a snapshot of code, and we want to be able to tell the client to require a minimum patch. However, I get now that Shorebird’s concept of a patch is quite different so it’s actually more of an app ID x platform X code combination.
#

i also want to be able to come back after the fact and update my config with the right patch numbers (since i don't want to do an interface-blocking forced update after EVERY patch, just a few when necessary), but there is no way of knowing the right patch number for the commit except immediately after the patch command so that's why i would have to store a lot to be able to back into the right patch number for app ID + flavor + platform + commit.

azure palm
#

If you're cutting all three at the same time, you could just use the least of the three for min

#

eg, this

{
minShorebirdPatch: {
    iOS: 1
    Android: 2
    MacOS: 3
}
}

Could be

{
“minVersion”: "1.0.0+1234",
“minShorebirdPatch”: 1
}
paper fiber
#

but if i'm building in parallel, it requires doing some extra work because if i just try to increment it as each build happens, i can't because if patch 3 happened first, the other platforms would be blocking the interface without actually having a patch available yet

#

i would have to save the first patch number for the patch tag within the workflow of the first patch and try to wait till all of them are complete before updating my config

azure palm
#

Right, you'd need to wait for all builds to finish

#

But that would be the case if you were using a single patch number as well

paper fiber
#

yeah it's just that i don't know what the number is before it finishes and which one is going to finish first

#

so i have to save them all and compare

#

and if i don't save it within the workflow i can't ever back into it again

azure palm
#

You can see them in the console

paper fiber
#

i can't tell which ones are grouped together

azure palm
#

If you're patching all platforms at once, won't it be every three?

#

e.g., 1-3, 4-6, 7-9, etc.?

paper fiber
#

i think theoretically! but i guess we've just had so much experience with intermittent workflow issues every once in a while that it doesn't seem ideal to have to guess (and we would be able to get that min patch number programmatically without having to guess from the console because we have a workflow for updating that config). but thank you for all the help and suggestions! it does seem like it's doable but there might be some items in your pipeline that would help us work with our workflow a bit more cleanly, so i will keep an eye out for those. great job to all of you on shorebird -- it's very impressive.

azure palm
#

That's fair

#

I think, for the time being, you'll probably need to manage the mapping manually

#

But yeah, I think some kind of patch notes would be useful here