Skip to content

Conversation

@fadi-george
Copy link
Contributor

@fadi-george fadi-george commented Dec 4, 2025

Description

One Line Summary

  • call shared sdk action to create release prs in wrapper sdks for new android sdk version

Details

  • updates publish workflow action to call shared sdk action

See example runs:
Action: https://github.com/OneSignal/OneSignal-Android-SDK/actions/runs/19942895432
RN: OneSignal/react-native-onesignal#1865
Flutter: OneSignal/OneSignal-Flutter-SDK#1088
Cordova: OneSignal/OneSignal-Cordova-SDK#1128
Unity: OneSignal/OneSignal-Unity-SDK#828

Motivation

  • want to make automate creation of release prs when theres a new native sdk ipdate

Scope

  • only affects workflows

Affected code checklist

  • Notifications
    • Display
    • Open
    • Push Processing
    • Confirm Deliveries
  • Outcomes
  • Sessions
  • In-App Messaging
  • REST API requests
  • Public API changes

Checklist

Overview

  • I have filled out all REQUIRED sections above
  • PR does one thing
    • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
  • Any Public API changes are explained in the PR details and conform to existing APIs

Testing

  • I have included test coverage for these changes, or explained why they are not needed
  • All automated tests pass, or I explained why that is not possible
  • I have personally tested this on my device, or explained why that is not possible

Final pass

  • Code is as readable as possible.
    • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
  • I have reviewed this PR myself, ensuring it meets each checklist item
    • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

This change is Reviewable

@abdulraqeeb33
Copy link
Contributor

hey @fadi-george , i remember we discussed about this, just making sure we are still on the same page.
native gets feature update - then we should not create wrappers as there needs to be some work to be done in the wrappers, instead it should go ahead and create tickets.
native gets patch/fixes - then we should automatically create wrappers

@abdulraqeeb33
Copy link
Contributor

hey @fadi-george , i remember we discussed about this, just making sure we are still on the same page. native gets feature update - then we should not create wrappers as there needs to be some work to be done in the wrappers, instead it should go ahead and create tickets. native gets patch/fixes - then we should automatically create wrappers

Based on the discussion with @fadi-george .

Apparently we have decided to create PRs for both the cases - features and patch fixes. And we will just look at the PR, clean up the release notes and create a version out of it. Note: There is a possibility that the developer may miss clean up the PR notes to not include the feature. And the version will also be out of sync with native.

@fadi-george fadi-george merged commit af428f1 into main Dec 4, 2025
1 check passed
@fadi-george fadi-george deleted the fg/wrapper-prs branch December 4, 2025 22:38
jinliu9508 pushed a commit that referenced this pull request Jan 6, 2026
ci: create release prs for wrappers for new android sdk release
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants