-
Notifications
You must be signed in to change notification settings - Fork 51
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
Provide a script to allow users to generate the single header from the current code, without doing a release #184
Comments
Hello, thanks for the message. I’m intrigued to know what problem you are solving - in case it gives ideas for other solutions? We have a bit of an overview of the release process here ... https://github.com/approvals/ApprovalTests.cpp/blob/master/build/HowToRelease.md ... essentially it’s a big ball of Python that goes through a lot of steps, including converting that header you’ve been able to generate into a standalone file, that has no references to any headers inside this project. An end-user wouldn’t be able to easily run our release scripts directly, as there is a whole bunch of other steps that get done, like testing updating of Conan info... I can’t make any promises about timescales, but I would think that I could extract some of the code out, and create a second script - perhaps called something like “create_standalone_single_header_file.py” That is already done as part of our Python unit tests - albeit in a test that is often disabled. |
Hi Clare |
Thanks - it's one of the tests that was disabled in this commit: Probably Current code: One issue with making a generic script from this is that the code currently creates a file with a version number in the name... If we were to have a script that produced the single header from current code, it shouldn't have a version number in the file name. Current thought: I think the simplest thing would be for the standalone script to write its output to stdout, then callers could redirect it to wherever they wanted to save the output... PR very welcome! |
FYI When we change this code, we temporarily re-enable the locking tests and save their output.... Then change the code... Then re-disable the locking tests... |
I guess the other thing to work out will be what to put in the version-number section of the output file. |
Hello, #! /usr/bin/env python3
import os
from scripts.code_generation import CppGeneration
from scripts.project_details import ProjectDetails
from scripts.release_details import ReleaseDetails
from scripts.single_header_file import SingleHeaderFile
from scripts.release_constants import release_constants
from scripts.version import Version
if __name__ == '__main__':
os.chdir(os.path.join("..", "ApprovalTests"))
current_version = Version.read(release_constants.build_dir)
deploy = False
conan_release = False
release_details = ReleaseDetails(current_version, current_version, deploy, ProjectDetails(), conan_release)
cpp_generation = CppGeneration(release_details)
cpp_generation.prepare_release(release_details) and for the ReleaseDetails init, it has the additional boolean ", conan_release: bool=True" where it skips the initialization of conan_details. I had an additional commit to output and return the content of the header file but its not needed since its generating the output under build/releases which is fine. Let me know if the above approach is fine. |
Hi, thanks very much for this. I can confirm that the new script does generate a release file in the build/ directory, which is great... However, it has the same file-name as the last release, and contains the same version number as the last release... This is misleading - it will risk confusing users, and will confuse us in user support - when someone says that are using "v.10.9.1" but in fact they are using modified source code, picking up any changes that we made since the last release. This is why I was preferring that the file was written to standard output, so it didn't need to have a version number in the filename - and the user could decide. As for the version number inside the contents of the file, I'll have a chat with @isidore and see if we can come up with any ideas... Perhaps including the git id/hash in the version number. It's really close, and thank you very much for doing this... I'm sure we'll find a way forward... |
Hello,
... Feel free to choose the way that suits you best, |
Hi @asreih, Sorry, I don't really understand the formatting of the code in your previous example. I do like that idea of adding "-snapshot" - if it were possible to add this to the version, then it would be included in both the header and the filename, and work really well. It doesn't work right now - I tried adding it... release_details = ReleaseDetails(current_version, current_version, deploy, ProjectDetails(), conan_release)
+ release_details.new_version.patch += "-snapshot" ... and got this error:
So the version class would need to be changed to support a 4th field, which is an optional extra string... I've got a conference talk coming up, so am definitely not going to be able to do this right now... It sounds to me like you've got something that works for you, for now ... So I'll try to pick this up after the start of July... Thanks for the suggestion, and the proposed implementation - really helpful, and greatly appreciated! |
Hello,
I have a question on how the single header file is being generated inside the release process,
Basically if I only want to generate the single header file, it's including all the headers with their cpps inside "ApprovalTests.cpp/ApprovalTests/ApprovalTests.hpp" when using "create_simulated_single_header_file.py" with the parameter include cpps as true. I am aiming on having the output of the releases where the includes are replaced with the content of the headers/cpp, how can it be done automatically ?
Many thanks in advance for your response,
Regards,
The text was updated successfully, but these errors were encountered: