updateHTMLVersion.js fails after reverting version in package.json

[pixelzoom]

It used to be the case that, if you had a failed build, you could just revert the version number in package.json. Now there's a new task, updateHTMLVersion.js, that does "Bumping dev HTML with new version". And if I revert version in package.json, my next build fails on that task.

This behavior is most inconvenient. I have occasional failures due to VPN hiccups, and I don't enjoy having unexplained gaps in my version numbering on phet-dev.colorado.edu.

@jonathanolson added updateHTMLVersion.js on 4/13/2020. Must updateHTMLVersion.js fail in this situation? Can't it just take whatever is in package.json and stick it into the dev HTML?

[pixelzoom]

Here's an example...

Publish natural-selection 1.0.0-dev.41:

% grunt dev --brands=phet,phet-io

Uh, oh. Something went wrong. Log into bayes, delete the 1.0.0-dev.41/ directory. Edit natural-selection/package.son and revert "version" to "1.0.0-dev.40", commit and push.

Now attempt to deploy 1.0.0-dev.41 again:

% git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
% grunt dev --brands=phet,phet-io
Running "dev" task
(Forwarding task to perennial)
Running "dev" task
info: linting natural-selection
info: running [[ -d "/data/web/htdocs/dev/html/natural-selection" ]] && echo exists || echo not remotely on bayes.colorado.edu
info: running [[ -d "/data/web/htdocs/dev/html/natural-selection/1.0.0-dev.41" ]] && echo exists || echo not remotely on bayes.colorado.edu
Deploy 1.0.0-dev.41 to bayes.colorado.edu [y/N]?y
info: npm update on natural-selection
info: npm update on chipper
info: Setting version from package.json for natural-selection to 1.0.0-dev.41
info: git add package.json on natural-selection
info: git commit on natural-selection with message:
Bumping version to 1.0.0-dev.41
info: Updating HTML for natural-selection with the new version strings
info: git add natural-selection_en.html on natural-selection
info: git commit on natural-selection with message:
Bumping dev HTML with new version
Fatal error: Perennial task failed:
Error: git commit --no-verify -m Bumping dev HTML with new version in ../natural-selection failed with exit code 1 and stdout:
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

  at ChildProcess.<anonymous> (/Users/cmalley/PhET/GitHub/perennial/js/common/execute.js:71:17)
  at ChildProcess.emit (events.js:210:5)
  at ChildProcess.EventEmitter.emit (domain.js:475:20)
  at maybeClose (internal/child_process.js:1021:16)
  at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)

Full Error details:
{
  "cmd": "git",
  "args": [
    "commit",
    "--no-verify",
    "-m",
    "Bumping dev HTML with new version"
  ],
  "cwd": "../natural-selection",
  "stdout": "On branch master\nYour branch is ahead of 'origin/master' by 1 commit.\n  (use \"git push\" to publish your local commits)\n\nnothing to commit, working tree clean\n",
  "stderr": "",
  "code": 1
}
Fatal error: perennial grunt "--repo=natural-selection" "dev" "--brands=phet,phet-io" failed with code 1
%

Great. package.json has been committed with 1.0.0-dev.41, and then the deploy fails.

[pixelzoom]

@samreid suggested that I delete and re-clone natural-selection. I tried that, and identical results after deleting and re-cloning.

I suspect that I could also revert the dev html file and then I might be able to redeploy. But there's nothing that indicates that reverting the html file is necessary, and I really don't want an extra step.

[jonathanolson]

Added a patch that should allow this, although having a gap in version numbers has been the supported way of doing things.

[pixelzoom]

Added a patch that should allow this,

Thanks, I'll check it out.

although having a gap in version numbers has been the supported way of doing things.

I've been reverting deploys like this for literally years, it's never been a problem until now. And the build process even tells you something like "Are you trying to do a redeploy? Then you need to delete {dirName} on bayes."

[pixelzoom]

Tested with example-sim 1.0.0-dev.17 and it's working nicely. Thanks, closing.

[jonathanolson]

Reopening, it appears I bugged this up (if you have ONLY staged changes and NO unstaged changes, it reports as "clean", so this isn't committing in the normal deployment case).

[samreid]

In slack, @jonathanolson commented that this would not block dev versions.

[jonathanolson]

Should be fixed above, forgot an await :/