-
Notifications
You must be signed in to change notification settings - Fork 130
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
regenerate internals in pipeline #341
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@locka99 Hey there,
first of all thanks for all the effort you've put into this project over the last years.
It appears to save me quite some time not needing to write an FFI for a cpp OPC UA library and hope you don't mind me rampaging through this project instead :S
Refactoring small stuff helps me figuring out how the project fits together;
one thing I'm currently having trouble wrapping my head around is how and when the five schema helpersupdate
I found they were all formatted and added the five respective PRs with necessary minor fixes below.
gen_address_space
ci: Regenerate and verify the address space files #348gen_node_ids
ci: Regenerate and verify the node ids file #351gen_status_codes
ci: Regenerate and verify the status codes file #344gen_supported_message
ci: Regenerate and verify the supported messages file #347 andgen_types
ci: Regenerate and verify the types files #350are invoked to match the current code committed.I suppose it should be a clean diff, when I regenerate and format the output?
If so I'd suggest (and eventually implement) a GitHub workflow, which regenerates the files and makes sure they do not change in order to tie the generators to the rest of the codebase?
This might furthermore help preventing unwanted fixes in generated code, which I might very well tripped in my open PRs.
I understand this is your freetime project? The open PRs are not meant as nudging, they only come in a bunch as I'll have more time to work on this in this week than usually. Sorry for all the buzz.
The text was updated successfully, but these errors were encountered: