-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Merge final release/18.2 into develop #15344
Conversation
With Tempfile, we'd have to IO#flush + IO#rewind and/or IO#close to be sure that the file will be written to disk and read from start at the time create_release is called and uses IO.read to read it.
…d slack CI actions This is only in order to test the PR without adding noise.
This has been replaced by the public `trigger_release_build` lane, which makes use of the `circleci_trigger_job` action implemented in toolkit. The old `trigger_ci` lane was not used anywhere in the Fastfile anymore (and being a private lane, couldn't be invoked manually from CLI either), confirming it was not used anymore.
…-gh-release [Tooling] Create a Single, Unified GitHub Releases for WP Alpha, WP Beta & JP Beta
…p-toggle Add Weekly Roundup toggle to Notification settings
…elease_1.61.1 Integrate gutenberg-mobile release 1.61.1
Instead of doing nothing on the build step and letting the other job steps continue, ultimately failing on 'persist_to_workspace' step not finding 'build/' directory
You can test the changes on this Pull Request by downloading the APKs: |
@AliSoftware Any chance you could link the commit hashes for these changes so we could review them? This PR contains quite a lot of changes, so besides ensuring the version changes, I think the review will be minimal. (since all changes should be reviewed already) However, we wouldn't want to merge anything that's never reviewed, so it'd help to have the commit hashes that were never reviewed. I don't think this is necessary to do most of the time, mainly because the changes would be release finalization related, so if there is a small change in Also, I think it's best to do a merge PR against |
Sure thing!
That's a very good point, I should have merged |
else | ||
echo "Skipping and halting this job because we only build Zalpha variants for rc versions, but current version is ${APP_VERSION}" | ||
circleci-agent step halt |
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 needed to add that change because without it, this build step will be skipped as expected… but the rest of the job would continue, and ultimately fail on the persist_to_workspace
step later in that job, as the build/
directory would not exist. This is what happened in this CircleCI run.
So instead, this halts the job gracefully, and does not run the following steps after this one for the job, avoiding to try running the persist_to_worspace
one.
I didn't encounter this during my earlier tests when I did the intermediate betas because we only skip the Zalpha during the final release.
This final release also includes:
.circleci/config.yml
andfastlane/Fastfile
for edge cases I forgot to account for during my recent JP Infra work