Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

ci: automate release artifacts and store uploads after release PR merge

Open
  • Is something wrong?
#276 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
10/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
android, dart, flutter, github-actions, ios
Domain
ci-cd, mobile, release

Research direction

Start with pubspec.yaml, CHANGELOG.md, docs/AUDIT.md and android/app/build.gradle.kts, which define the version, release notes, audit entry and Android signing. Then read the existing CI workflows that run the tests and builds checks. Done means a merged release PR validates its metadata and publishes the Windows ZIP, Android AAB and iOS IPA with protected secrets, while ordinary merges touch no release secrets. Credential setup, rotation and rerun steps belong in docs/RELEASING.md.

Written by the indexing model from the issue text.

Description

enhancement P2-Medium

Goal

After a release PR merges into main, build distributable UNIUN artifacts, attach the Windows ZIP to a versioned GitHub Release, upload Android to Google Play, and upload iOS to TestFlight. The maintainer will review and submit the store updates for public release.

Release PR contract

  • A release PR updates pubspec.yaml (MAJOR.MINOR.PATCH+build), adds user-facing notes to CHANGELOG.md, and adds the release audit entry to docs/AUDIT.md without deleting earlier audit history.
  • Validate that the version is new, the build number exceeds the last store upload, and the changelog/audit entries match the version. Fail before any upload if validation fails.
  • Trigger publishing only for a merged release PR, not for ordinary merges, PR builds, or nightly builds. Require the tests and builds checks to pass before publishing.

Artifacts and uploads

  • Windows: build in Release mode on Windows, ZIP the complete runnable output directory, create tag v<version>, and attach the ZIP and checksums to a GitHub Release.
  • Android: build a Release AAB signed with the existing production upload key, then upload it to a configured Google Play track for maintainer review. Do not use the disposable key from PR build CI.
  • iOS: build and sign a Release IPA on macOS for both in.uniun.app and in.uniun.app.ShareExtension, then upload it to App Store Connect/TestFlight. The maintainer handles App Store submission after processing and review.
  • Fetch the real Git LFS model asset for distributable builds; the pointer-only checkout used by PR build CI must not be shipped.
  • Keep version, tag, release notes, and all three artifacts tied to the same merged commit. Make failed or partial uploads visible and safe to retry without silently incrementing or reusing a store build number.

Credentials and gates

  • Store the Android upload keystore/passwords, Google Play service account access, Apple Distribution certificate/profiles, and App Store Connect API key in protected GitHub environment secrets. Never write them to the repo or expose them in logs or PR jobs.
  • Limit Play permissions to the selected track. Confirm the target track before enabling upload; keep production rollout/manual submission with the maintainer.
  • Document credential setup, rotation, a manual rerun path, and what to do after a partial release in docs/RELEASING.md.
Google Play credentials
Needed How to get it
Existing Android upload keystore (.jks), alias, store password, and key password Use the upload key for the current Play listing; android/app/build.gradle.kts reads it through the gitignored android/key.properties. See docs/RELEASING.md.
Google Play service account JSON key In Google Cloud, enable the Google Play Developer API and create a service account. Invite its email in Play Console → Users and permissions with access to UNIUN, then create its JSON key for CI. Google setup guide.
Track permission Grant Release apps to testing tracks for a test track. Grant Release to production only if automated production submission is later chosen. Play permissions.
App Store / TestFlight credentials
Needed How to get it
App Store Connect API key (.p8), Key ID, and Issuer ID App Store Connect → Users and Access → Integrations → App Store Connect API → Team Keys → Generate. Use an App Manager role for managing the build. Download the .p8 once and store it securely. Apple API key guide.
Apple Distribution signing identity (.p12) and its password Export the existing distribution certificate with its private key from the Mac that holds it. Apple signing guidance.
Two App Store Connect provisioning profiles Create one for in.uniun.app and one for in.uniun.app.ShareExtension, matching the distribution certificate and configured capabilities. Download them from Apple Developer → Certificates, Identifiers & Profiles → Profiles. Apple profile guide.

Acceptance criteria

  • A non-release merge never accesses release secrets or uploads anything.
  • A release PR with failing checks or invalid version metadata cannot upload.
  • One merged release PR produces a working Windows ZIP/GitHub Release, a Play Console AAB ready for review, and an iOS build visible in TestFlight.
  • The maintainer can submit the store releases manually after checking the uploaded builds.
Dominant language
Dart
Stars
2
Forks
2
Avg merge
19h 21m
Merged PRs (30d)
37

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from basictech01/uniun

All issues in basictech01/uniun

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.