Build/deploy automation: dependency fixes + CI cleanup - #1650
Build/deploy automation: dependency fixes + CI cleanup#1650rajatgautam755421 wants to merge 27 commits into
Conversation
Scope @ajna/pagination and stylelint-config-wordpress peer overrides instead of relying on --legacy-peer-deps/--force, migrate PHPUnit test tooling to a PHP 7.4-8.3-compatible line, and pin Node via .nvmrc.
vendor/, dist/, the compiled .pot, minified admin/frontend JS, and CSS source maps are all reproducible via composer/npm and shouldn't live in git; the untracking itself already landed with the previous commit.
The interactive y/N prompt read from /dev/tty, which hangs or errors in any non-interactive context (scripted pushes, some GUI clients) and made --no-verify a habit rather than an exception. Real enforcement belongs in GitHub branch protection, not a client-side hook.
evf-PR-test.yml did a full uncached npm/composer reinstall+build+zip on every push and SSHed into one shared QA server per run, with no isolation between concurrent runs. pr-lint-test.yml just lints JS and verifies composer resolves cleanly across PHP 7.4-8.3, both cached on lockfile hashes - nothing is built or deployed here anymore.
build-release.yml and push-deploy.yml built and deployed independently, so they could drift from each other - push-deploy.yml in particular had zero build steps of its own and only worked because the tagged tree still had committed build output. release.yml now builds once, uploads it as an artifact, and has both the GitHub Release attach and the SVN deploy consume that same artifact.
workflow_dispatch job that bumps the version across the plugin header, includes/class-everest-forms.php, package.json, and readme.txt, inserts a changelog stub in readme.txt/CHANGELOG.txt, and opens a PR against pre-develop - a human still fills in the real changelog and merges/tags, but no longer hand-edits four separate version strings.
Without a platform.php pin, regenerating composer.lock on a newer local PHP silently locked transitive dev dependencies (symfony/console et al, pulled in via spatie/phpunit-watcher) to versions requiring PHP >=8.1, breaking the 7.4 leg of the new CI matrix. spatie/phpunit-watcher itself requires PHP ^8.1 and is only used by the optional test:watch convenience script (not CI, not the real test script), so it's removed rather than pinned to an old sub-version - jolicode/jolinotif goes with it since it was only pulled in for phpunit-watcher's desktop notifications.
npm run lint:js has apparently never actually run in CI - .eslintrc's "extends": "eslint" referenced a config that doesn't exist (should be the built-in eslint:recommended), and its parser named the long-deprecated babel-eslint package instead of the already-installed @babel/eslint-parser. Once those were fixed, real errors surfaced: most were noise from vendored third-party JS (jquery-tiptip, mailcheck, wp-color-picker, dropzone, code-mirror, intlTelInput) never added to .eslintignore alongside the other 8 vendored dirs already there, WP-standard runtime globals (jQuery, wp, ajaxurl, grecaptcha) never being declared, and no-mixed-spaces-and-tabs flagging the codebase's normal WPCS tab-indentation as an error instead of allowing it via smart-tabs mode.
Even after fixing the eslint config itself, ~800 real findings remain in first-party admin/frontend JS (unused vars, redeclares, a few real no-cond-assign bugs, useless escapes). That's never been enforced before and needs case-by-case cleanup, not a blind bulk fix - continue-on-error keeps the signal visible without blocking merges on a backlog this PR didn't create.
actions/cache@v2 is now hard-deprecated by GitHub and fails the job at setup, before any code even runs - unrelated to this PR's changes, but blocking every PR's code-sniff check right now.
…the way Both .jshintrc and .eslintrc were missing modern syntax support (esversion, es6 env) and several legitimate runtime globals (localized script objects, Mailcheck/flatpickr/tinyMCE), so linting these files for the first time surfaced real, pre-existing bugs: - everest-forms.js: `! 'select-multiple' === type` parses as `(!'select-multiple') === type`, which is always false - the onclick revalidation branch for non-multiselect fields has been dead code. - ajax-submission.js: `'evf'-+ form_id +'-field_'...` is string-minus-number (evaluates to NaN), garbling the id used to detect signature/likert/address fields on submission failure - always fell through to the generic case. - everest-forms-survey-polls-quiz.js: `container` and `$this` were assigned without `var` in two handlers, leaking them as globals across calls. - everest-forms.js: two date-range branches did `x = x` (self-assignment, a no-op) or produced a different fallback than intended depending on input - restructured both to match their actual intended fallback values. - Assorted: missing semicolons, == where === was intended on values that are always the same type, double-quoted strings mixed into otherwise single-quoted files, an always-discarded JSON.parse result, and three deeply-nested inline callbacks reworked as named locals (same behavior, under the existing max-nested-callbacks limit).
npm run release now does everything bin/build-zip.sh did (install deps, build:core, production composer install, zip) but through grunt release's existing compress step instead of a separate hand-rolled rsync+zip. Removes build-zip.sh and the "test build action" workflow that called it via wpeverest/action-build - both superseded by this same consolidation that already replaced build-release.yml/push-deploy.yml earlier.
npm run start runs webpack serve with hot+liveReload+writeToDisk, so the existing wp_enqueue_script calls (unchanged, still pointing at dist/*.min.js) pick up live-reloading automatically - webpack-dev-server injects its client/HMR runtime directly into each compiled bundle, confirmed by grepping the output for it after a real run. No PHP changes needed: an earlier version of this added a PHP hook to manually load a dev-server client script, but testing showed that URL 404s and the injection already happens automatically - removed as dead code before committing. Also fixes NODE_ENV being hardcoded to 'production' regardless of the actual environment variable, which had silently made the existing `if (webpackConfig.mode !== 'production')` devtool branch unreachable.
Prompts for a new version and updates it everywhere it lives (plugin header, class property, readme Stable tag, package.json), plus drops an empty changelog placeholder for the changelog text to be filled in by hand.
Pushing a commit containing 'release: create tag' to develop reads the pending changelog entry from readme.txt and creates or updates a draft GitHub Release from it. Nothing publishes automatically.
Same issue as pro: contains(toJson(commits), ...) matched the phrase anywhere in a commit message, including this branch's own earlier commits that mention it in a body paragraph. Now requires a commit's subject line to start with the marker.
…lly use = X.X.X - xx-xx-2026 = was a single space; recent real entries in this repo's readme.txt pad the version out 7 spaces before the dash (verified directly: recent = X.X.X entries measure exactly 15 chars from '=' through '-'). New placeholders now match -- pro's own copy uses 11 spaces since that's its own separately-measured convention.
…eal releases Same issue as pro: '* bullet' was rendering as an actual markdown bulleted list instead of literal text. Real past releases wrap version+bullets in a triple-backtick block, confirmed against a real release's rendered page.
…ding Same defensive fix as pro: the scan now also stops at any bare '==...==' line, not just the next '= version -' line or end of string -- protects against the same class of bug found live in pro's Stripe readme.txt (a duplicate '== Changelog ==' heading getting swallowed into the captured bullets).
…ust creation Same critical bug as pro: gh release edit never re-pinned --target, so a draft updated more than once stayed pointed at whatever commit existed when it was first created, while its body text kept describing newer changes. Fixed by passing --target on every edit, not just create.
…marker This repo's own readme.txt entries (e.g. 3.6.0, 3.5.3) are consistently committed without a closing =, unlike pro/addons' readme.txt convention. The marker regex required one, so a real pending entry written in this repo's own actual style would fail the workflow outright.
Extends the existing assets/js/{admin,frontend}/*.min.js ignore rule to
compiled CSS (sass/rtlcss output) and the 9 vendor libs the
uglify:vendor Grunt target regenerates. Scoped to assets/css/ top level
only -- nested vendor dirs (jquery-ui/, perfect-scrollbar/, etc.) and
the whole addons/ tree have no grunt build step reaching them (confirmed
via each task's actual cwd/src glob, not assumed from directory names),
so they stay tracked.
Also fixes a real pre-existing bug: printThis.min.js is a vendored file
with no non-min source, but the existing blanket
assets/js/admin/*.min.js rule had already silently untracked it. Added
a negation and re-added the file.
Mirrors the pattern already established in the pro monorepo: 'build' is 'release' minus the two compress: steps, giving initial-setup/local-dev a way to compile everything (composer, webpack, sass/uglify/makepot) without producing a zip. Also adds force: true to jshint's options, matching pro's existing fix -- otherwise a legacy lint violation would abort the whole build task, same bug pro had before it was fixed.
Draft releases were titled 'Everest Forms X.X.X', not matching any real past release title. Verified via a real test publish (title showed 'Release of 3.6.4' correctly).
Why this PR shows 347 file changes195 of them (56%) are The actual code change is 152 files: 71 What's new here: a Nothing in this PR ever published a real release or deployed to WordPress.org — every workflow test used disposable branches/releases with the SVN step forced to dry-run, verified and deleted afterward. |
All Submissions:
Changes proposed in this Pull Request:
Builds a complete, tested release automation pipeline for the free plugin, matching the equivalent work done on the Pro monorepo, and fixes several real, pre-existing bugs found while getting it working end to end.
Local build tooling
npm run bump— bumps the plugin version and drops a pending changelog placeholder.npm run build— build without zipping (mirrorsrelease, minus the zip step), for local setup/testing.npm run build:core— what CI's build job actually runs.Automated draft-release → build-and-ship pipeline
prepare-release-draft.yml— arelease: create tagmarker commit auto-generates a draft GitHub Release from the pending changelog entry, code-fenced to render like real past releases.release.yml— consolidates the previousbuild-release.yml+push-deploy.ymlinto one workflow: builds fresh, attaches the zip to the GitHub Release, and deploys straight to WordPress.org SVN on publish.pr-lint-test.yml— replaces the oldevf-PR-test.yml(uncached, shared-server SSH deploy, Node 12/PHP 7.4 only) with JS lint + a PHP 7.4–8.3composer installcompat matrix on every PR — no secrets,pull_request(notpull_request_target), cached.Real bugs found and fixed
jshintaborted the build task on pre-existing lint debt instead of just reporting it (same class of bug also found and fixed in Pro).gh release uploadhad no repo context outside a git checkout — failed on the one job with nocheckoutstep.=on the changelog date line, but this repo's own real entries don't have one — a real pending entry written in the repo's own house style would have failed the whole workflow..min.jswere tracked directly in git even though they're fully regenerable — stopped tracking 33 files, keeping the ones with no real source (an existing blanket ignore rule had already silently untracked one vendored file,printThis.min.js, with no way back — restored it).Everest Forms X.X.Xinstead of the realRelease of X.X.Xconvention.Deliberately manual, not automated: unlike Pro, the real release date is not auto-written back into
readme.txtafter publish — this file is what WordPress.org renders live on the public plugin page, so the fix needs to land before the SVN deploy runs, not after. That's kept as the existing manual step (a human commits the real date todevelopbefore publishing) rather than adding automation complexity for one file.How to test the changes in this Pull Request:
npm install && npm run build— confirm a clean build with no zip produced.npm run release— confirm the zip step still works (1436 files compressed)..github/workflows/prepare-release-draft.yml/release.yml— trace the marker-detection → draft → publish → build/attach/SVN-deploy flow.pull_request_target, and that the SVN deploy step'sdry-runinput is understood (verified via the action's owndeploy.sh: the only line that writes to.orgissvn commit, hard-gated behind that flag).Types of changes:
Other information:
Changelog entry
Note on file count: 56% of this PR's changed files are
vendor/directory files being untracked (composer dependency output that shouldn't have been committed). The actual code change is 152 files; see the comment below for the full breakdown.