chippyash / semantic-version-updater
Utility to update version tags during Jenkins builds
Requires
- php: >=8.0
- symfony/console: 5.2.8
Requires (Dev)
- phpunit/phpunit: ^9.5
- symfony/process: ^5.2
README
Build chain utility to update the semantic version for a PHP package
PHP Version support
With the inexorable withdrawal of upstream library support for PHP<V8, I've now also decided to remove support for <V8. If you still need <V8 support use a tagged version <1 and build the package yourself. V1+ is PHP8 only.
Quality Assurance
The above badges represent the current development branch. As a rule, I don't push to GitHub unless tests, coverage and usability are acceptable. This may not be true for short periods of time; on holiday, need code for some other downstream project etc. If you need stable code, use a tagged version.
See the Test Contract
How
Initialisation
For a new package
add "chippyash/semantic-version-updater":"*"
to your dev-requires section of the composer.json file
run composer update
run vendor/bin/vupdate init
to create a new VERSION file in the root of your project
run
git commit -am"add vupdate" git tag 0.0.0 git push origin master --tags
Manually updating the version and git tag
During initial development, you'll want to have your package tagged at various points. You can keep your git tag version and the version contained in the VERSION file in sync with
bin/vupdate && cat VERSION | xargs git tag
Don't forget to push your tags to remote repo.
Once you have finished initial development and you think you are good to go,
you can tag you package at its first 'real' release version. You can
either run bin/vupdate -pbcbreak
to update the major (M.n.n) part of
the version number, or bin/vupdate -o 1.0.0
to force the version. A one liner would be
bin/vupdate -pbcbreak && cat VERSION | xargs git tag && git commit -am"First release" && git push origin master --tags
Use bin/vupdate -h
to see the help screen.
Use bin/vupdate --version
for command version number.
Employing into your build chain
The real purpose of the utility is to get it used in the build chain, updating the tag, pushing to git and then updating the Satis/Composer (or other repo) to tell it that a new version is available.
Download this repo as a zip and extract it. Move/copy the bin/vupdate file to somewhere on your PATH, e.g. /usr/local/bin/vupdate. You can also do this if you just want the executable phar on your local machine to be globally available.
Here is a jenkins job that we use in our build chain to update the version dependent on the branch name prefix:
VERSIONER=/usr/local/bin/vupdate GIT=git cd "${workingDir}"; ${GIT} checkout ${gitBranch}; lastCommit=$(git log --branches | grep 'Merge pull request.* to master' | head -1) if [[ $lastCommit == *"feature/"* ]] || [[ $lastCommit == *"release/"* ]] then ${VERSIONER} -p feature; verType="Feature"; else ${VERSIONER}; verType="Patch"; fi; ${GIT} commit -am"CD $verType Version update: $lastCommit"; cat VERSION | xargs ${GIT} tag; ${GIT} push origin ${gitBranch} --tags;
The $workingDir and $gitBranch parameters are sent to the job from the main build job. $gitBranch defaults to 'master';
Development
Clone the repo as normal.
Create a feature branch
run composer update
to pull in the external libraries.
Commit your changes as normal and push to repo and make a pull request.
The make file
Running make
will rebuild the bin/vupdate
phar file and push the changes to the repo.
As such, it is only of any use to you if you have write access on the code repo.
You can run make build
to just build the bin/vupdate
Notes
If you get creating archive "/var/lib/jenkins/jobs/ci-version-updater-builder/workspace/bin/vupdate.phar" disabled by the php.ini setting phar.readonly
or something similar when using the make build tools, edit your php cli
ini file and set phar.readonly = Off
.
Acknowledgments
I first wrote the vupdate.php script some years ago. At that time it relied on the
'herrera-io/version' package from Kevin Herrara. He's since abandoned that package, so
I've included his original code in the source of this package. It still works just fine.
You can find it in the 'src' directory, along with his original tests in the 'test'
directory. The Test Contract can be found at docs/Test-Contract.md
. He has
a permissive license on his code, so feel free to use this package
to get access to the original code if you need it in some other application.
The build routine managed by the Makefile relies on Box. There is a box phar distribution in the bin directory which will be used by the makefile.