feat: add 'make test' to v2's workflow #3379
Conversation
| @@ -74,3 +74,39 @@ jobs: | |||
| - name: Show mod_security2 audit log | |||
| if: always() | |||
| run: sudo cat /var/log/apache2/modsec_audit.log | |||
There was a problem hiding this comment.
Run the build job until make install, then reuse the artefacts for building and testing. Don't build the artefacts twice.
There was a problem hiding this comment.
You mean I should insert the rebuild module and make install part between install module and prepare config steps? (After line 40)
If yes, then that has one advantage: we do not run twice almost the whole process, and one disadvantage: in case of error we have to open the GH log. Now we can see the name of the task, eg.
test-linux (ubuntu-22.04, x32, gcc, with pcre, no study, no jit, --enable-pcre-study=no)
vs.
build-linux (ubuntu-22.04, x32, gcc, with pcre, no study, no jit, --enable-pcre-study=no)
(the whole list is here).
There was a problem hiding this comment.
and one disadvantage: in case of error we have to open the GH log
I don't see that as an issue.
I would continue to use two jobs. Upload the build output from the build job and then download it for the test job: https://docs..com/en/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow#passing-data-between-jobs-in-a-workflow.
There was a problem hiding this comment.
Sorry, I don't understand this:
Upload the build output from the build job and then download it for the test job
We definitely must rebuild again with different configure arguments (namely without --enable-assertions), so if you take a look at line 35 and line 105, you can see that from that point the two jobs are different. We can save (and upload) available data till that point - which (I guess) makes no sense.
| run: ./autogen.sh | ||
| - name: configure ${{ matrix.configure.label }} | ||
| run: ./configure ${{ matrix.configure.opt }} 'CFLAGS=-Werror=format-security' | ||
| - uses: ammaraskar/gcc-problem-matcher@master |
There was a problem hiding this comment.
| - uses: ammaraskar/gcc-problem-matcher@master | |
| - uses: ammaraskar/gcc-problem-matcher@0f9c86f9e693db67dacf53986e1674de5f2e5f28 # ratchet:ammaraskar/[email protected] |
| run: | | ||
| sudo apt-get update -y -qq | ||
| sudo apt-get install -y apache2-dev libxml2-dev liblua5.1-0-dev libcurl4-gnutls-dev libpcre2-dev pkg-config libyajl-dev apache2 apache2-bin apache2-data | ||
| - uses: actions/checkout@v2 |
There was a problem hiding this comment.
| - uses: actions/checkout@v2 | |
| - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # ratchet:actions/checkout@v4 |
…d packages Co-authored-by: Felipe Zipitría <[email protected]>
Sorry to ask, what is the advantage of using this form? Why isn't good to use the current |
Supply chain attacks? See: |
Thanks. If I'm right, if we use hash's then we should have to care with new releases. I think this PR is outside of this, so can we skip this change now? Later I try to align these as you suggested with other necessary configuration. |
Sounds good. Renovatebot can take care of that, let's do it in a different pr then. |
what
This PR adds mod_security2 module's own test cases to the GH workflow.
The new job uses the same matrix as the existing one, but we can't use
--enable-assertionsconfigure option (which is important with the valid configuration, where we do not use invalid values), because then the test cases which check invalid values would throw an assert error.why
The module's
make testscommand hasn't been working for some time, because the PCRE2 modifications weren't applied that code. With some recent PR's those part of code were aligned, somake testworks again.