-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Remove Internal builds leftovers #23803
Conversation
Generated by 🚫 Danger |
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
@@ -1,4 +1,4 @@ | |||
#include "Version.internal.xcconfig" | |||
#include "Version.public.xcconfig" |
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 weren't really using the unique internal version xcconfig build number values once the release cycle builds were disabled in March. This change will just have the alpha/prototype builds use the release version number from the public file and will still continue to generate build numbers on-demand.
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.
Sounds good.
@@ -1,4 +1,4 @@ | |||
#include "Version.internal.xcconfig" | |||
#include "Version.public.xcconfig" |
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 weren't really using the unique internal version xcconfig build number values once the release cycle builds were disabled in March. This change will just have the debug builds use whatever the build number is in the public version file.
# Returns the build code of the app for the code freeze. It is the release version name plus sets the build number to 0 | ||
# | ||
def build_code_code_freeze | ||
# Read the current build code from the .xcconfig file and parse it into an AppVersion object | ||
# The AppVersion is used because WP/JPiOS uses the four part (1.2.3.4) build code format, so the version | ||
# calculator can be used to calculate the next four-part version | ||
release_version_current = VERSION_FORMATTER.parse(INTERNAL_VERSION_FILE.read_release_version) | ||
release_version_current = VERSION_FORMATTER.parse(PUBLIC_VERSION_FILE.read_release_version) |
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'm not sure why this was ever using the internal version file instead of the public one. So this change won't affect anything. The release version (e.g. 24.4) was the same between the public and internal files, anyway.
@@ -359,7 +359,7 @@ def build_and_upload_prototype_build(scheme:, output_app_name:, appcenter_app_na | |||
configuration = 'Release-Alpha' | |||
|
|||
# Get the current build version, and update it if needed | |||
version_config_path = File.join(PROJECT_ROOT_FOLDER, 'config', 'Version.internal.xcconfig') | |||
version_config_path = File.join(PROJECT_ROOT_FOLDER, 'config', 'Version.public.xcconfig') |
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.
Similar to the comments above, the public version file's release version (e.g. 24.4) is the same as the internal's, so this change won't affect anything. The build numbers were different between the public and internal, but for these prototype builds, their build numbers are generated on-demand anyway, superseding the existing build number.
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 think this should work, as long as the lane is import
ed instead of require
d (import
gives access to constants) after PUBLIC_VERSION_FILE
is defined
version_config_path = File.join(PROJECT_ROOT_FOLDER, 'config', 'Version.public.xcconfig') | |
version_config_path = PUBLIC_VERSION_FILE |
@@ -598,9 +570,8 @@ def prompt_for_confirmation(message:, bypass:) | |||
UI.confirm(message) | |||
end | |||
|
|||
def bump_build_codes | |||
def bump_build_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.
Updated this method name because only one build code is being updated now 🙂
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.
Looking good.
The usual caveat with any release-automation change is that issues are tricky to see and the only way to be sure nothing broke is to run the release. So here's a ping to @jkmassel to keep an eye out in the next release cycle and not hesitate to ping us.
Not approving yet because the prototype builds are failing to upload to App Center, which is odd because I cannot see any App Center change in this PR
https://buildkite.com/automattic/wordpress-ios/builds/24848#01934a52-447a-4a5c-9f65-fb1d5a26c023
[08:17:49]: Called from Fastfile at line 183
| [08:17:49]: ```
| [08:17:49]: 181: def execute_action(action_name)
| [08:17:49]: 182: print_group(action_name)
| [08:17:49]: => 183: super
| [08:17:49]: 184: end
| [08:17:49]: 185: end
| [08:17:49]: ```
| [08:17:49]: No URL provided to download or install the app.
| - Either use this action right after using `appcenter_upload` and provide an `app_center_org_name` (so that this action can use the link to the App Center build)
| - Or provide an explicit value for the `download_url` parameter
```
@@ -1,4 +1,4 @@ | |||
#include "Version.internal.xcconfig" | |||
#include "Version.public.xcconfig" |
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.
Sounds good.
@@ -359,7 +359,7 @@ def build_and_upload_prototype_build(scheme:, output_app_name:, appcenter_app_na | |||
configuration = 'Release-Alpha' | |||
|
|||
# Get the current build version, and update it if needed | |||
version_config_path = File.join(PROJECT_ROOT_FOLDER, 'config', 'Version.internal.xcconfig') | |||
version_config_path = File.join(PROJECT_ROOT_FOLDER, 'config', 'Version.public.xcconfig') |
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 think this should work, as long as the lane is import
ed instead of require
d (import
gives access to constants) after PUBLIC_VERSION_FILE
is defined
version_config_path = File.join(PROJECT_ROOT_FOLDER, 'config', 'Version.public.xcconfig') | |
version_config_path = PUBLIC_VERSION_FILE |
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.
Not approving yet because the prototype builds are failing to upload to App Center, which is odd because I cannot see any App Center change in this PR
https://buildkite.com/automattic/wordpress-ios/builds/24848#01934a52-447a-4a5c-9f65-fb1d5a26c023
Nevermind. The cause for that App Center failure was upstream in the automation. The actual App Center upload got a 429.
[08:15:54]: ------------------------------
| [08:15:54]: --- Step: appcenter_upload ---
| [08:15:54]: ------------------------------
| [08:15:55]: Starting release upload...
| [08:16:11]: Retryable error creating release upload 429: {"code"=>"too_many_requests", "message"=>"Error: Too many requests on Distribution/Releases"}
I retried them to see if it's related to the changes here or it was an HTTP fluke.
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 @mokagio! |
Summary
This PR removes the "Release-Internal" configuration and "WordPress Internal" scheme. Those were used for App Center builds that were uploaded during the release cycle. Those builds were disabled by @mokagio in March 2024. The prototype builds that are uploaded to App Center for each PR are still enabled (referred to as the Alpha configuration)--this is just for those release cycle builds.
Removes:
To test:
PR submission checklist:
RELEASE-NOTES.txt
if necessary.Testing checklist: