Allow variation in release property

[BClark09]

• [x] Requires OPENHAB_RELEASE_NUMBER to be added in cloudbees. I'll do this ahead of the merge.
• [x] Requires buildTesting task to be run on cloudbees with OPENHAB_RELEASE_NUMBER=2 and OPENHAB_TESTING_VERSION=2.1.0 after merge to resolve #82

Signed-off-by: Ben Clark ben@benjyc.uk

[BClark09]

I will test this PR by running:

sudo ./gradlew -DOPENHAB_TESTING_VERSION=2.1.0 -DOPENHAB_RELEASE_NUMBER=2 buildTesting

as soon as possible.

[BClark09]

https://openhab.jfrog.io/openhab/webapp/#/artifacts/browse/tree/General/linuxpkg-testing/pool/main/2.1.0/openhab2_2.1.0-2_all.deb

Seems to work well, can only properly test the generated file late this evening however.

[ThomDietrich]

Fingers crossed! :wink:

[BClark09]

After a bit of delay (I found out you cannot build linuxpkg on a Windows machine 😞) the testing package seems fine. I found that openhab-cli makes reference to the restore and backup scripts however so have prepared #86 before merge.

If you agree, my actions would be:

• Merge #86
• Merge this PR
• Build a testing package in cloudbees
• Make a new PR removing the comments introduced in #86

[BClark09]

Build completed and published to jfrog. Have tested the signed packages and sent instruction to distribute to Bintray. Now we wait :clock1:

[BClark09]

For my own reference, no waiting needed. calculateMetadata task does what we need so should be executed after a release to update the repo index quickly and with the right signatures.

Release builds in the future should follow this order:

1. Run task buildRelease.
2. Validate files on jFrog.
3. Push to distribution repo from jFrog to Bintray (performing a dry-run first to confirm paths)
4. Run task calculateMetadata.