Jump to content
thirty bees forum

It's done: the module validator


Recommended Posts

This announcement is mostly for developers.

Looking at the current 1.0.x branch on Github, there's a series of 71 commits introducing tools/validatemodule.sh. It's run like this during module development: sh cd modules/<module> ../../tools/validatemodule.sh There's also a release mode, which does additional validations for things being significant when making a module or core release: sh cd modules/<module> ../../tools/validatemodule.sh --release And of course, like every proper shell application, it comes with a --help option, explaining things a bit.

This script was written and tested with the assumption of being a thirty bees module (e.g. it verifies file headers to contain the thirty bees one) residing in a Git repository being placed in the modules folder. It doesn't validate files on disk, but files checked into the repository. Which means, if you have fixed something, you have to commit that change to see it recognized by validatemodule.sh. It also means that stray files not committed get ignored, which is the purpose of this strategy.

Near time plan is to run a validation of all modules before doing a release. Somewhat later the plan is to add the capability of validating a module unpacked from a ZIP archive.

And yes, during coding and testing hundreds of smaller issues in the 51 default modules came up, so expect many commits there in the near future. Currently no less than 692 commits across all these modules are awaiting review, push and release :-)

Link to comment
Share on other sites

Another dozen of commits brought tools/buildmodule.sh, a central script for building a module package. It replaces all the individual build.sh scripts inside the modules (only about half of the standard modules had one) and and refuses to build if validatemodule.sh doesn't pass, of course. It also enabled me to start making new module releases, which is the best of all of this:

https://github.com/thirtybees/bankwire/releases/tag/2.0.7 https://github.com/thirtybees/blockbanner/releases/tag/2.0.2 https://github.com/thirtybees/blockbestsellers/releases/tag/2.1.2 ... more of them forthcoming ...

Does this change module behavior or fix merchant-visible bugs? Honestly, I don't know. Some modules had/have commits on master, but no release tag for them. Others had their version in code bumped, but also no release. So I'm not sure which version of each hits the shop installations.

Nevertheless I'm positive the situation becomes a bit more predictable now. Latest commit = head of master = latest release. And even an internal document on how to release a module step by step exists. That's how it should be :-)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...