-
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
Add CI for plugins #41
Conversation
Fix path includes not being packaged Package test plugins with releases Fix compilation for cbasenpc_example.sp Fix compilation warnings for baseanimatingoverlay.inc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Firstly, thank you for the fix.
Secondly, been thinking back and forth about this PR. And while I like having the plugins as part of the build script, I don't know if we need to split the pipeline between SM 1.11 and SM 1.12. This was a question I asked myself during #38
Sourcemod is by nature strongly backwards compatible when it comes to the plugins API, therefore it makes little sense to have a build line on both SM 1.11 and SM 1.12. If plugins build line succeed on SM 1.11 then it will also succeed on SM 1.12, we don't need to test it.
Thirdly, adding plugins to the CI means we shall add a 3rd job to the required workflows. And currently the naming of the job will fail us if SM ever gets to version 1.13 or later. I ask that the plugins build workflow is simply named SourcePawn CI / SM-Stable
providing a future proof workflow name for the required workflows.
Oh yeah, I wasn't entirely sure if compiling the plugins against SM's dev build was necessary as you mentioned backwards-compatibility and all. I can just have the CI compile against 1.11.
If the job names were hardcoded, yes. But the job name is based on the SM version that the SP compiler action was configured to use which would have to be manually updated in the future anyways. Updating the SM version will automatically update the job name too. |
Yes but that is exactly why I'm requesting to hardcode the job name. I want a non changing job name, so that the repository settings don't have to be changed. Just like currently the repo requires |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are almost there, if those if statements could be turned into functions of the class (much like versioning) this PR will be good to be merged.
Okay that makes sense. I thought you wanted the name change just for readability purposes, but since it's actually for a repository setting I understand why a static name is needed. Thanks for the clarification! In any case I've already changed the name, it should be |
This extends the CI to compile the test plugins. There was an issue with some includes not being packaged with the releases, so compilation of the test plugins should be able to catch this next time.
Changes: