-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[eas-build-job] add channel to Job #24
Conversation
In terms of adding this field, it's everything ok, but you are not doing anything with it, so the question is what it should do? If this is just a replacement for releaseChannel then you can just remove it and we will handle old reqests in API. If you are planning to add in the future other stuff than a channel for updates I would suggest wrapping that into sth else If you are planning to use this as a flag to switch between update services (old OTA vs EAS Update), then it's fine as long as it's a temporary solution and releaseChannel will be deprecated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adding this comment just to mark PR as reviewed :D
yes this is the situation, but classic updates will be supported indefinitely, even though there is going to be a very strong recommendation to use modern EAS Updates.
Good suggestion, wrapped. I left |
44dd2e6
to
7825f01
Compare
5dbca87
to
b038cb2
Compare
sorry, did pushed by accident, please don't re-review! 🙏 |
OK, so this is a bigger PR
I would suggest looking at It replaces The other change to note it that testingI added a bunch of unit tests and did a sequence of builds with different parameters on both iOS and android. I confirmed that classic updates still worked by publishing an update. eas updates needs the update URL to be changed as well, so I was not able to do and e2e test yet. I limited my testing of it to just checking the plist/manifest in the working directory after setting |
@@ -35,8 +35,7 @@ | |||
"node-forge": "^0.9.1", | |||
"nullthrows": "^1.1.1", | |||
"plist": "^3.0.1", | |||
"uuid": "^3.3.3", | |||
"xml2js": "^0.4.23" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I replaced the manual xml2js usage in packages/build-tools/src/android/releaseChannel.ts
with calls to methods in @expo/config-plugins.AndroidConfig.Manifest.*
in packages/build-tools/src/android/expoUpdates.ts
@@ -34,9 +34,7 @@ | |||
"fs-extra": "^9.0.0", | |||
"node-forge": "^0.9.1", | |||
"nullthrows": "^1.1.1", | |||
"plist": "^3.0.1", | |||
"uuid": "^3.3.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uuid wasn't being used.
switch (true) { | ||
case !!ctx.job.updates?.channel: { | ||
await configureEASExpoUpdatesAsync(ctx, platform); | ||
return; | ||
} | ||
default: { | ||
await configureClassicExpoUpdatesAsync(ctx, platform); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
switch (true) { | |
case !!ctx.job.updates?.channel: { | |
await configureEASExpoUpdatesAsync(ctx, platform); | |
return; | |
} | |
default: { | |
await configureClassicExpoUpdatesAsync(ctx, platform); | |
} | |
} | |
if (ctx.job.updates?.channel) { | |
await configureEASExpoUpdatesAsync(ctx, platform); | |
} else { | |
await configureClassicExpoUpdatesAsync(ctx, platform); | |
} |
or make the first condition based on the existence of updates
field instead, this way we can use the default channel without specifying it, it may be useful if we would switch default channel name in the fututre
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have the 'default' workflow figured out yet. It will likely be something like 'main' instead, but it will be subtly different than before and would prefer to hold off on making assumptions here till we have settled in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(changed to if/else)
await AndroidConfig.Manifest.writeAndroidManifestAsync(manifestPath, androidManifest); | ||
} | ||
|
||
export const androidSetReleaseChannelNativelyAsync = async ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
androidSetClasicChannelNativelyAsync
or androidSetLegacyChannelNativelyAsync
or sth simliair that mekes it more clear, distinction between realeasChannel
and channel
is often hard to spot.
When we switch to eas updates old key in eas.json will also have to be renamed this way to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export const androidSetReleaseChannelNativelyAsync = async ( | |
export async function androidSetReleaseChannelNativelyAsync( |
ctx: ManagedBuildContext<ManagedJob> | BuildContext<GenericJob>, | ||
platform: Platform | ||
): Promise<void> => { | ||
await setChannelNativelyAsync(ctx, platform); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about managed workflow? By default, eject will configure it for classic updates, what should be responsible for updating update url expo eject
or this code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The update URL is set dynamically in a bunch of different places.
I am planning on reworking the URL setting functions where they live.
It's likely going to be a complex PR and so I am planning on doing it in a follow up.
Once those are both landed it maybe worth considering a 3rd PR to move the code closer together, but I am not yet sure that makes sense so would prefer to wait till the first 2 have landed to decide.
* Channel (for Expo Updates when it is configured for for use with EAS) | ||
* It's undefined if the expo-updates package is not configured for use with EAS. | ||
*/ | ||
channel?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to add the new channel to build metadata, you should also update www and eas-cli.
See those two PRs if have a better understanding what needs to be done:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, I will consult these when I work on those PR's
Co-authored-by: Wojciech Kozyra <wojciech.kozyra@swmansion.com> Co-authored-by: Dominik Sokal <dominik.sokal@swmansion.com>
Why
In order to support the new EAS version of expo-udpates, we need to be able to set the
channel
of a build in the same way we set thereleaseChannel
for classic expo-updates.[edit]
A bit more context for posterity:
Q: "why can't we use releaseChannel for everything?"
A:
channel
to different Plist elements:releaseChannel https://github.com/expo/expo/blob/master/packages/expo-updates/ios/EXUpdates/EXUpdatesConfig.m#L29
channel is saved as a value in a requestHeaders object and then saved here: https://github.com/expo/expo/blob/master/packages/expo-updates/ios/EXUpdates/EXUpdatesConfig.m#L28
How
added
channel
where ever I sawreleaseChannel
.Put in an
oxor
that only allows "neither", "channel", or "releaseChannel" to be allowed.Test Plan
yarn test