Merge release 2.34 into `trunk` #1695

mokagio · 2024-09-19T07:28:52Z

%%{init: { 'gitGraph': { 'mainBranchName': 'trunk', 'mainBranchOrder': 1000, 'showCommitLabel': false }}}%%
gitGraph
   branch release/2.34
   checkout release/2.34
   commit
   commit
   commit
   branch merge/release-2.34-into-trunk
   checkout merge/release-2.34-into-trunk
   commit
   checkout trunk
   commit
   commit
   merge merge/release-2.34-into-trunk

cc @Automattic/apps-infrastructure to have a look at the automation changes. Context paaHJt-6Zx-p2

#1693)

Base off woocommerce/woocommerce-android#12450

Clearly the change adding Simplenote Android has not been deployed yet.

`publish_release` does it for us now.

mokagio · 2024-09-19T07:29:27Z

fastlane/Fastfile

@@ -169,64 +169,6 @@ platform :android do
    trigger_release_build(branch_to_build: release_branch_name)
  end

-  desc 'Updates store metadata and runs the release checks'
-  lane :finalize_release do |skip_confirm: false|


Moved to release.rb

dangermattic · 2024-09-19T07:30:23Z

	1 Message
📖	This PR has the `Releases` label: some checks will be skipped.

Generated by 🚫 Danger

mokagio · 2024-09-19T07:30:25Z

fastlane/lanes/ci_releases.rb

-      environment: { RELEASE_VERSION: release_version }
-    )
-  end
-end


Deleted as discussed in Automattic/simplenote-ios#1655 (comment). See also wordpress-mobile/WordPress-iOS#23589

mokagio · 2024-09-19T07:34:19Z

fastlane/lanes/release.rb

-    base: base_branch,
-    labels: 'Releases'
-  )
+def create_backmerge_pr!


What do you think of what I did here?

create_backmerge_pr! does exactly what is says, returns the URL of the PR or crashes if something went wrong. This allows callers to declare they expect a single backmerge PR, like in this repo for a code freeze or a release finalization.

create_backmerge_prs! below allows for more backmerge PRs, like when we finalize a hotfix. It also has the ! suffix because if something goes wrong it will call UI.user_error!

I wrote a short comment about this in another PR but I guess it got lost amidst all PRs and discussions currently happening.

My main question is whether we can be sure the validation on create_backmerge_pr! is guaranteed to be semantically correct, meaning: I think there may be cases when a previous release might take a bit longer or there is a hotfix in progress, then you "unexpectedly" will have a backmerge.

I see... 🤔

So, for example if finalize_code_freeze for 1.2 runs when 1.1 hasn't landed yet? Or if we are code freezing 1.2 while 1.1.1 is still in progress?

I'm tempted to say that 1) that should not happen because one should not run a code freeze before having finalized the previous release and 2) the action should only create backmerges in branches that are from later releases (e.g. 1.2.1 or 1.3). That to me suggests that if we have more than one backmerge then something went wrong and we should abort.

Having said that... Maybe it's best to be flexible (and account for me not being able to predict every future possible case in which this action should run) and let release manager deal with multiple backmerge PRs when only one should be there.

In fact, now that I think about it, the release manager would have to deal with them anyway because the failure implemented here is after the PRs have been created.

Here's what I might do:

Remove the create_backmerge_pr!

Move the logic to print to STDOUT annotate CI into create_backmerge_prs! (I am keen on keeping the plural form to make it clear at call site that more than one might be opened)

Add a warn_on_multiple_prs_opened: false parameter that lanes such as finalize_code_freeze can use to change the STDOUT and CI annotation to include a warning if more than one backmerge was create

What do you think @iangmaia ?

Actually @iangmaia sorry I'm going to merge this before you have a chance to reply to this because I had to make a few more changes to the release branch and will need to submit a new build. As such, it's convenient to have this PR on trunk before the publish_release task will open a new integration PR (because of the new changes).

So, for example if finalize_code_freeze for 1.2 runs when 1.1 hasn't landed yet? Or if we are code freezing 1.2 while 1.1.1 is still in progress?

Yeah, in that case the PR would be created from 1.1.1 to 1.2 on finalize_hotfix, but I guess it's just a matter of using the plural method in this case.

In fact, now that I think about it, the release manager would have to deal with them anyway because the failure implemented here is after the PRs have been created.

Makes sense to me 👍 I'm still a bit on the fence on what's best to do but annotating a warning sounds like a good compromise.

sorry I'm going to merge this before you have a chance to reply to this because I had to make a few more changes to the release branch and will need to submit a new build

No worries!

A minor followup:

Move the logic to print to STDOUT annotate CI into create_backmerge_prs! (I am keen on keeping the plural form to make it clear at call site that more than one might be opened)

