Emoncms V9.9.6 Stable merge (pre-merge check)

Emoncms
24

In my defence, it was a very quick bit of code :grin:…

1 Like
25

Thanks @borpin @Greebo, I’ve merged the pull request and incorporated your comment @Greebo

26

I’ve commented on GitHub but this is an error I think.

Previously, the first if checks for a flag and if it exists does some stuff,

Now the ‘some stuff’ (line 50 on) is executed every time and ‘flag’ can be undefined or the previous value.

27

Ah yes, you’re right - I wasn’t paying sufficient attention to the indentation!

I’ve re-written parts of it today anyway to cope with multiple instances and any prefix - it does this by looking in redis for the “readapikey” key on startup and then uses any prefix(es) it finds there to subsequently search for service-runner.

It needs some more testing with a few different prefixes, and on a multi-instance install before its ready for a PR though. Until then, ignore my suggestions and go with @borpin’s original PR code.

@TrystanLea, is it safe to assume that every EmonCMS will have a “readapikey” key held in redis?

28

I like that :smile:

29

Just did a pull on master and found the Server information when posted here is not formatted correctly. I’ve raised an issue.

30

Could this go into usefulscripts?

31

@TrystanLea Just created a PR to fix this.

32

Thanks @borpin. I’ve merged it in.

33

@borpin @Greebo I think it would be a good idea if we go forward with this v9.9.6 merge, the discussed changes to service-runner or associated emoncms calls can be updated at a later stage. The automated update process would at this point still be aimed at emonSD users. I think there is more work required to reach a point where clicking the update button on the UI works for custom installations - we can review and test these separately. I’ve tested the update on a emonpi here again and it all goes smoothly.

Test procedure:

SSH into stock EmonPi running emonSD-30Oct18

cd emonpi
git pull
git checkout service_correction
cd /var/www/emoncms
git checkout master

Then I login to the EmonPi, navigate to admin and running emonpi update.

34

Once emonpi:service_correction and emoncms:master are merged the update should work out of the box (without these manual changes) as the update procedure changes are all in 2nd level scripts (emoncmsupdate and emonhubupdate) called from the main “service-runner-update.sh” script that is in the emonpi repository.

35

@TrystanLea, I’m sorry for repeating myself, but it will be great if the Git tags can be set for each repository.

I think we have done all we can for now.

1 Like
36

Great, ok Il start the process.

37

Emoncms Update, core and modules

Emoncms (v9.9.6):

Emonpi (v2.9.1):

emoncms app module (v1.2.1):

emoncms dashboard module (v1.3.3):

emoncms graph module (v1.2.2):

emoncms wifi module (v1.3.1):

emoncms device module (v1.2.1)

emoncms sync module (v1.0.1)

emoncms postprocess module (v1.0.0)

emoncms backup module (v1.1.6)

  • The backup module has not changed since last stable merge.
38

I think that’s all done! Thankyou everyone for helping with this release! :tada:

39

Updating:

  • For emonPi & emonBase users the above is all available now by clicking emonPi/emonbase Update in the emoncms administration menu.

  • If you are running a custom installation of emoncms, feel free to update the core, or any specific module as you wish. There is still work ongoing on automating the update process for custom installations. Other than core and module updates the other main difference is the renaming of phpmqtt_input service to emoncms_mqtt service. This is a non breaking change as the original service is still present in the repository. See the readme here for details on how to remove the old mqtt_input service and install the new emoncms_mqtt service: emoncms/install-service-emoncmsmqtt.md at master · emoncms/emoncms · GitHub

40

@TrystanLea, something did not quite go as planned…

**Emoncms** Version low-write 9.9.6
Branch: * stable | Describe: 9.9.4-205-g22d2e6c1

Ok so, my bad. I must have translated my test commands badly. To get an annotated tag as opposed to a lightweight tag (which is what Github creates), you need to use the -a option. So

git tag -a 1.4 -m "my version 1.4"

I think that this can be fixed.

By using the command git log --pretty=oneline the last 2 commits to Stable are…

22d2e6c1c685982afe4deb17b17921df7b84cb2f Merge pull request #1159 from emoncms/master
53991d68e7c7e5ffc4c494ed2c7da6e350abef9a Update version.txt

And the last few commits to master are

0a74cda9c3d0b1fbf02a68b3c53b7bbdddf7612f readme for emoncms_mqtt service
acbfca04d932e093babc13bbdb71d689e425c83f Update version.txt
ede160083a24f7cc32f6b2026f187157d43bfe97 Update version.txt
53991d68e7c7e5ffc4c494ed2c7da6e350abef9a Update version.txt

The lightweight tag 9.9.6 currently points to this commit

# git show 9.9.6
commit acbfca04d932e093babc13bbdb71d689e425c83f
Author: Trystan Lea <[email protected]>
Date:   Tue Feb 12 15:07:13 2019 +0000

    Update version.txt

diff --git a/version.txt b/version.txt
index d9e3b748..709d3278 100644
--- a/version.txt
+++ b/version.txt
@@ -1 +1 @@
-9.9.7-beta
+9.9.6

The problem is this commit is not actually in stable…

I Think the command;

git tag -a -f 9.9.6 <commit> -m "The release message"

will set the tag correctly and override any meta data held against it. We just need to pick the right commit number.

You do need to then push the tag as in

git push origin 9.9.6

Alternatively we leave it and try again next time :slight_smile:

Reference 1- Git tag

41

aha looks like I got the ordering wrong then, merging to stable prior to setting the tab. If I merge master again into stable now would that then include the tag perhaps?

What is the reason for the annotated tag?

Github will also create the tag for you if you just create a release in the UI…?

42

I think doing the tag is the very last thing and it attaches itself to the last commit. I’d just point the tag to the right commit.

git describe will easily identify where the user’s repository is for the admin page.

Github tags are ‘lightweight’ tags, using the -a creates annotated tags. Have a look at the reference for a fuller explanation.

so the git describe of 9.9.4-207-g0a74cda9 is on commit g0a74cda9 which is 207 commits ahead of the last annotated tag 9.9.4

$ git describe --tags --debug
searching to describe HEAD
 lightweight        1 9.9.6
 lightweight      190 9.9.5
 lightweight      204 9.9.3
 annotated        207 9.9.4
 lightweight      258 V9.9.2
43

Thanks @borpin Il take a look and get back to you on this soon.

1 Like