> Did you try browser based auth (and authentication detection for that matter?).
> If you want to enable the AJAX SPider then browser based auth is probably the way to go - injecting session > state into browsers is very hard.
I did try the auto-detect auth and the browser based auth but what I remember it didn't just
work so that's why I settled for the form based auth, I'll give it another try later.
As of gitlab version 16.x, you cannot mount volumes to a services, this is a planned feature for 17.0.
See
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28121#note_1675743672For now you'll have to build a custom docker image that has all the files needed.
For the environment variables, it was my mistake you can just use a "variables" keyword and that does the trick.
I did see the delay job but once again the complexity is on the gitlab side.
With this job:
test-selenium-zap:
stage: acceptance
needs: ["deploy-prototype"]
services:
"-silent",
"-host",
"0.0.0.0",
"-port",
"8080",
"-config",
"
api.addrs.addr.name=.*",
"-config",
"api.addrs.addr.regex=true",
"-config",
"api.disablekey=true",
"-autorun",
"plan.yml"
]
script:
# Bunch of commands ....
# Below will run selenium test
- php vendor/bin/codecept run tests/acceptance
# Some curl command to tell zap to stop the delay job and carry on with the scan
- curl
http://zap/JSON/automation/action/endDelayJob # Then for the report, need to add a script job in the plan.yml that sends it via mail etc
# You could also enable the file transfer api, then this job could fetch it from the zap service and you could store the reports as a job artifact
https://docs.gitlab.com/ee/ci/jobs/job_artifacts.htmlEverything works as expected, except that we have like 300 tests running so it's taking a huge amount of time (20mn for the selenium tests then add 20mn for the passive/active scan of ZAP).
On a side note is this issue
https://github.com/zaproxy/zaproxy/issues/2157 still a thing? Can anyone who use this in CI share their experience?
One solution to reduce the amount of time our tests are taking are to parallelize them, in gitlab you do so with the keyword "parallel", here we will separate our tests in 5 groups, so it will be "parallel: 5"
test-selenium-zap:
stage: acceptance
needs: ["deploy-prototype"]
parallel: 5
services:
"-silent",
"-host",
"0.0.0.0",
"-port",
"8080",
"-config",
"
api.addrs.addr.name=.*",
"-config",
"api.addrs.addr.regex=true",
"-config",
"api.disablekey=true",
"-autorun",
"plan.yml"
]
script:
- >
./vendor/bin/codecept run -g paracept_$CI_NODE_INDEX
--xml
"report_selenium_firefox_testing-$CI_NODE_INDEX.xml"
--html
"report_selenium_firefox_testing-$CI_NODE_INDEX.html"
- curl
http://zap/JSON/automation/action/endDelayJobWhat will happen is that this job will actually be executed 5 times at the same time, so each job
will launch its own group of test and the first one that finishes will do the curl command to tell ZAP to continue with the scan.
And that's the problem with that parallel keyword, how can you make sure that ZAP only starts when all of the selenium tests are finished?
The only solution I can come up with consists of adding an "after_script" block and write a custom script that checks if the other jobs actually have finished their selenium tests and only then tell zap to continues.
However it feels very hacky and I should not have to do that, there must be a better solution but I haven't found it yet.
Right now I guess we could not use the parallel keyword and accept that this job will take +40mn and then run that job every night at 3AM or something.
Or just run it on a subset of our test.
Thoughts?