mirror of
https://github.com/opensourcepos/opensourcepos.git
synced 2026-10-28 19:18:58 -04:00
- release.yml:
- Normalize App.php, package.json, and package-lock.json to clean release version ($TARGET) prior to tagging, ensuring tagged commits contain clean release metadata in git history.
- Update release commit message to `chore(release): release <version>` to reflect that code, manifests, and templates are committed.
- Automate updating issue templates (bug report.yml and feature_request.yml) on release: prepends new release, retains top 5 versions, and preserves the fallback option.
- Automate updating supported versions in SECURITY.md (>= $TARGET and < $TARGET).
- Remove automated regex update of README.md: the intro sentence describes the v3.4 rewrite to CI4, so blindly regex-replacing the version on future releases produces misleading prose and is brittle against wording edits.
- Add concurrency group `release` and restrict workflow execution to master branch.
- Bump App.php, package.json, and package-lock.json to next dev snapshot ($NEXT) in post-release commit.
- build-release.yml:
- Remove redundant VERSION="${VERSION%-dev}" check and in-runner normalization step now that release commits are clean.
- Templates and Security Policy:
- Add OpenSourcePOS 3.4.3 to bug report.yml, feature_request.yml, and SECURITY.md.
- Add "- Older version (specify in description)" fallback option to issue templates.
- Remove default selection in bug report.yml so reporters specify version explicitly.
GitHub Actions
This document describes the CI/CD workflows for OSPOS.
Build and Release Workflow (.github/workflows/build-release.yml)
Build Process
- Setup PHP 8.2 with required extensions
- Setup Node.js 22
- Install composer dependencies
- Install npm dependencies
- Build frontend assets with Gulp
Docker Images
- Build and push
opensourceposDocker image for multiple architectures (linux/amd64, linux/arm64) - On
master: taggedmasterand<sha> - On other branches: tagged
<branch>-<sha> - On a semver tag (e.g.
3.4.2): tagged<version>andlatest - The version number is never stamped onto
master/branch builds — it only appears on tag releases - Pushed to Docker Hub
Releases
- Create distribution archives (tar.gz, zip)
- Create/update GitHub "unstable" release on master branch only
Required Secrets
To use this workflow, you need to add the following secrets to your repository:
- DOCKER_USERNAME - Docker Hub username for pushing images
- DOCKER_PASSWORD - Docker Hub password/token for pushing images
How to add secrets
- Go to your repository on GitHub
- Click Settings → Secrets and variables → Actions
- Click New repository secret
- Add
DOCKER_USERNAMEandDOCKER_PASSWORD
The GITHUB_TOKEN is automatically provided by GitHub Actions.
Workflow Triggers
- Push to master - Runs build, Docker push (
master+<sha>tags), and creates/updates theunstablerelease - Push to other branches - Runs build and Docker push (
<branch>-<sha>tag) - Push a semver tag (e.g.
3.4.2) - Runs build and Docker push (<version>+latesttags) - Pull requests - Runs build only (PHPUnit tests run in parallel via phpunit.yml); no Docker push
Existing Workflows
This repository also has these workflows:
.github/workflows/main.yml- PHP linting with PHP-CS-Fixer.github/workflows/phpunit.yml- PHPUnit tests (runs on all PHP versions 8.1-8.4).github/workflows/php-linter.yml- PHP linting
Testing
PHPUnit tests are run separately via .github/workflows/phpunit.yml on every push and pull request, testing against PHP 8.1, 8.2, 8.3, and 8.4.
To test the build workflow:
- Add the required secrets
- Push to master or create a PR
- Monitor the Actions tab in GitHub