Some checks failed
CI / test (push) Has been cancelled
- Introduced Gradle tasks for release preparation, version bumping, and git tagging. - Added CI workflow for continuous integration on pushes and pull requests. - Implemented release workflow for automated builds and Gitea releases upon tag pushes. - Created scripts for manual release processes on Windows and Linux/macOS. - Documented the release process and Gitea Actions setup in the new RELEASE.md and setup-gitea-actions.md files.
4.5 KiB
4.5 KiB
Setting up Gitea Actions for PlayHours
This guide will help you configure Gitea Actions for automated releases on your self-hosted Gitea instance.
Prerequisites
- Self-hosted Gitea instance with Actions enabled
- Repository with proper permissions
- Git repository with the PlayHours project
Step 1: Enable Actions in Gitea
- Check Gitea version: Ensure you're running Gitea 1.19+ (Actions support)
- Enable Actions globally (if you're the admin):
- Go to Site Administration → Actions
- Enable "Enable Actions"
- Enable Actions for your repository:
- Go to your repository settings
- Under "Features", enable "Actions"
Step 2: Configure Repository Secrets
- Go to repository settings → Secrets
- Add the following secrets (if needed):
Required Secrets
GITEA_TOKEN: Your Gitea API token (for Gitea API access)GITEA_API_URL: Your Gitea instance URL (optional, defaults to current instance)
Creating API Tokens
For Gitea Token:
- Go to your Gitea profile → Settings → Applications
- Generate new token with
reposcope - Copy the token and add it as
GITEA_TOKENsecret
For Custom Gitea Instance (optional):
- Go to repository settings → Secrets
- Add
GITEA_API_URLwith your instance URL (e.g.,https://your-gitea.com)
Step 3: Verify Workflow Files
Ensure these files exist in your repository:
.gitea/workflows/ci.yml.gitea/workflows/release.yml
Step 4: Test the Setup
Test CI Workflow
- Make a small change to your code
- Commit and push to main branch
- Check Actions tab - you should see a CI workflow running
Test Release Workflow
- Create a test tag:
git tag -a v1.0.0-test -m "Test release" git push origin v1.0.0-test - Check Actions tab - you should see a release workflow running
- Check Releases - a new release should be created
Step 5: Configure Runner (if needed)
If you don't have runners available, you may need to set up self-hosted runners:
Using Docker Runner
-
Install act (local Actions runner):
# On Linux/macOS curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash # On Windows (with Chocolatey) choco install act-cli -
Test locally:
act -l # List available workflows act push # Run push workflow
Using Self-Hosted Runner
- Download runner from your Gitea instance
- Configure and register the runner
- Start the runner service
Troubleshooting
Common Issues
-
Actions not showing up:
- Check if Actions are enabled in repository settings
- Verify Gitea version supports Actions
-
Workflow fails to run:
- Check runner availability
- Verify workflow syntax
- Check secrets configuration
-
Build fails:
- Verify Java 17 is available
- Check Gradle wrapper permissions
- Review build logs for specific errors
-
Release creation fails:
- Verify API tokens have correct permissions
- Check if release already exists
- Review Gitea API rate limits
Debug Steps
-
Check Actions logs:
- Go to Actions tab in your repository
- Click on failed workflow
- Review step-by-step logs
-
Test locally:
# Test build ./gradlew clean build # Test with act act push -v -
Verify secrets:
- Check secret names match exactly
- Verify token permissions
- Test API access manually
Advanced Configuration
Custom Runner Labels
If using self-hosted runners, you can specify runner labels in workflows:
jobs:
build:
runs-on: [self-hosted, linux, java17]
Environment Variables
Add environment-specific variables:
env:
JAVA_VERSION: '17'
GRADLE_OPTS: '-Xmx2g'
Custom Gitea Instance Configuration
If your Gitea instance is not at the default URL:
env:
GITEA_API_URL: ${{ secrets.GITEA_API_URL }}
GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
Security Considerations
- Token Permissions: Use minimal required permissions for API tokens
- Secret Management: Never commit secrets to repository
- Runner Security: Secure self-hosted runners properly
- Access Control: Limit who can trigger releases
Monitoring and Maintenance
- Regular Updates: Keep Gitea and Actions up to date
- Log Monitoring: Check Actions logs for issues
- Token Rotation: Regularly rotate API tokens
- Runner Health: Monitor runner performance and availability