Skip judging parts of the integration tests. #2540
Conversation
|
Trying this as an alternative to #2531 which skips the integration tests all together. |
There was a problem hiding this comment.
I think any fix will do so lets merge first and afterwards try to get more back,
- We could check for cgroupv1 and if found still go on? I suspect they still have a fleet of older machines.
- We can see if we can get cgroupv1 back with
docker:dindas that might spin up a small vm. It does on macos/windows but I suspect it's smart enough to detect linux can already do cgroup on the host. - I think we can skip L92 & L136-148 and check the API there and even get a bit further, it would require also checking if we're cgroupv2, because if we're we will never get everything verified.
|
Good ideas, added the check and continued with everything that we could. |
| section_start check_cgroup_v1 "Checking for cgroup v1 availability" | ||
| grep cgroup$ /proc/filesystems | ||
| if [ $? -eq 0 ]; then | ||
| cgroupv1=1 |
There was a problem hiding this comment.
| cgroupv1=1 | |
| cgroupv=1 |
| cgroupv1=1 | ||
| else | ||
| echo "Skipping tests that rely on cgroup v1" | ||
| cgroupv1=0 |
There was a problem hiding this comment.
| cgroupv1=0 | |
| cgroupv=2 |
There was a problem hiding this comment.
I am testing for cgroup v1 ability, not v2 and using this is a boolean variable in the sense of "is cgroup v1 in the config we need it available" as this is what matters for the integration test.
| section_start judgehost "Configure judgehost" | ||
| cd /opt/domjudge/judgehost/ | ||
| sudo cp /opt/domjudge/judgehost/etc/sudoers-domjudge /etc/sudoers.d/ | ||
| sudo chmod 400 /etc/sudoers.d/sudoers-domjudge | ||
| sudo bin/create_cgroups | ||
| if [ $cgroupv1 -ne 0 ]; then |
There was a problem hiding this comment.
| if [ $cgroupv1 -ne 0 ]; then | |
| if [ $cgroupv -eq 1 ]; then |
| if [ $cgroupv1 -ne 0 ]; then | ||
| # We allow this to go wrong as some gitlab runners do not have the | ||
| # swapaccount kernel option set. | ||
| sudo bin/create_cgroups || cgroupv1=0 |
There was a problem hiding this comment.
| sudo bin/create_cgroups || cgroupv1=0 | |
| sudo bin/create_cgroups || cgroupv=0 |
The choice for cgroupv=0 is explicit here but I would argue that we should fail for this case? If the gitlab runners are inconsistent I would prefer that we fail get a retry on another runner.
Why can this fail on a machine with cgroupv1?
There was a problem hiding this comment.
See the comment text I added. They don't set swapaccount=1 as kernel option.
|
|
||
| section_start start_judging "Start judging" | ||
| cd /opt/domjudge/judgehost/ | ||
| if [ $cgroupv1 -ne 0 ]; then |
There was a problem hiding this comment.
| if [ $cgroupv1 -ne 0 ]; then | |
| if [ $cgroupv -eq 1 ]; then |
| sudo -u domjudge bin/judgedaemon $PINNING |& tee /tmp/judgedaemon.log & | ||
| sleep 5 | ||
| section_end start_judging | ||
| if [ $cgroupv1 -ne 0 ]; then |
There was a problem hiding this comment.
| if [ $cgroupv1 -ne 0 ]; then | |
| if [ $cgroupv1 -eq 1 ]; then |
gitlab/integration.sh
Outdated
| NUMSUBS=$(curl --fail http://admin:$ADMINPASS@localhost/domjudge/api/contests/1/submissions | python3 -mjson.tool | grep -c '"id":') | ||
|
|
||
| # Send a general clarification to later test if we see the event. | ||
| curl $CURLOPTS -F "sendto=" -F "problem=1-" -F "bodytext=Testing" -F "submit=Send" \ |
There was a problem hiding this comment.
| curl $CURLOPTS -F "sendto=" -F "problem=1-" -F "bodytext=Testing" -F "submit=Send" \ | |
| curl $CURLOPTS -F "sendto=" -F "problem=1-" -F "bodytext=Testing" -F "submit=Send" \ |
Like a said, we can test this with the evenfeed still if its received.
There was a problem hiding this comment.
GitHub (and I) don't see any changes suggested here. But I assume I addressed the suggestion anyway by moving it outside of the if.
This is unfortunate but gitlab seems to have enabled cgroups v2 on their runners and we still use cgroups v1, see DOMjudge#1072
|
I merged it now to make CI green again. We can always improve things on top of it |
This is unfortunate but gitlab seems to have enabled cgroups v2 on their runners and we still use cgroups v1, see #1072