Add tag-triggered release workflow

[kirich1409]

Summary

• Add .github/workflows/release.yml — push a v* tag to trigger: version validation, quality checks, Maven Central publishing, and GitHub Release with AAR artifacts
• Update vbpdpublish.gradle.kts to support ORG_GRADLE_PROJECT_* env vars for CI (with local.properties fallback for local dev)
• Remove outdated jitpack.yml (JitPack not used, was stuck on JDK 11)
• Add Maven Central, CI status, and License badges to README

Required GitHub Secrets

Before first use, configure these repository secrets:

Secret	Purpose
SIGNING_KEY_ID	GPG key ID
SIGNING_KEY	Base64-encoded GPG private key
SIGNING_PASSWORD	GPG key passphrase
MAVEN_CENTRAL_USERNAME	Sonatype Central Portal username
MAVEN_CENTRAL_PASSWORD	Sonatype Central Portal token

How to release

git tag v2.0.5
git push origin v2.0.5

Test plan

• Verify ./gradlew clean check passes
• Verify ./gradlew publishToMavenLocal still works with local.properties
• Configure GitHub Secrets and test with a real tag push

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This pull request adds automated release infrastructure to enable tag-triggered releases to Maven Central and GitHub Releases. The changes replace manual local publishing with a fully automated CI/CD pipeline.

Changes:

• Added GitHub Actions workflow for tag-triggered releases with version validation, quality checks, and automated publishing to Maven Central
• Updated publishing configuration to support both CI environment variables and local development via local.properties
• Removed outdated JitPack configuration
• Enhanced README with Maven Central, CI status, and license badges
• Added comprehensive design documentation for the release workflow

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
.github/workflows/release.yml	Tag-triggered workflow that validates versions, runs checks, publishes to Maven Central, and creates GitHub Releases with AAR artifacts
gradle/convetions-plugins/vbpd-library-base/src/main/kotlin/vbpdpublish.gradle.kts	Refactored to support both CI environment variables (with ORG_GRADLE_PROJECT_ prefix) and local.properties for credential management
jitpack.yml	Removed outdated JitPack configuration (was pinned to JDK 11)
README.md	Added badges for Maven Central version, build status, and license
docs/plans/2026-02-14-release-workflow-design.md	Comprehensive design document explaining the release automation strategy, credentials, and design decisions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

If the Maven Central publish succeeds but the GitHub Release creation fails, artifacts will be published to Maven Central without a corresponding GitHub Release. This could create confusion. Consider either: (1) creating the GitHub Release first with the release notes, then publishing to Maven Central, or (2) adding a note in the workflow that explains this potential state, or (3) using a workflow that can rollback the Maven Central publish if the release creation fails (though this may not be possible with Maven Central).

[Copilot]

The version extraction using grep and sed is fragile and could fail if there are spaces or formatting variations in the TOML file. Consider using a more robust TOML parser or checking if the grep command succeeded before using the result. For example, add validation that TOML_VERSION is not empty before the comparison.

Suggested change

	TOML_VERSION=$(grep '^vbpd = ' gradle/libs.versions.toml | sed 's/vbpd = "\(.*\)"/\1/')
	TOML_VERSION=$(grep -E '^[[:space:]]*vbpd[[:space:]]*=' gradle/libs.versions.toml | sed -E 's/^[[:space:]]*vbpd[[:space:]]*=[[:space:]]*"(.*)"/\1/')
	if [ -z "$TOML_VERSION" ]; then
	echo "::error::Failed to extract vbpd version from gradle/libs.versions.toml"
	exit 1
	fi

[Copilot]

The workflow doesn't verify that the AAR files were successfully built before attempting to upload them. If the build step fails silently or the file paths are incorrect, the GitHub Release creation could fail or upload incomplete artifacts. Consider adding a validation step to check that all expected AAR files exist before the release creation step.

[Copilot]

The AAR files are being built twice: once during the Maven Central publish step and again in this step. This is inefficient and wastes CI time. Consider reusing the AAR artifacts from the publish step or combining these steps to avoid redundant builds.

Suggested change

	- name: Build release AARs
	run: ./gradlew :vbpd-core:assembleRelease :vbpd:assembleRelease :vbpd-reflection:assembleRelease --no-configuration-cache