-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mismatch between Helm and Python versioning schemes #411
Comments
The current state of this is that the PyPI GH action will convert a sem ver tag to a PEP 440 compliant release. There was some discussion about converting the copier template to enforce a sem ver version however it was decided that this requirement is a special case and should not be the norm as most projects will likely only need/want to be PEP 440 compliant. Therefore we should be able to use sem ver tags for releases and everything should work but this should probably be documented within this project. Additionally it might be possible to validate this before the release tasks are performed using an action but I haven't explored this yet. |
I think it's worth documenting higher up, this is a special case but not that special. It's a Copier project with a helm chart, I suspect there will be more than a few of those. Tagging @coretl and @gilesknap for opinions |
Tom and I discussed this. We thought about enforcing use of semver in copier but decided that was confusing to the majority pure python projects. Its a gotcha that is hard to know where to flag. Perhaps we could add a question in copier. Asking if you will be deploying things other than python packages(such as helm) and add in semvar enforcement in the CI if the answer is yes. (The question could highlight the need for semvar in this case too) |
I think if we add helm chart as an option to the copier template then we should do this, and I'd like to see some more usecases for python project with a helm chart in it before we do that. Do we have any apart from blueapi? |
Presumably any Python backend web service eventually? Adding helm to the copier template might create more awkward than its worth. There are lots of different types of helm template - REST service, epics service etc. so constraining it it seems counterproductive. |
I'm not convinced that there will be any epics services, we use I think we should defer this until we have a second example to look at... |
This is now a blocking concern, has there been any progress on it? |
@callumforrester I think there is a simple answer which I now realize has not been highlighted in the comments on this issue. Just use semver for this repo. Helm will be happy and pypi publishing will automatically convert it to PEP440. I have verified the latter here:
If you want to put in a check into blueapi CI to tell you you have made a bad version then I think that should be a custom change to blueapi itself because we think in general this would be a confusing thing for users of python copier template who just want python packages published. What do you think? |
Maybe rather than doing the check which is just another way of failing the CI we could have a troubleshooting section in the docs that says if you are making a beta and this happens then ... |
We've just made a release of blueapi too to check this works ( For reference: the version conversion happens when the wheel is built in
I think we want some check to prevent the case where publishing may succeed to one service but fail on others (as can currently happen). Then we should add versioning info to this project's docs. |
@coretl so here we have a working solution for pypi and helm, feels reasonably to move to a copier template issue at this point? |
I'm still waiting for the second example to look at... Has this popped up anywhere apart from blueapi? |
I presume it would happen if we ever did an alpha release of https://github.com/DiamondLightSource/diffcalc-api |
Is there anything that stops you making a GitHub release if it doesn't conform to a regex then? |
Not sure, that would be ideal. If not, another option is to prevent the release pipeline from triggering unless it conforms to a regex. Then the release just appears in the GH release history and you can yank it when you realise you've got it wrong. |
have we had any issues with this around the 0.5.0 release? I think not, @callumforrester , maybe this can be closed |
@stan-dot There are no issues because we know how to avoid them (tag releases with |
related issue |
@joeshannon I'm having issues trying to replicate this |
I think we can solve this with tag rulesets: https://docs.github.com/en/[email protected]/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules I will experiment with it at some point, documenting it here in case anyone else has time sooner than me. |
|
this should work, but I don't have the permissions
to match the dash and this, I think:
|
I had a play with that, update on how far I got:
|
When creating, for example, an alpha release using a verion name compatible with the Python Packaging User Guide such as
0.4.1a1
the current CI for publishing the helm chart uses${GITHUB_REF##*/}
as the appVersion.This is rejected by helm/the repository with:
Helm uses Sem Ver 2.0.
There is a library which could help https://python-semver.readthedocs.io/en/latest/advanced/convert-pypi-to-semver.html but other solutions might be preferred or easier.
The text was updated successfully, but these errors were encountered: