-
Notifications
You must be signed in to change notification settings - Fork 8k
Verify bundled sources using CI - PCRE2 & SLJIT #20354
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
base: master
Are you sure you want to change the base?
Conversation
| cp -R /tmp/php-src-bundled/pcre2/src ext/pcre/pcre2lib | ||
|
|
||
| cd ext/pcre/pcre2lib | ||
| git restore config.h |
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.
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.
There is no exact procedure as files get added and removed in the library. It mainly consists of copying over the c and h files,sometimes updating the config files, applying the diff of pcre.h, and updating the sljit includes so that it includes from the right location.
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.
Please review, I reverse-engineered the patches.
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.
I'm fine with this, as this is right from a technical PoV, but deferring the action workflow judgement to @TimWolla / @iluuu1994
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.
I don't have strong opinions on this. I think it would be better if these files lived outside of .github and also helped updating the libraries themselves (i.e. downloading some revision, updating the hash somewhere, applying the patches, etc.). But I don't maintain any parts of PHP with external code that is pulled in, so I'll defer to those people whether that's actually necessary.
| @@ -0,0 +1,13 @@ | |||
| diff --git a/ext/pcre/pcre2lib/pcre2_jit_compile.c b/ext/pcre/pcre2lib/pcre2_jit_compile.c | |||
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 have some existing patch files, e.g. ext/fileinfo/libmagic.patch. They should live in a consistent place. Not necessarily the same place, just consistent.
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.
Yes, to be consistent.
I personally prefer to keep it here for now as there are dozens of bundled sources and maintaining the update files is much easier if they are kept at shared place.
| name: Verify Bundled Files | ||
|
|
||
| on: | ||
| push: |
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 should only run this when the files have actually changed. https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore
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.
This is per workflow, not per step. It is however handled using dorny/paths-filter@v3 step. The workflow will skip all downloads if nothing has changed.
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.
in that case, I assume the intention is that this workflow will be used for other bundled files, in which case the VERIFY_BUNDLED_FILES job should be renamed to maybe VERIFY_BUNDLED_PCRE2 or something? If there will be multiple jobs, the job name should match what is tested, and if there is only one job, then we can apply the filter for the overall workflow
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.
see https://github.com/mvorisek/php-src/blob/778cf78cdbf1be73f63889e518f78e4d89a8b71d/.github/workflows/verify-bundled-files.yml#L32-L38 for added bundle - not a separate workflow/job, but instead of separate step (2 steps) to safe CI resources.
| set -ex | ||
| cd "$(dirname "$0")/../../.." | ||
|
|
||
| commit=b2bd4254b379b9d7dc9a3dda060a7e27009ccdff # 10.46 release |
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.
Why not use the tag? This is more self-documenting.
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.
I like it 👍
| rm pcre2test.c | ||
|
|
||
| # move renamed files | ||
| mv config.h.generic config.h |
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.
what is the point of moving a file into config.h just to restore the original one that was in git via git restore config.h down below - why not just rm config.h.generic entirely, and document that config.h is not something that is bundled and so should not be used for the comparison?
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.
I designed it this way. The actual git restore config.h command is the one that can be removed in the future. The config.h is currently very out of sync with config.h.generic but that is because a lot of lines are commented out, so the real patch should not be that big...
| git status | ||
|
|
||
| # display & detect all changes | ||
| git add . -N && git diff --cached -a --exit-code . && git diff -a --exit-code . |
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.
the existing workflow to verify generated files uses git add . -N && git diff -a --exit-code - here you use something different. If this is more correct, we should update that, but if not I suggest we match
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.
I updated the "verify generated files" and deduplicated it.
| name: Verify Bundled Files | ||
|
|
||
| on: | ||
| push: |
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.
in that case, I assume the intention is that this workflow will be used for other bundled files, in which case the VERIFY_BUNDLED_FILES job should be renamed to maybe VERIFY_BUNDLED_PCRE2 or something? If there will be multiple jobs, the job name should match what is tested, and if there is only one job, then we can apply the filter for the overall workflow
initial PR of #19802
The new CI asserts all bundled files are up-to-date and the CI code also provides trusted documentation of how the bundled deps were added.
On push/PR the CI is run only if the bundled files were changed.
The CI is based on shell scripts that can be easily modified for upgrade and run localy.