Skip to content

Build/deploy automation: dependency fixes + CI cleanup - #1650

Open
rajatgautam755421 wants to merge 27 commits into
pre-developfrom
build-deploy-automation
Open

Build/deploy automation: dependency fixes + CI cleanup#1650
rajatgautam755421 wants to merge 27 commits into
pre-developfrom
build-deploy-automation

Conversation

@rajatgautam755421

@rajatgautam755421 rajatgautam755421 commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

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 (mirrors release, 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 — a release: create tag marker commit auto-generates a draft GitHub Release from the pending changelog entry, code-fenced to render like real past releases.
  • release.yml — consolidates the previous build-release.yml + push-deploy.yml into 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 old evf-PR-test.yml (uncached, shared-server SSH deploy, Node 12/PHP 7.4 only) with JS lint + a PHP 7.4–8.3 composer install compat matrix on every PR — no secrets, pull_request (not pull_request_target), cached.

Real bugs found and fixed

  • jshint aborted the build task on pre-existing lint debt instead of just reporting it (same class of bug also found and fixed in Pro).
  • A published draft's target commit only got re-pinned on first creation, not on later updates.
  • gh release upload had no repo context outside a git checkout — failed on the one job with no checkout step.
  • The marker-detection regex required a trailing = 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.
  • Compiled CSS/RTL-CSS/.min.js were 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).
  • Draft release titles read Everest Forms X.X.X instead of the real Release of X.X.X convention.

Deliberately manual, not automated: unlike Pro, the real release date is not auto-written back into readme.txt after 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 to develop before publishing) rather than adding automation complexity for one file.

How to test the changes in this Pull Request:

  1. npm install && npm run build — confirm a clean build with no zip produced.
  2. npm run release — confirm the zip step still works (1436 files compressed).
  3. Review .github/workflows/prepare-release-draft.yml / release.yml — trace the marker-detection → draft → publish → build/attach/SVN-deploy flow.
  4. Confirm no workflow uses pull_request_target, and that the SVN deploy step's dry-run input is understood (verified via the action's own deploy.sh: the only line that writes to .org is svn commit, hard-gated behind that flag).

Types of changes:

  • Bug fix (non-breaking change which fixes an issue)
  • Enhancement (modification of the currently available functionality)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Other information:

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you successfully run tests with your changes locally?
  • Have you updated the documentation accordingly?

Changelog entry

Adds an automated build/release pipeline (version bump, draft-release generation, build-and-ship-on-publish, PR lint/compat checks) and fixes several real, pre-existing build/release bugs found while testing it.


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.

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.
@rajatgautam755421
rajatgautam755421 marked this pull request as ready for review August 27, 2026 04:30
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).
@rajatgautam755421

Copy link
Copy Markdown
Contributor Author

Why this PR shows 347 file changes

195 of them (56%) are vendor/ directory files being untracked — composer dependencies that shouldn't have been committed in the first place (vendor/composer/*, vendor/themegrill/*, vendor/scssphp/*, etc.). All 174 .php files in this diff are inside vendor/ — zero real source PHP changed.

The actual code change is 152 files: 71 .js + 24 .css (compiled assets stopped being tracked — same reasoning as vendor/, they're build output regenerable via npm run build), 10 .yml (new/updated CI workflows), 10 .json + 8 .txt (manifests, changelog entries), plus .webp/.png assets, .map, and .md.

What's new here: a build task/npm script alongside release (build without zipping, for local setup), a pr-lint-test.yml (JS lint + PHP 7.4–8.3 compat matrix, no secrets — verified running for real on this PR), and an automated draft-release + build pipeline tested via multiple real, disposable test cycles, including the actual SVN-deploy step run with dry-run: true (verified via the action's own logs that no commit ever reached .org).

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.

@rajatgautam755421

Copy link
Copy Markdown
Contributor Author

build-deploy.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant