This repository has been archived on 2023-08-16. You can view files and clone it, but cannot push or open issues or pull requests.
footnotes/_tools/build-stylesheets.sh

95 lines
4 KiB
Bash
Raw Permalink Normal View History

Automatically generate new releases (#59) * Adapt after the 2.5.9d1 accident. * Corrections to changelog. * Also added @‌revision and @‌timestamp PHPDOC tags @‌revision and @‌timestamp used for SVN refs. Full enumeration of added custom PHPDOC tags: @‌accountable, @‌bib, @‌biblio, @‌callback, @‌commit, @‌committer, @‌contributor, @‌courtesy, @‌date, @‌datetime, @‌lastmodified, @‌modified, @‌publisher, @‌reporter, @‌revision, @‌timestamp, @‌user.Some tags like @‌reporter and @‌contributor are more used than others. * Readme header upgrade. * Create deploy-to-wordpress.org.yml * Add distignore * Comment out `build` command, replace npm with composer * Remove placeholder comments * Add build commands * Fix typo * Fix version number bug * Make zip without top-level directory * Append tag name to plugin zip * Clean up a bit * Rename workflow config * Fix upload paths * Append tag name to artifact * Fix paths * Revert path fix * Try again * Add wplm-config.xml to buildfiles * Fix indentation * Rename development/csscat.sh to css/csscat.sh * Rename development/customized-documentation-schema.txt to customized-documentation-schema.txt * Rename development/customized-template-stack.txt to customized-template-stack.txt * Version number related fixes before pull request. * Move csscat script to tools dir * Rename csscat * Refactor script * Update customized-documentation-schema.txt * Replace empty lines in help output * Escape empty lines. * Delete 3 items from `.distignore` As mentioned, CONTRIBUTING.md and README.md should be included in distributions. - As an invitation to the Community. - As a tangible proof of goodwill after the 2.5.9d1 accident. Also SECURITY.md so Footnotes users see that we’re concerned, and can reach out without transiting via GitHub. * Include CONTRIBUTING.md README.md SECURITY.md * Update sync w/ 5.7 tested. * Update * Update composerfiles Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
2021-03-12 17:53:49 +00:00
#!/bin/bash
# Concatenates, minifies (TODO) and deploys stylesheets for distribution.
#
# 12 unified stylesheets are concatenated out of these files:
# - `dev-common.css`
# - `dev-tooltips.css`
# - `dev-tooltips-alternative.css`
# - `dev-layout-reference-container.css`
# - `dev-layout-entry-content.css`
# - `dev-layout-main-content.css`
echo "Running $(dirname "$0")/build-stylesheets.sh"
if [[ $1 == "-c" ]]; then
Add release helper script (#64) 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>
2021-03-17 17:46:21 +00:00
echo "Concatenating files and placing in \`css/tmp/\`..."
Automatically generate new releases (#59) * Adapt after the 2.5.9d1 accident. * Corrections to changelog. * Also added @‌revision and @‌timestamp PHPDOC tags @‌revision and @‌timestamp used for SVN refs. Full enumeration of added custom PHPDOC tags: @‌accountable, @‌bib, @‌biblio, @‌callback, @‌commit, @‌committer, @‌contributor, @‌courtesy, @‌date, @‌datetime, @‌lastmodified, @‌modified, @‌publisher, @‌reporter, @‌revision, @‌timestamp, @‌user.Some tags like @‌reporter and @‌contributor are more used than others. * Readme header upgrade. * Create deploy-to-wordpress.org.yml * Add distignore * Comment out `build` command, replace npm with composer * Remove placeholder comments * Add build commands * Fix typo * Fix version number bug * Make zip without top-level directory * Append tag name to plugin zip * Clean up a bit * Rename workflow config * Fix upload paths * Append tag name to artifact * Fix paths * Revert path fix * Try again * Add wplm-config.xml to buildfiles * Fix indentation * Rename development/csscat.sh to css/csscat.sh * Rename development/customized-documentation-schema.txt to customized-documentation-schema.txt * Rename development/customized-template-stack.txt to customized-template-stack.txt * Version number related fixes before pull request. * Move csscat script to tools dir * Rename csscat * Refactor script * Update customized-documentation-schema.txt * Replace empty lines in help output * Escape empty lines. * Delete 3 items from `.distignore` As mentioned, CONTRIBUTING.md and README.md should be included in distributions. - As an invitation to the Community. - As a tangible proof of goodwill after the 2.5.9d1 accident. Also SECURITY.md so Footnotes users see that we’re concerned, and can reach out without transiting via GitHub. * Include CONTRIBUTING.md README.md SECURITY.md * Update sync w/ 5.7 tested. * Update * Update composerfiles Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
2021-03-12 17:53:49 +00:00
mkdir -p ./css/tmp
cat ./css/dev-common.css > ./css/tmp/footnotes-nottbrpl0.css
cat ./css/dev-{common,layout-reference-container}.css > ./css/tmp/footnotes-nottbrpl1.css
cat ./css/dev-{common,layout-entry-content}.css > ./css/tmp/footnotes-nottbrpl2.css
cat ./css/dev-{common,layout-main-content}.css > ./css/tmp/footnotes-nottbrpl3.css
cat ./css/dev-{common,tooltips}.css > ./css/tmp/footnotes-jqttbrpl0.css
cat ./css/dev-{common,tooltips,layout-reference-container}.css > ./css/tmp/footnotes-jqttbrpl1.css
cat ./css/dev-{common,tooltips,layout-entry-content}.css > ./css/tmp/footnotes-jqttbrpl2.css
cat ./css/dev-{common,tooltips,layout-main-content}.css > ./css/tmp/footnotes-jqttbrpl3.css
cat ./css/dev-{common,tooltips,tooltips-alternative}.css > ./css/tmp/footnotes-alttbrpl0.css
cat ./css/dev-{common,tooltips,tooltips-alternative,layout-reference-container}.css > ./css/tmp/footnotes-alttbrpl1.css
cat ./css/dev-{common,tooltips,tooltips-alternative,layout-entry-content}.css > ./css/tmp/footnotes-alttbrpl2.css
cat ./css/dev-{common,tooltips,tooltips-alternative,layout-main-content}.css > ./css/tmp/footnotes-alttbrpl3.css
cat ./css/settings.css > ./css/tmp/settings.css
Add release helper script (#64) 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>
2021-03-17 17:46:21 +00:00
echo "Stylesheet concatenation complete."
exit 0
Automatically generate new releases (#59) * Adapt after the 2.5.9d1 accident. * Corrections to changelog. * Also added @‌revision and @‌timestamp PHPDOC tags @‌revision and @‌timestamp used for SVN refs. Full enumeration of added custom PHPDOC tags: @‌accountable, @‌bib, @‌biblio, @‌callback, @‌commit, @‌committer, @‌contributor, @‌courtesy, @‌date, @‌datetime, @‌lastmodified, @‌modified, @‌publisher, @‌reporter, @‌revision, @‌timestamp, @‌user.Some tags like @‌reporter and @‌contributor are more used than others. * Readme header upgrade. * Create deploy-to-wordpress.org.yml * Add distignore * Comment out `build` command, replace npm with composer * Remove placeholder comments * Add build commands * Fix typo * Fix version number bug * Make zip without top-level directory * Append tag name to plugin zip * Clean up a bit * Rename workflow config * Fix upload paths * Append tag name to artifact * Fix paths * Revert path fix * Try again * Add wplm-config.xml to buildfiles * Fix indentation * Rename development/csscat.sh to css/csscat.sh * Rename development/customized-documentation-schema.txt to customized-documentation-schema.txt * Rename development/customized-template-stack.txt to customized-template-stack.txt * Version number related fixes before pull request. * Move csscat script to tools dir * Rename csscat * Refactor script * Update customized-documentation-schema.txt * Replace empty lines in help output * Escape empty lines. * Delete 3 items from `.distignore` As mentioned, CONTRIBUTING.md and README.md should be included in distributions. - As an invitation to the Community. - As a tangible proof of goodwill after the 2.5.9d1 accident. Also SECURITY.md so Footnotes users see that we’re concerned, and can reach out without transiting via GitHub. * Include CONTRIBUTING.md README.md SECURITY.md * Update sync w/ 5.7 tested. * Update * Update composerfiles Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
2021-03-12 17:53:49 +00:00
elif [[ $1 == "-m" ]]; then
# TODO: this should automatically minifiy all files, outputting into `.min.css`
# files and deleting the original concatenated `.css` files in `css/tmp/`.
# Once that's done, we can change the `rm -r` command in the deploy step to
# `rmdir`, which will throw us an error if we have any minified files that
# haven't been moved over to `dist/css/` for whatever reason. As it currently
# stands, we have no error checking in place.
Add release helper script (#64) 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>
2021-03-17 17:46:21 +00:00
echo "Please minify the stylesheets in \`css/tmp/\`, saving them in the same location with the \`.min.css\` file extension."
read -p "Are you ready to continue? (Y/N): " CONFIRM && [[ $CONFIRM == [yY] || $CONFIRM == [yY][eE][sS] ]] || exit 1
exit 0
Automatically generate new releases (#59) * Adapt after the 2.5.9d1 accident. * Corrections to changelog. * Also added @‌revision and @‌timestamp PHPDOC tags @‌revision and @‌timestamp used for SVN refs. Full enumeration of added custom PHPDOC tags: @‌accountable, @‌bib, @‌biblio, @‌callback, @‌commit, @‌committer, @‌contributor, @‌courtesy, @‌date, @‌datetime, @‌lastmodified, @‌modified, @‌publisher, @‌reporter, @‌revision, @‌timestamp, @‌user.Some tags like @‌reporter and @‌contributor are more used than others. * Readme header upgrade. * Create deploy-to-wordpress.org.yml * Add distignore * Comment out `build` command, replace npm with composer * Remove placeholder comments * Add build commands * Fix typo * Fix version number bug * Make zip without top-level directory * Append tag name to plugin zip * Clean up a bit * Rename workflow config * Fix upload paths * Append tag name to artifact * Fix paths * Revert path fix * Try again * Add wplm-config.xml to buildfiles * Fix indentation * Rename development/csscat.sh to css/csscat.sh * Rename development/customized-documentation-schema.txt to customized-documentation-schema.txt * Rename development/customized-template-stack.txt to customized-template-stack.txt * Version number related fixes before pull request. * Move csscat script to tools dir * Rename csscat * Refactor script * Update customized-documentation-schema.txt * Replace empty lines in help output * Escape empty lines. * Delete 3 items from `.distignore` As mentioned, CONTRIBUTING.md and README.md should be included in distributions. - As an invitation to the Community. - As a tangible proof of goodwill after the 2.5.9d1 accident. Also SECURITY.md so Footnotes users see that we’re concerned, and can reach out without transiting via GitHub. * Include CONTRIBUTING.md README.md SECURITY.md * Update sync w/ 5.7 tested. * Update * Update composerfiles Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
2021-03-12 17:53:49 +00:00
elif [[ $1 == "-d" ]]; then
Add release helper script (#64) 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>
2021-03-17 17:46:21 +00:00
# NOTE: I've temporarily replaced the `mv` command
# with `cp` and disabled the `rm` command, so the minified
# files won't be removed from the source directory.
echo "Deploying minified stylesheets to \`dist/css/\`..."
Automatically generate new releases (#59) * Adapt after the 2.5.9d1 accident. * Corrections to changelog. * Also added @‌revision and @‌timestamp PHPDOC tags @‌revision and @‌timestamp used for SVN refs. Full enumeration of added custom PHPDOC tags: @‌accountable, @‌bib, @‌biblio, @‌callback, @‌commit, @‌committer, @‌contributor, @‌courtesy, @‌date, @‌datetime, @‌lastmodified, @‌modified, @‌publisher, @‌reporter, @‌revision, @‌timestamp, @‌user.Some tags like @‌reporter and @‌contributor are more used than others. * Readme header upgrade. * Create deploy-to-wordpress.org.yml * Add distignore * Comment out `build` command, replace npm with composer * Remove placeholder comments * Add build commands * Fix typo * Fix version number bug * Make zip without top-level directory * Append tag name to plugin zip * Clean up a bit * Rename workflow config * Fix upload paths * Append tag name to artifact * Fix paths * Revert path fix * Try again * Add wplm-config.xml to buildfiles * Fix indentation * Rename development/csscat.sh to css/csscat.sh * Rename development/customized-documentation-schema.txt to customized-documentation-schema.txt * Rename development/customized-template-stack.txt to customized-template-stack.txt * Version number related fixes before pull request. * Move csscat script to tools dir * Rename csscat * Refactor script * Update customized-documentation-schema.txt * Replace empty lines in help output * Escape empty lines. * Delete 3 items from `.distignore` As mentioned, CONTRIBUTING.md and README.md should be included in distributions. - As an invitation to the Community. - As a tangible proof of goodwill after the 2.5.9d1 accident. Also SECURITY.md so Footnotes users see that we’re concerned, and can reach out without transiting via GitHub. * Include CONTRIBUTING.md README.md SECURITY.md * Update sync w/ 5.7 tested. * Update * Update composerfiles Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
2021-03-12 17:53:49 +00:00
rm -r ./dist
mkdir -p ./dist/css
for f in ./css/tmp/*.min.css; do
filename=$(basename $f .css)
Add release helper script (#64) 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>
2021-03-17 17:46:21 +00:00
cp $f ./dist/css
#mv $f ./dist/css
echo -e '\t' $filename".css moved."
Automatically generate new releases (#59) * Adapt after the 2.5.9d1 accident. * Corrections to changelog. * Also added @‌revision and @‌timestamp PHPDOC tags @‌revision and @‌timestamp used for SVN refs. Full enumeration of added custom PHPDOC tags: @‌accountable, @‌bib, @‌biblio, @‌callback, @‌commit, @‌committer, @‌contributor, @‌courtesy, @‌date, @‌datetime, @‌lastmodified, @‌modified, @‌publisher, @‌reporter, @‌revision, @‌timestamp, @‌user.Some tags like @‌reporter and @‌contributor are more used than others. * Readme header upgrade. * Create deploy-to-wordpress.org.yml * Add distignore * Comment out `build` command, replace npm with composer * Remove placeholder comments * Add build commands * Fix typo * Fix version number bug * Make zip without top-level directory * Append tag name to plugin zip * Clean up a bit * Rename workflow config * Fix upload paths * Append tag name to artifact * Fix paths * Revert path fix * Try again * Add wplm-config.xml to buildfiles * Fix indentation * Rename development/csscat.sh to css/csscat.sh * Rename development/customized-documentation-schema.txt to customized-documentation-schema.txt * Rename development/customized-template-stack.txt to customized-template-stack.txt * Version number related fixes before pull request. * Move csscat script to tools dir * Rename csscat * Refactor script * Update customized-documentation-schema.txt * Replace empty lines in help output * Escape empty lines. * Delete 3 items from `.distignore` As mentioned, CONTRIBUTING.md and README.md should be included in distributions. - As an invitation to the Community. - As a tangible proof of goodwill after the 2.5.9d1 accident. Also SECURITY.md so Footnotes users see that we’re concerned, and can reach out without transiting via GitHub. * Include CONTRIBUTING.md README.md SECURITY.md * Update sync w/ 5.7 tested. * Update * Update composerfiles Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
2021-03-12 17:53:49 +00:00
done
Add release helper script (#64) 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>
2021-03-17 17:46:21 +00:00
# NB: We currently distribute both the minified + concatenated and the
# unminified + unconcatenated stylesheets with the Plugin.
echo "Deploying development stylesheets to \`dist/css/\`..."
for f in ./css/dev-*.css; do
filename=$(basename $f .css)
cp $f ./dist/css
#mv $f ./dist/css
echo -e '\t' $filename".css moved."
done
#echo "Deleting temporary files..."
#rm -r ./css/tmp
echo "All stylesheets added to build."
exit 0
Automatically generate new releases (#59) * Adapt after the 2.5.9d1 accident. * Corrections to changelog. * Also added @‌revision and @‌timestamp PHPDOC tags @‌revision and @‌timestamp used for SVN refs. Full enumeration of added custom PHPDOC tags: @‌accountable, @‌bib, @‌biblio, @‌callback, @‌commit, @‌committer, @‌contributor, @‌courtesy, @‌date, @‌datetime, @‌lastmodified, @‌modified, @‌publisher, @‌reporter, @‌revision, @‌timestamp, @‌user.Some tags like @‌reporter and @‌contributor are more used than others. * Readme header upgrade. * Create deploy-to-wordpress.org.yml * Add distignore * Comment out `build` command, replace npm with composer * Remove placeholder comments * Add build commands * Fix typo * Fix version number bug * Make zip without top-level directory * Append tag name to plugin zip * Clean up a bit * Rename workflow config * Fix upload paths * Append tag name to artifact * Fix paths * Revert path fix * Try again * Add wplm-config.xml to buildfiles * Fix indentation * Rename development/csscat.sh to css/csscat.sh * Rename development/customized-documentation-schema.txt to customized-documentation-schema.txt * Rename development/customized-template-stack.txt to customized-template-stack.txt * Version number related fixes before pull request. * Move csscat script to tools dir * Rename csscat * Refactor script * Update customized-documentation-schema.txt * Replace empty lines in help output * Escape empty lines. * Delete 3 items from `.distignore` As mentioned, CONTRIBUTING.md and README.md should be included in distributions. - As an invitation to the Community. - As a tangible proof of goodwill after the 2.5.9d1 accident. Also SECURITY.md so Footnotes users see that we’re concerned, and can reach out without transiting via GitHub. * Include CONTRIBUTING.md README.md SECURITY.md * Update sync w/ 5.7 tested. * Update * Update composerfiles Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
2021-03-12 17:53:49 +00:00
else
echo -e "Concatenates, minifies (TODO) and deploys stylesheets for distribution.\n"
echo -e "12 unified style sheets are concatenated out of these files:\n"
echo "\`dev-common.css\`"
echo "\`dev-tooltips.css\`"
echo "\`dev-tooltips-alternative.css\`"
echo "\`dev-layout-reference-container.css\`"
echo "\`dev-layout-entry-content.css\`"
echo -e "\`dev-layout-main-content.css\`\n"
echo "Command: \`-c\`: Concatenate \`dev-*\` CSS files into temporary directory."
echo "Command: \`-m\`: Minify files (TODO)."
echo "Command: \`-d\`: Deploy minified files to \`dist/css/\` and remove temporary files."
echo "No command, \"--help\", or anything else: Output this help section."
fi