learninglocker
learninglocker copied to clipboard
LearningLocker
Old version number still being shown after the upgrade
You need to replace the parts of this template where you see {{some text}}.
Version master at a6021af0fb33d97f2953c0ce876442cacaa4a299 on 2.5.5
Steps to reproduce the bug
- Upgrade any older version of LL V2
Expected behaviour Login screen should have version v2.5.5 text as it matches with the version installed.
Actual behaviour
Login screen shown version as v2.1.3 as it was when first being installed.
<p title="Build: master @ 9433f3a35d0ca6919061119f07b5ea964c8d3347">v2.1.3</p>
Additional information
OS: Ubuntu 16.04
Browser: Chrome version 69.0.3497.100
Both OS and browser version are irrelevant as that seems to be some of the internals listing wrong version number. The real version is 2.5.5 (pm2 shows that when running pm2 list).
Just running the shell script again. Pretty much following the instructions outlined here.
The version seemed to have changed, with all migrations applied and so on.
Okay thanks @pjotrsavitski. @ht2 @asahd something we've seen before? I'm unsure what the install script does on upgrades compared to installs.
The version is just pulled from the tags list, but I'm wondering if because master was checked out, it hasn't actually pulled the tags.
Run git fetch --tags in the webapp working directory and see if that fixes it
It happened again, upgrading from 2.6.2 to 2.7.0 (the migrations also had an error due to a duplicate identifiers with a lot of number 1 characters in it (1111...111).
@ht2 Ran that tags fetching where, within the FULL_PATH/current/webapp? That one did not do any good for me. After the fetch brought the tags in question and pm2 restarted the services, nothing happened. Not upgrading the version seems to be a standard behaviour.
We recently upgraded from v2.2.2 to v3.1.0 and the webapp still shows v2.2.1 (the first version we ever installed). The actual html in the page is: <p title="Build: master @ 3fb1a677fb3893504181c261747a2690f87137c4">v2.2.1</p>
Tried running "git fetch --tags" in both of the git directories in webapp (/usr/local/learninglocker/current/webapp/ and /usr/local/learninglocker/current/webapp/.git). It seemed to pull the latest tags down, but after rebooting the version was still showing as v2.2.1.
/usr/local/learninglocker/current/webapp/ui/src/components/FullPageBackground/index.js
This seems to handle the version display, but I don't know anything about nodejs, so I couldn't actually get it to reflect any changes. Any ideas? Thanks for your help!
As a followup, as suggested by James in the gitter support channel, the fix is (after backing up the VM first!!):
cd /usr/local/learninglocker/current/webapp git reset HEAD --hard git clean -df git pull yarn install yarn build-all systemctl restart pm2-learninglocker
and now the webapp shows v3.1.0 and /api/app/version shows:
short "f28afc1" long "f28afc1c0e8afecf0f143fbc68f3ef9c2d0b88d2" branch "master" tag "v3.1.0"
@jesseoDIG Thanks for the info on the fix, though that should not be required and wold have to be handled by the script itself. Fetching version from the commit or branch might not be the best idea ever, especially if there is a package.json or any other file that has the version number present (most of Node.js packages do have that + importing JSON file into the process is really easy).
@pjotrsavitski We do not include the current version in the package.json, we use semantic-release to automate our releases and you hit a chicken-egg scenario where we release on the current commit to master (if tests pass) and you cannot modify the package.json at that point (https://github.com/semantic-release/semantic-release).
The script should be handling this, but it doesn't. To be honest we want to rewrite it anyway as it's showing its age. Happy to accept any modifications (PRs) if someone wants to try and issue a fix for this issue onto the deploy script though: https://github.com/LearningLocker/deploy
@ht2 I've dug into the codebase to see how does it work. It seems to be using the git-rev package to extract the data on the fly as could be seen here
So the issue seems to be with the commend from this line. I'd guess that all the other values are also incorrect in those cases.
The server sowed that webapp was still pointing to the master branch of the older tag, with no new tags have been fetched and a lot of uncommitted modifications. A guess would be that some part of the process would just move the filed around without making the necessary changes to the state of the repository. Checking the git log output within the xapi directory shows correct and consistent data.
Will see if that could be checked out when my local instance will become outdated again.
Hi, having the same issue upgrading from 2.6.2 to the current version. Is there any definative fix i can try?
FYI I tried @jesseoDIG suggestion and it worked to upgrade to the latest version of the web gui. This is still a problem that the devs should investigate.
