Ben Goldsworthy
0a34e96450
This commit adds a release helper script, amongst other workflow improvements. See `README.md` for instructions, and `_tools/release.sh` for the script itself. This script: 1. sanity-checks the various version tags; 2. triggers a Plugin build; 3. flags the new version as pre-release; 4. tags the version in Git; 5. creates a local working copy of the SVN repo; 6. copies the new release to the local `trunk/` (whilst keeping the ‘Stable Tag’ field in `readme.txt` pointing to the previous stable version); 7. copies the commit message from the changelog in `readme.txt`; and 8. (if a flag is set) commits the changes to the remote `trunk/`. Pushing out a new release must still be done manually, once `trunk/` is tested and working. To do so, check out a local copy of `trunk/` and: 1. update the ‘Stable Tag’ field in `trunk/readme.txt` to the new version; 2. update the ‘Version’ field in the comment header of `trunk/footnotes.php` to the new version; 3. remove the ‘p’ from the end of the ‘version’ tag in the `getInfo()` function at the bottom of `js/wsiwyg-editor.js`; 4. copy a new tag for the release from `trunk/` (`svn cp trunk tags/<version number>`); and 5. commit your changes (`svn ci -m "Release version <version number>"`). The WP Plugin Directory will automatically parse the ‘Stable Tag’ field in `trunk/readme.txt`, and inform users that a new version is available. At various stages user input is required to validate information. This is not ready for automation with GitHub Actions, but is a useful step on the way — see [this piece](https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/) for more info. Unless a `-c` flag is passed (e.g., by running `composer run release:commit`) no changes will take place on the remote SVN repo. If you want to test this out on a branch other than `main`, uncomment lines 31 & 52 of the script. Version checking enforces the versioning rules stated [here](https://github.com/markcheret/footnotes/wiki/Versioning). **NB: I have not tested the `-c` mode yet, as I wanted people will more familiarity with the SVN to have a look at it before I risked making any changes and blowing everything up.** Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
32 lines
1.3 KiB
Bash
Executable file
32 lines
1.3 KiB
Bash
Executable file
#!/bin/bash
|
|
|
|
echo "Building Plugin..."
|
|
|
|
# Moves everything including the style sheets over to `dist/`
|
|
echo "Copying directories..."
|
|
cp -r -t dist class/ css/ js/ languages/ templates/
|
|
# Among the images, only 2 out of 3 are distributed.
|
|
echo "Copying the needed images..."
|
|
mkdir dist/img
|
|
cp -t dist/img img/fn-wysiwyg.png img/main-menu.png
|
|
echo "Copying files..."
|
|
cp -t dist features.txt license.txt readme.txt includes.php wpml-config.xml customized-documentation-schema.txt customized-template-stack.txt CONTRIBUTING.md README.md SECURITY.md
|
|
echo "Setting production flag..."
|
|
sed "s/'C_BOOL_CSS_PRODUCTION_MODE', false/'C_BOOL_CSS_PRODUCTION_MODE', true/g" footnotes.php > dist/footnotes.php
|
|
echo "Production flag set."
|
|
|
|
# TODO: once automatic minification is implemented, this should handle that.
|
|
# For now, we shall have to assume that this command is being run on a repo. with
|
|
# minimised stylesheet files already in `dist/css/`.
|
|
echo "Building stylesheets..."
|
|
./_tools/build-stylesheets.sh -c
|
|
if [ $? != 0 ]; then echo "Concatenation failed!"; exit 1; fi
|
|
./_tools/build-stylesheets.sh -m
|
|
if [ $? != 0 ]; then echo "Minification failed!"; exit 1; fi
|
|
./_tools/build-stylesheets.sh -d
|
|
if [ $? != 0 ]; then echo "Deployment failed!"; exit 1; fi
|
|
echo "Stylesheet build complete."
|
|
|
|
echo "Build complete."
|
|
exit 0
|