-
Notifications
You must be signed in to change notification settings - Fork 112
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
dynamically set build version using current git tag/shorthash #538
Conversation
Will have to check on that, but may have to be a different car as we need a version number in there for the official releases and that version number needs to be there before the tag (ideally), see https://github.com/OpenEVSE/ESP32_WiFi_V4.x/blob/master/docs/process.md. I am not opposed to changing the process, but it is critical that there is no rebuild after testing, and ideally I don't want to increase the version number after a testing failure and multiple builds with the same version number would defeat the purpose of the PR. |
works ok |
we've cross posted, I've pushed a change. |
Looks to work, please update the process docs and you will probably need to update the release validation workflow. Remember it is very important that their is no rebuild after testing, ie the tag has to be created before testing which will then create the release build and the testing will be done on that. What is the expected flow should the testing find an issue? |
I did the changes, but please check that it doesn't mess up before as I'm no expert in dev op github action |
@KipK I have not forgotten about this, I am just trying to figure out how best to work this into the release process |
Also includes uploading v1 GUI binaries to the `latest` release and v2 GUI to the v2 GUI pre-release.
if it's a realease tag, should name it normally with release name ( i.e 4.1.7 ) , if not, it display the current tag
Will stop confusion displaying always the same version when developping