I run into the case of using create_backmerge_pr expecting it to return a single URL in this Simplenote iOS build (all my own doing). There result was a buggy UX where the link to the PR in the build annotation didn't work. The reason? The markup had an array in the URL with got rendered as empty:

Following up via #1698

wpmobilebot · 2024-09-19T07:34:26Z

📲 You can test the changes from this Pull Request in Simplenote Android by scanning the QR code below to install the corresponding build.

	App Name	Simplenote Android
	Build Type	Debug
	Commit	`1030049`
	Direct Download	`simplenote-android-prototype-build-pr1695-1030049-0192092f-3647-4718-ab28-2c2d10e96c08.apk`

mokagio · 2024-09-19T07:55:26Z

.buildkite/release-pipelines/finalize-release.yml

+      source use-bot-for-git wpmobilebot
+
+      echo '--- :git: Checkout Release Branch'
+      .buildkite/commands/checkout-release-branch.sh


I plan to followup with a dedicated PR that surfaces RELEASE_VERSION here and remove reading it from the environment in the script.

I think by doing that we might also make the script more portable and possibly move it to the CI plugin. Being such a simple script, I wonder what's the value, but then again, it would make the implementation, the error handling, and the messages it print consistent across project, which I think is desirable for us.

It would also make the implementation consistent with the recent changes accessing RELEASE_VERSION in the pipeline command that we made in some iOS projects.

mokagio · 2024-09-20T01:19:53Z

Admin merging as discussed above, #1695 (comment)

Andy Valdez and others added 15 commits September 11, 2024 15:31

Add message to allow user to login manually in the enter email screen.

77d2a03

Change using spans directly and use html.toHtml instead.

f1a36ae

Add message to allow user to login manually in the enter email screen. (

1c149f9

#1693)

Remove out-of-date parameter from download_metadata_strings call

aebb6a3

Remove ci_releases.rb – We decided not to track them

7d5fd2c

Move finalize_release to fastlane/lanes/release.rb

c38e3c6

Replace create_release_management_pull_request with new backmerge

ec7a563

Add publish_release lane

1a5436c

Base off woocommerce/woocommerce-android#12450

Add Buildkite pipelines to finalize and publish releases in CI

ffc4b50

Explicitly pass wpmobilebot to secure agent command

2f69029

Clearly the change adding Simplenote Android has not been deployed yet.

Update translations

c358ba1

Bump version name and build code

851e61f

Update metadata translations for 2.34

45a8201

Remove unnecessary version parameter

adc8fef

Do not remove branch protection in finalize_release

1030049

`publish_release` does it for us now.

mokagio commented Sep 19, 2024

View reviewed changes

mokagio added this to the 2.35 milestone Sep 19, 2024

mokagio added the Releases label Sep 19, 2024

mokagio requested a review from a team September 19, 2024 07:44

mokagio enabled auto-merge September 19, 2024 07:44

mokagio commented Sep 19, 2024

View reviewed changes

mokagio mentioned this pull request Sep 19, 2024

[Tooling] Automate Release Publishing wordpress-mobile/WordPress-Android#21239

Merged

mokagio disabled auto-merge September 20, 2024 01:15

mokagio merged commit f0c98fa into trunk Sep 20, 2024
19 checks passed

mokagio deleted the merge/release-2.34-into-trunk branch September 20, 2024 01:20

mokagio mentioned this pull request Sep 25, 2024

Extract create backmerge PR methods in helper files #1698

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge release 2.34 into `trunk` #1695

Merge release 2.34 into `trunk` #1695

mokagio commented Sep 19, 2024

mokagio Sep 19, 2024

dangermattic commented Sep 19, 2024 •

edited

Loading

mokagio Sep 19, 2024

mokagio Sep 19, 2024

iangmaia Sep 19, 2024

mokagio Sep 19, 2024

mokagio Sep 20, 2024

iangmaia Sep 20, 2024

mokagio Sep 23, 2024 •

edited

Loading

mokagio Sep 25, 2024

wpmobilebot commented Sep 19, 2024

mokagio Sep 19, 2024 •

edited

Loading

mokagio commented Sep 20, 2024

Merge release 2.34 into trunk #1695

Merge release 2.34 into trunk #1695

Conversation

mokagio commented Sep 19, 2024

Choose a reason for hiding this comment

dangermattic commented Sep 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mokagio Sep 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wpmobilebot commented Sep 19, 2024

mokagio Sep 19, 2024 • edited Loading

Choose a reason for hiding this comment

mokagio commented Sep 20, 2024

Merge release 2.34 into `trunk` #1695

Merge release 2.34 into `trunk` #1695

dangermattic commented Sep 19, 2024 •

edited

Loading

mokagio Sep 23, 2024 •

edited

Loading

mokagio Sep 19, 2024 •

edited

Loading