nightly tarball testing
dothebart opened this issue · 1 comments
dothebart commented
- create docker container that can run the nightly tar tester
- There should be sourceInfo.log near ftp://nas02.arangodb.biz/buildfiles/stage2/nightly/devel/Linux/ with the following info:
Community: 819...
Enterprise: f2c...
which will be fetched by acqurie_packages, and be used to check whether the package is new or not.
I believe there should be jenkins folder in this repo that has simple bash script which can run this docker.
I advise to always use https://fileserver.arangodb.com:8529/?dir=stage2/nightly to get packages (i.e. https://fileserver.arangodb.com:8529/stage2/nightly/devel/Linux/arangodb3-linux-3.8.0-nightly.tar.gz) and files and pick username and password from DOWNLOAD_CREDENTIALS environment variable which will be provided by Jenkins in user:password format. - protect against duplicate runs:
I suggest to do the following in order to prevent duplicate execution of upgrade jobs in Jenkins:
have Upgrade view with Upgrade-3.7-to-devel job (more should happen afterwards)
in the beginning of new run copy sourceInfo.log and execution logs (should be generated by release-test-automation and preserved as upgrade.log from previous finished job (using "Copy Artifacts" step) despite blue or red result)
release-test-automation should compare copied sourceInfo.log, acquired sourceInfo.log for current run and analyze upgrade.log (which, for example, can have release-test-automation commit so we can understand whether the same packages should be re-tested by an improved scripts) to decide whether we should start new execution
if there is no need to start new execution current job should delete result and store this information as Upgrade-3.7-to-devel job description using post-build step so we can understand what was started, when and why it wasn't actually executed
I believe there should be jenkins folder in this repo that has simple bash script which can run the docker image.
I advise to always use https://fileserver.arangodb.com:8529/?dir=stage2/nightly to get packages (i.e. https://fileserver.arangodb.com:8529/stage2/nightly/devel/Linux/arangodb3-linux-3.8.0-nightly.tar.gz) and files and pick username and password from DOWNLOAD_CREDENTIALS environment variable which will be provided by Jenkins in user:password format.
There is no need to analyze --version output because ArangoDB version (i.e. 3.8.0-nightly.20210101) is generated automatically and could base on the same commits despite of different version string.
DEBs have ~~nightly_1 suffix in their names. RMPs have 0.2 suffix in their names.
dothebart commented
implemented.