Commit graph

6 commits

Author SHA1 Message Date
0e5a6830fe ci: update build process and linter to reflect new layout 2021-04-26 22:57:56 +01:00
c18a66ae95 ci: improve build commands 2021-04-26 11:46:42 +01:00
6a1117be15
ci: improve release process, clean up and re-org repo, add automated minification (#143)
* ci: update scripts

* release 2.7.1

* remove tracked stylesheets

* docs: revert stable tag to 2.7.0

* chore: move Plugin source into own dir

* docs: delete info texts

These can now be found in the [project wiki][wiki].

[wiki]: https://github.com/markcheret/footnotes/wiki

* docs: tweak contributing guide

* ci: reflect new directory structure

* chore: update gitignore

* chore: reflect new dir structure

* docs: update documentation

* build(linting): add Husky hooks, Markdown linting, lint all MD files

* fix pre-push command

* fix pre-push command

* build: add stylesheet, JS minification

* ci: add linting steps

* ci: comment out CSS linting step (that's going to be a whole *thing*)

* ci: minify all JS files

* ci: call correct JS file

* chore: lint

* ci: fix PHP linting commands

* chore: increment version constant string

* ci: concat AMP stylesheets

* ci: improve build scripts

* chore: add assets dir
2021-04-25 09:28:02 +01:00
3ae70069b3 fix: fix release and build scripts 2021-04-19 20:05:33 +01:00
0a34e96450
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
e8d6dbe13d
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