Release pixel cleanup

[samsymons]

Task/Issue URL: https://app.asana.com/1/137249556945/task/1211470395820605?focus=true
Tech Design URL:
CC:

Description

This PR removes the old macOS and iOS release pixels, and replaces them with the new format.

⚠️ The branch that this is targeted add sends a pixel when the build is created, not pushed live, but the macOS pixel on this branch is sent when pushed live to users. This should be consolidated.

Testing Steps

1. Check that the release pixel format is correct

Impact and Risks

What could go wrong?

Quality Considerations

Notes to Reviewer

---

Internal references:

Definition of Done | Engineering Expectations | Tech Design Template

---

Note

Remove old release-annotation pixel action and iOS usage; switch macOS release workflow to send-pixel with new pixel name and stricter run condition.

• CI Workflows:
  • /.github/workflows/macos_publish_dmg_release.yml:
    • Replace send-release-annotation-pixel step with send-pixel using pixel-name: m_ci_apple_macos_release_version_${{ steps.verify-tag.outputs.release-version }}.
    • Add success() to the step condition; rename step to "Send Release Pixel".
  • /.github/workflows/ios_tag_release_update_asana.yml:
    • Remove the "Send release annotation pixel" step for iOS public/hotfix releases.
• Actions:
  • Delete /.github/actions/send-release-annotation-pixel/action.yml (legacy composite action).

^{Written by Cursor Bugbot for commit f777316. This will update automatically on new commits. Configure here.}

[cursor]

Bug: iOS Workflow Missing New Pixel Format

The iOS release workflow removes the pixel sending step without replacing it with the new format. This contradicts the PR description's intent to replace old pixel steps and creates an inconsistency with the macOS workflow, which was updated to use the new format.

.github/workflows/ios_tag_release_update_asana.yml#L233-L244

apple-browsers/.github/workflows/ios_tag_release_update_asana.yml

Lines 233 to 244 in f777316

	template_name:"${{ steps.asana-templates.outputs.release-task-comment-template }}"
	- name: Create Asana notification task
	if: github.event.inputs.release-type != null && github.event.inputs.release-type != 'internal'
	continue-on-error: true
	uses: ./.github/actions/send-release-notification-task
	with:
	platform: ios
	tag: ${{ env.TAG }}
	asana-project: ${{ vars.APPLE_DEPLOYMENTS_ASANA_PROJECT_ID }}
	asana-section: ${{ vars.APPLE_DEPLOYMENTS_SECTION_ID }}
	asana-access-token: ${{ secrets.ASANA_ACCESS_TOKEN }}

 

---

[bwaresiak]

What I wonder is if we want to have it for internals as well:
1/ we can have only for public
2/ we can have for all
3/ we can have two pixels, one for internal and one for public releases

I’m sort of leaning towards 3, as it gives us most flexibility around how to use these pixels, but it’s a bt more tricky to send (e.g. we’d have internal, that then gets promoted to public).

[samsymons]

Yeah good question. If we do want internal pixels (and we may as well), then I agree option 3 is suitable. I think this will be doable by keeping this pixel as-is as the final release, but updating the other workflow file to send the internal pixel - let me take a go at that on Thursday.

[github-actions]

This PR has been inactive for more than 7 days and will be automatically closed 7 days from now.