exchange_calendars: release.yml workflow failing to check new releases
The 4.0 release failed to import as a result of not including the sub-packages in the build (#203). My bad, although it should have been picked up by the release workflow.
The last job of the release workflow is to install and import the newly released version… https://github.com/gerrymanoim/exchange_calendars/blob/502280c1e0617974cb86804d314b9abf479d50ee/.github/workflows/release.yml#L45-L48 However, a look at the workflow logs shows that this job is actually installing and importing the prior version, not the new release. For example the log for the 3.6.3 release shows that the workflow actually installed / imported the prior 3.6.2 release.
In #206 I’ve explicitly defined the PyPI index that pip should install the package from (although not sure it’ll make any difference). Maybe it’s simply a matter of PyPI not having had a chance to publish the newly uploaded package?
What I’m struggling with even more is why the prior job which installed from the test PyPI repo also did not fail. https://github.com/gerrymanoim/exchange_calendars/blob/687f0657b6bb27bbe2c59f3aec1e50fe5ce60925/.github/workflows/release.yml#L33-L37 The log for the 4.0 release workflow seems to show that the version installed and imported was indeed 4.0, although if this were the case then why did it not fail and stop the workflow? (to be clear, it is not possible to install 4.0 from PyPI and import it - rather it fails as described in #203.)
What’s also odd is that it appears the Versioneer implementation is not working correctly (#205) in v4. However, the release workflow log shows that exchange_calendars__version__ prints as ‘4.0’ for the package as (supposedly) installed from both the test and the main PyPI repos. By all accounts this should have printed as ‘0+unknown’ given the bug with the Versioneer implementation.
Taking all the above together, it’s almost as if although the workflow is downloading and installing a version from PyPI, the version then being imported is a prior locally installed version. Not that I can’t see how that could happen?
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 20 (3 by maintainers)
Commits related to this issue
- Update release workflow Attempts fix for install and import checks (#207). — committed to gerrymanoim/exchange_calendars by maread99 2 years ago
- Update release workflow (#237) * Update release workflow - Attempts fix for install and import checks (#207). - Revises to wait for newly released version to appear in pip index before attemptin... — committed to gerrymanoim/exchange_calendars by maread99 2 years ago
4.5.2 did enter the loop and the workflow failed, regardless of the shell being defined as bash. (NB published to PyPI fine, just failed on the subsequent install and import check,)
Failed on the
((i++))line. Will change tolet i++, see if that makes any difference. (EDIT, tagged this change onto #361)🙏
Thanks for grabbing that release!
I think the issue could be that this is running in
shinstead ofbash. I think you’ll need something likei=$((i+1)). It seems it is a bit unclear exactly what shell you run in (https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell), but thei++syntax works for me locally in bash, but not insh.Can also try specifying the shell.
Workflow failed for release 4.3 in same manner as it failed on 4.2.8. (Again, the actual release was fine - checked manually.)
Going to add an echo to identify if failing on sleeping or the subsequent
((i++)).4.2.4 released as required (checked manually), although the workflow failed on the subsequent ‘Install and import’ job. The analogous job to check the upload to the test repo ran fine, and the same workflow has worked with market_prices. Although, on each of those occasions the workflow didn’t enter the while loop, which suggests a problem there - seems to have come unstuck on the first iteration or subsequent check of the while condition. @gerrymanoim - would you mind having a look at the loop and letting me know it anything’s immediately obvious to you?
I’m clearly missing something. Issue stays open☹️.
Hopefully resolved by #237.
Close if workflow releases next release (after 4.2.3) without a hitch.
Thank you for that @Stryder-Git. I was struggling yesterday to appreciate the need in your workflow for
pip install .. All clear now!I’ve had another bash at it (#237) based on your approach. I’ll merge it ahead of our next release and take it from there 🤞.
Cheers.
Hmm - that’s very weird. My guess would be that probably pypi hasn’t had enough time to process the package we published before we ask to install it?
Perhaps we should either:
github.refon the actions context to grab the version we want to install and force that constraint inpip install?