Main issue:
Version 1.4.2 could not be deployed to anaconda on the tagged build
The script failed with exit status 127
I don't know what it corresponds to but I notice that at least 1 environment variable used in the anaconda_upload.sh script is not defined: $PKG_DIR
In previous versions (1.4.1) it was defined in install section as:
export PKG_DIR=$HOME/miniconda/conda-bld/linux-64/
I suspect this is the cause of the issue.
Other remarks:
-
Looking at the build log, it seems that the section before_deploy is run not just once but once before each deployment.
=> As a result the conda build conda_recipe is run everytime, even for pip sdist deployment, this takes a lot of time. I suggest moving this to section after_success to make sure it is run only once.
-
The version number in tofu/version.py had to be forced by hand
Indeed, the automated update in install section (export REV=$(python -c "import _updateversion as up; out=up.updateversion(); print(out)")) does ot seem to apply at deployment.
I mean that the variable REV is ok, but the version number taken at pipy deployment seems to be not $REV but instead read from tofu/version.py before it was updated by the line above. This suggest that at deployment time, travis re-clones the github repo instead of using the local tofu.
-
Apparently the deployment was also done on test-pypi despite the fact I pushed on master and not on test-deploy. My interpretation: I think that a tag in git is not just a commit. When we create a tag, git creates a dedicated branch. The tag is a branch itself. So when travis sees there is a tag, maybe it does not check the branch.
Highest priority:
- fix anaconda_upload.sh (deployment today early afternoon if possible)
- Fix multiple
conda build conda_recipe to save time (should be easy)
Lowest priority:
- tofu version update: we can work like this: i.e. by forcing version by hand for 1.4.2, but it would be nice to fix it somehow for the next release 1.4.3 (probably a bit tricky and time-consuming, so no need to do it now)
- Clarify tag vs branch condition in travis (master vs deploy-test)
Tip:
@lasofivec , I had to make several tries, if necessary you can work directly on master
If necessary, you can re-deploy the same tga by deleting the existing tag locally, pushing the deletion to the remote, committing changes, and re-tagging and re-pushing tags:
Delete tag locally and push deletion
git tag -d 1.4.2
git push origin :refs/tags/1.4.2
... commit changes...
Re-tag and push tags
git tag -a 1.4.2 -m "Tracing Quinoa: python 2.7 support dropped, new configurations, more portable, faster, better IMAS interface, basic reflections, more documented, 2D X ray spectrometers basics..."
git push origin master --tags
Main issue:
Version 1.4.2 could not be deployed to anaconda on the tagged build
The script failed with exit status 127
I don't know what it corresponds to but I notice that at least 1 environment variable used in the anaconda_upload.sh script is not defined: $PKG_DIR
In previous versions (1.4.1) it was defined in install section as:
export PKG_DIR=$HOME/miniconda/conda-bld/linux-64/I suspect this is the cause of the issue.
Other remarks:
Looking at the build log, it seems that the section before_deploy is run not just once but once before each deployment.
=> As a result the
conda build conda_recipeis run everytime, even for pip sdist deployment, this takes a lot of time. I suggest moving this to section after_success to make sure it is run only once.The version number in tofu/version.py had to be forced by hand
Indeed, the automated update in install section (
export REV=$(python -c "import _updateversion as up; out=up.updateversion(); print(out)")) does ot seem to apply at deployment.I mean that the variable REV is ok, but the version number taken at pipy deployment seems to be not $REV but instead read from tofu/version.py before it was updated by the line above. This suggest that at deployment time, travis re-clones the github repo instead of using the local tofu.
Apparently the deployment was also done on test-pypi despite the fact I pushed on master and not on test-deploy. My interpretation: I think that a tag in git is not just a commit. When we create a tag, git creates a dedicated branch. The tag is a branch itself. So when travis sees there is a tag, maybe it does not check the branch.
Highest priority:
conda build conda_recipeto save time (should be easy)Lowest priority:
Tip:
@lasofivec , I had to make several tries, if necessary you can work directly on master
If necessary, you can re-deploy the same tga by deleting the existing tag locally, pushing the deletion to the remote, committing changes, and re-tagging and re-pushing tags:
Delete tag locally and push deletion
... commit changes...
Re-tag and push tags