2020-05-03 02:31:50 -04:00
|
|
|
name: Daily
|
|
|
|
|
|
|
|
|
|
on:
|
2020-07-20 06:57:54 -04:00
|
|
|
pull_request:
|
|
|
|
|
branches:
|
|
|
|
|
# any PR to a release branch.
|
|
|
|
|
- '[0-9].[0-9]'
|
2020-05-03 02:31:50 -04:00
|
|
|
schedule:
|
2020-07-12 06:55:26 -04:00
|
|
|
- cron: '0 0 * * *'
|
2021-06-22 10:23:59 -04:00
|
|
|
workflow_dispatch:
|
|
|
|
|
inputs:
|
2021-06-23 15:13:24 -04:00
|
|
|
skipjobs:
|
2021-07-05 01:46:19 -04:00
|
|
|
description: 'jobs to skip (delete the ones you wanna keep, do not leave empty)'
|
Fix some compile warnings and errors when building with gcc-12 or clang (#12035)
This PR is to fix the compilation warnings and errors generated by the latest
complier toolchain, and to add a new runner of the latest toolchain for daily CI.
## Fix various compilation warnings and errors
1) jemalloc.c
COMPILER: clang-14 with FORTIFY_SOURCE
WARNING:
```
src/jemalloc.c:1028:7: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation]
"/etc/malloc.conf",
^
src/jemalloc.c:1027:3: note: place parentheses around the string literal to silence warning
"\"name\" of the file referenced by the symbolic link named "
^
```
REASON: the compiler to alert developers to potential issues with string concatenation
that may miss a comma,
just like #9534 which misses a comma.
SOLUTION: use `()` to tell the compiler that these two line strings are continuous.
2) config.h
COMPILER: clang-14 with FORTIFY_SOURCE
WARNING:
```
In file included from quicklist.c:36:
./config.h:319:76: warning: attribute declaration must precede definition [-Wignored-attributes]
char *strcat(char *restrict dest, const char *restrict src) __attribute__((deprecated("please avoid use of unsafe C functions. prefer use of redis_strlcat instead")));
```
REASON: Enabling _FORTIFY_SOURCE will cause the compiler to use `strcpy()` with check,
it results in a deprecated attribute declaration after including <features.h>.
SOLUTION: move the deprecated attribute declaration from config.h to fmacro.h before "#include <features.h>".
3) networking.c
COMPILER: GCC-12
WARNING:
```
networking.c: In function ‘addReplyDouble.part.0’:
networking.c:876:21: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
876 | dbuf[start] = '$';
| ^
networking.c:868:14: note: at offset -5 into destination object ‘dbuf’ of size 5152
868 | char dbuf[MAX_LONG_DOUBLE_CHARS+32];
| ^
networking.c:876:21: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
876 | dbuf[start] = '$';
| ^
networking.c:868:14: note: at offset -6 into destination object ‘dbuf’ of size 5152
868 | char dbuf[MAX_LONG_DOUBLE_CHARS+32];
```
REASON: GCC-12 predicts that digits10() may return 9 or 10 through `return 9 + (v >= 1000000000UL)`.
SOLUTION: add an assert to let the compiler know the possible length;
4) redis-cli.c & redis-benchmark.c
COMPILER: clang-14 with FORTIFY_SOURCE
WARNING:
```
redis-benchmark.c:1621:2: warning: embedding a directive within macro arguments has undefined behavior [-Wembedded-directive] #ifdef USE_OPENSSL
redis-cli.c:3015:2: warning: embedding a directive within macro arguments has undefined behavior [-Wembedded-directive] #ifdef USE_OPENSSL
```
REASON: when _FORTIFY_SOURCE is enabled, the compiler will use the print() with
check, which is a macro. this may result in the use of directives within the macro, which
is undefined behavior.
SOLUTION: move the directives-related code out of `print()`.
5) server.c
COMPILER: gcc-13 with FORTIFY_SOURCE
WARNING:
```
In function 'lookupCommandLogic',
inlined from 'lookupCommandBySdsLogic' at server.c:3139:32:
server.c:3102:66: error: '*(robj **)argv' may be used uninitialized [-Werror=maybe-uninitialized]
3102 | struct redisCommand *base_cmd = dictFetchValue(commands, argv[0]->ptr);
| ~~~~^~~
```
REASON: The compiler thinks that the `argc` returned by `sdssplitlen()` could be 0,
resulting in an empty array of size 0 being passed to lookupCommandLogic.
this should be a false positive, `argc` can't be 0 when strings are not NULL.
SOLUTION: add an assert to let the compiler know that `argc` is positive.
6) sha1.c
COMPILER: gcc-12
WARNING:
```
In function ‘SHA1Update’,
inlined from ‘SHA1Final’ at sha1.c:195:5:
sha1.c:152:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 [-Wstringop-overread]
152 | SHA1Transform(context->state, &data[i]);
| ^
sha1.c:152:13: note: referencing argument 2 of type ‘const unsigned char[64]’
sha1.c: In function ‘SHA1Final’:
sha1.c:56:6: note: in a call to function ‘SHA1Transform’
56 | void SHA1Transform(uint32_t state[5], const unsigned char buffer[64])
| ^
In function ‘SHA1Update’,
inlined from ‘SHA1Final’ at sha1.c:198:9:
sha1.c:152:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 [-Wstringop-overread]
152 | SHA1Transform(context->state, &data[i]);
| ^
sha1.c:152:13: note: referencing argument 2 of type ‘const unsigned char[64]’
sha1.c: In function ‘SHA1Final’:
sha1.c:56:6: note: in a call to function ‘SHA1Transform’
56 | void SHA1Transform(uint32_t state[5], const unsigned char buffer[64])
```
REASON: due to the bug[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922], when
enable LTO, gcc-12 will not see `diagnostic ignored "-Wstringop-overread"`, resulting in a warning.
SOLUTION: temporarily set SHA1Update to noinline to avoid compiler warnings due
to LTO being enabled until the above gcc bug is fixed.
7) zmalloc.h
COMPILER: GCC-12
WARNING:
```
In function ‘memset’,
inlined from ‘moduleCreateContext’ at module.c:877:5,
inlined from ‘RM_GetDetachedThreadSafeContext’ at module.c:8410:5:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59:10: warning: ‘__builtin_memset’ writing 104 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
59 | return __builtin___memset_chk (__dest, __ch, __len,
```
REASON: due to the GCC-12 bug [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503],
GCC-12 cannot see alloc_size, which causes GCC to think that the actual size of memory
is 0 when checking with __glibc_objsize0().
SOLUTION: temporarily set malloc-related interfaces to `noinline` to avoid compiler warnings
due to LTO being enabled until the above gcc bug is fixed.
## Other changes
1) Fixed `ps -p [pid]` doesn't output `<defunct>` when using procps 4.x causing `replication
child dies when parent is killed - diskless` test to fail.
2) Add a new fortify CI with GCC-13 and ubuntu-lunar docker image.
2023-04-18 02:53:51 -04:00
|
|
|
default: 'valgrind,sanitizer,tls,freebsd,macos,alpine,32bit,iothreads,ubuntu,centos,malloc,specific,fortify,reply-schema'
|
2021-06-23 15:13:24 -04:00
|
|
|
skiptests:
|
2021-07-05 01:46:19 -04:00
|
|
|
description: 'tests to skip (delete the ones you wanna keep, do not leave empty)'
|
2022-02-13 10:43:19 -05:00
|
|
|
default: 'redis,modules,sentinel,cluster,unittest'
|
2021-06-22 10:23:59 -04:00
|
|
|
test_args:
|
|
|
|
|
description: 'extra test arguments'
|
|
|
|
|
default: ''
|
|
|
|
|
cluster_test_args:
|
|
|
|
|
description: 'extra cluster / sentinel test arguments'
|
|
|
|
|
default: ''
|
2021-06-23 15:13:24 -04:00
|
|
|
use_repo:
|
|
|
|
|
description: 'repo owner and name'
|
|
|
|
|
default: 'redis/redis'
|
|
|
|
|
use_git_ref:
|
|
|
|
|
description: 'git branch or sha to use'
|
|
|
|
|
default: 'unstable'
|
2021-06-22 10:23:59 -04:00
|
|
|
|
2020-05-03 02:31:50 -04:00
|
|
|
|
|
|
|
|
jobs:
|
2020-05-24 01:00:12 -04:00
|
|
|
|
2020-07-30 06:25:10 -04:00
|
|
|
test-ubuntu-jemalloc:
|
2020-05-03 02:31:50 -04:00
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'ubuntu')
|
2020-07-12 06:55:26 -04:00
|
|
|
timeout-minutes: 14400
|
2020-05-03 02:31:50 -04:00
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2020-05-03 02:31:50 -04:00
|
|
|
- name: make
|
2021-03-10 02:13:11 -05:00
|
|
|
run: make REDIS_CFLAGS='-Werror -DREDIS_TEST'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: sudo apt-get install tcl8.6 tclx
|
2020-05-03 02:31:50 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-05-03 02:31:50 -04:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-09 15:37:18 -05:00
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-07-12 06:55:26 -04:00
|
|
|
- name: sentinel tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2020-07-12 06:55:26 -04:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
2021-03-10 02:13:11 -05:00
|
|
|
- name: unittest
|
2022-02-13 10:43:19 -05:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'unittest')
|
Fix some compile warnings and errors when building with gcc-12 or clang (#12035)
This PR is to fix the compilation warnings and errors generated by the latest
complier toolchain, and to add a new runner of the latest toolchain for daily CI.
## Fix various compilation warnings and errors
1) jemalloc.c
COMPILER: clang-14 with FORTIFY_SOURCE
WARNING:
```
src/jemalloc.c:1028:7: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation]
"/etc/malloc.conf",
^
src/jemalloc.c:1027:3: note: place parentheses around the string literal to silence warning
"\"name\" of the file referenced by the symbolic link named "
^
```
REASON: the compiler to alert developers to potential issues with string concatenation
that may miss a comma,
just like #9534 which misses a comma.
SOLUTION: use `()` to tell the compiler that these two line strings are continuous.
2) config.h
COMPILER: clang-14 with FORTIFY_SOURCE
WARNING:
```
In file included from quicklist.c:36:
./config.h:319:76: warning: attribute declaration must precede definition [-Wignored-attributes]
char *strcat(char *restrict dest, const char *restrict src) __attribute__((deprecated("please avoid use of unsafe C functions. prefer use of redis_strlcat instead")));
```
REASON: Enabling _FORTIFY_SOURCE will cause the compiler to use `strcpy()` with check,
it results in a deprecated attribute declaration after including <features.h>.
SOLUTION: move the deprecated attribute declaration from config.h to fmacro.h before "#include <features.h>".
3) networking.c
COMPILER: GCC-12
WARNING:
```
networking.c: In function ‘addReplyDouble.part.0’:
networking.c:876:21: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
876 | dbuf[start] = '$';
| ^
networking.c:868:14: note: at offset -5 into destination object ‘dbuf’ of size 5152
868 | char dbuf[MAX_LONG_DOUBLE_CHARS+32];
| ^
networking.c:876:21: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
876 | dbuf[start] = '$';
| ^
networking.c:868:14: note: at offset -6 into destination object ‘dbuf’ of size 5152
868 | char dbuf[MAX_LONG_DOUBLE_CHARS+32];
```
REASON: GCC-12 predicts that digits10() may return 9 or 10 through `return 9 + (v >= 1000000000UL)`.
SOLUTION: add an assert to let the compiler know the possible length;
4) redis-cli.c & redis-benchmark.c
COMPILER: clang-14 with FORTIFY_SOURCE
WARNING:
```
redis-benchmark.c:1621:2: warning: embedding a directive within macro arguments has undefined behavior [-Wembedded-directive] #ifdef USE_OPENSSL
redis-cli.c:3015:2: warning: embedding a directive within macro arguments has undefined behavior [-Wembedded-directive] #ifdef USE_OPENSSL
```
REASON: when _FORTIFY_SOURCE is enabled, the compiler will use the print() with
check, which is a macro. this may result in the use of directives within the macro, which
is undefined behavior.
SOLUTION: move the directives-related code out of `print()`.
5) server.c
COMPILER: gcc-13 with FORTIFY_SOURCE
WARNING:
```
In function 'lookupCommandLogic',
inlined from 'lookupCommandBySdsLogic' at server.c:3139:32:
server.c:3102:66: error: '*(robj **)argv' may be used uninitialized [-Werror=maybe-uninitialized]
3102 | struct redisCommand *base_cmd = dictFetchValue(commands, argv[0]->ptr);
| ~~~~^~~
```
REASON: The compiler thinks that the `argc` returned by `sdssplitlen()` could be 0,
resulting in an empty array of size 0 being passed to lookupCommandLogic.
this should be a false positive, `argc` can't be 0 when strings are not NULL.
SOLUTION: add an assert to let the compiler know that `argc` is positive.
6) sha1.c
COMPILER: gcc-12
WARNING:
```
In function ‘SHA1Update’,
inlined from ‘SHA1Final’ at sha1.c:195:5:
sha1.c:152:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 [-Wstringop-overread]
152 | SHA1Transform(context->state, &data[i]);
| ^
sha1.c:152:13: note: referencing argument 2 of type ‘const unsigned char[64]’
sha1.c: In function ‘SHA1Final’:
sha1.c:56:6: note: in a call to function ‘SHA1Transform’
56 | void SHA1Transform(uint32_t state[5], const unsigned char buffer[64])
| ^
In function ‘SHA1Update’,
inlined from ‘SHA1Final’ at sha1.c:198:9:
sha1.c:152:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 [-Wstringop-overread]
152 | SHA1Transform(context->state, &data[i]);
| ^
sha1.c:152:13: note: referencing argument 2 of type ‘const unsigned char[64]’
sha1.c: In function ‘SHA1Final’:
sha1.c:56:6: note: in a call to function ‘SHA1Transform’
56 | void SHA1Transform(uint32_t state[5], const unsigned char buffer[64])
```
REASON: due to the bug[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922], when
enable LTO, gcc-12 will not see `diagnostic ignored "-Wstringop-overread"`, resulting in a warning.
SOLUTION: temporarily set SHA1Update to noinline to avoid compiler warnings due
to LTO being enabled until the above gcc bug is fixed.
7) zmalloc.h
COMPILER: GCC-12
WARNING:
```
In function ‘memset’,
inlined from ‘moduleCreateContext’ at module.c:877:5,
inlined from ‘RM_GetDetachedThreadSafeContext’ at module.c:8410:5:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59:10: warning: ‘__builtin_memset’ writing 104 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
59 | return __builtin___memset_chk (__dest, __ch, __len,
```
REASON: due to the GCC-12 bug [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503],
GCC-12 cannot see alloc_size, which causes GCC to think that the actual size of memory
is 0 when checking with __glibc_objsize0().
SOLUTION: temporarily set malloc-related interfaces to `noinline` to avoid compiler warnings
due to LTO being enabled until the above gcc bug is fixed.
## Other changes
1) Fixed `ps -p [pid]` doesn't output `<defunct>` when using procps 4.x causing `replication
child dies when parent is killed - diskless` test to fail.
2) Add a new fortify CI with GCC-13 and ubuntu-lunar docker image.
2023-04-18 02:53:51 -04:00
|
|
|
run: ./src/redis-server test all --accurate
|
|
|
|
|
|
|
|
|
|
test-ubuntu-jemalloc-fortify:
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
if: |
|
|
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'fortify')
|
|
|
|
|
container: ubuntu:lunar
|
|
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
|
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
|
|
|
|
- uses: actions/checkout@v3
|
|
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: |
|
|
|
|
|
apt-get update && apt-get install -y make gcc-13
|
|
|
|
|
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-13 100
|
|
|
|
|
make CC=gcc REDIS_CFLAGS='-Werror -DREDIS_TEST -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3'
|
|
|
|
|
- name: testprep
|
|
|
|
|
run: apt-get install -y tcl8.6 tclx procps
|
|
|
|
|
- name: test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
|
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
|
|
|
|
- name: module api test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
|
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
|
|
|
|
- name: sentinel tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
|
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: cluster tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
|
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: unittest
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'unittest')
|
2021-11-16 14:00:13 -05:00
|
|
|
run: ./src/redis-server test all --accurate
|
2020-05-03 02:31:50 -04:00
|
|
|
|
2020-07-30 06:25:10 -04:00
|
|
|
test-ubuntu-libc-malloc:
|
2020-05-03 02:31:50 -04:00
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'malloc')
|
2020-07-12 06:55:26 -04:00
|
|
|
timeout-minutes: 14400
|
2020-05-03 02:31:50 -04:00
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2020-05-03 02:31:50 -04:00
|
|
|
- name: make
|
2021-11-29 03:30:35 -05:00
|
|
|
run: make MALLOC=libc REDIS_CFLAGS='-Werror'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: sudo apt-get install tcl8.6 tclx
|
2020-05-03 02:31:50 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-05-03 02:31:50 -04:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-09 15:37:18 -05:00
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-07-12 06:55:26 -04:00
|
|
|
- name: sentinel tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2020-07-12 06:55:26 -04:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
2020-05-03 02:31:50 -04:00
|
|
|
|
2021-02-25 02:24:41 -05:00
|
|
|
test-ubuntu-no-malloc-usable-size:
|
|
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'malloc')
|
2021-02-25 02:24:41 -05:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2021-02-25 02:24:41 -05:00
|
|
|
- name: make
|
2021-11-29 03:30:35 -05:00
|
|
|
run: make MALLOC=libc CFLAGS=-DNO_MALLOC_USABLE_SIZE REDIS_CFLAGS='-Werror'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: sudo apt-get install tcl8.6 tclx
|
2021-02-25 02:24:41 -05:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2021-02-25 02:24:41 -05:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-09 15:37:18 -05:00
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2021-02-25 02:24:41 -05:00
|
|
|
- name: sentinel tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2021-02-25 02:24:41 -05:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
2021-02-25 02:24:41 -05:00
|
|
|
|
2020-07-30 06:25:10 -04:00
|
|
|
test-ubuntu-32bit:
|
2020-05-24 01:00:12 -04:00
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, '32bit')
|
2020-07-12 06:55:26 -04:00
|
|
|
timeout-minutes: 14400
|
2020-05-24 01:00:12 -04:00
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2020-05-24 01:00:12 -04:00
|
|
|
- name: make
|
|
|
|
|
run: |
|
|
|
|
|
sudo apt-get update && sudo apt-get install libc6-dev-i386
|
2021-03-10 02:13:11 -05:00
|
|
|
make 32bit REDIS_CFLAGS='-Werror -DREDIS_TEST'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: sudo apt-get install tcl8.6 tclx
|
2020-05-24 01:00:12 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-05-24 01:00:12 -04:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2020-05-27 11:09:09 -04:00
|
|
|
run: |
|
|
|
|
|
make -C tests/modules 32bit # the script below doesn't have an argument, we must build manually ahead of time
|
2021-11-09 15:37:18 -05:00
|
|
|
./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-07-12 06:55:26 -04:00
|
|
|
- name: sentinel tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2020-07-12 06:55:26 -04:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
2021-03-10 02:13:11 -05:00
|
|
|
- name: unittest
|
2022-02-13 10:43:19 -05:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'unittest')
|
2021-11-16 14:00:13 -05:00
|
|
|
run: ./src/redis-server test all --accurate
|
2020-05-24 01:00:12 -04:00
|
|
|
|
2020-07-30 06:25:10 -04:00
|
|
|
test-ubuntu-tls:
|
2020-05-25 10:25:23 -04:00
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'tls')
|
2020-07-12 06:55:26 -04:00
|
|
|
timeout-minutes: 14400
|
2020-05-25 10:25:23 -04:00
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2020-05-25 10:25:23 -04:00
|
|
|
- name: make
|
|
|
|
|
run: |
|
2021-11-29 03:30:35 -05:00
|
|
|
make BUILD_TLS=yes REDIS_CFLAGS='-Werror'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
2020-05-25 10:25:23 -04:00
|
|
|
run: |
|
2021-04-25 06:08:46 -04:00
|
|
|
sudo apt-get install tcl8.6 tclx tcl-tls
|
2020-05-25 10:25:23 -04:00
|
|
|
./utils/gen-test-certs.sh
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: |
|
2022-03-22 11:38:01 -04:00
|
|
|
./runtest --accurate --verbose --dump-logs --tls --dump-logs ${{github.event.inputs.test_args}}
|
|
|
|
|
- name: module api test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
|
|
|
|
run: |
|
|
|
|
|
./runtest-moduleapi --verbose --dump-logs --tls --dump-logs ${{github.event.inputs.test_args}}
|
|
|
|
|
- name: sentinel tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
|
|
|
|
run: |
|
|
|
|
|
./runtest-sentinel --tls ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: cluster tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
|
|
|
|
run: |
|
|
|
|
|
./runtest-cluster --tls ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
|
|
|
|
|
test-ubuntu-tls-no-tls:
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'tls')
|
2022-03-22 11:38:01 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: |
|
|
|
|
|
make BUILD_TLS=yes REDIS_CFLAGS='-Werror'
|
|
|
|
|
- name: testprep
|
|
|
|
|
run: |
|
|
|
|
|
sudo apt-get install tcl8.6 tclx tcl-tls
|
|
|
|
|
./utils/gen-test-certs.sh
|
|
|
|
|
- name: test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
|
|
|
|
run: |
|
2021-06-22 10:23:59 -04:00
|
|
|
./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-05-25 10:25:23 -04:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2020-08-17 10:36:50 -04:00
|
|
|
run: |
|
2021-11-09 15:37:18 -05:00
|
|
|
./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-07-12 06:55:26 -04:00
|
|
|
- name: sentinel tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2020-08-17 10:36:50 -04:00
|
|
|
run: |
|
2021-06-22 10:23:59 -04:00
|
|
|
./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2020-07-12 06:55:26 -04:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2020-08-17 10:36:50 -04:00
|
|
|
run: |
|
2021-06-22 10:23:59 -04:00
|
|
|
./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
2020-05-25 10:25:23 -04:00
|
|
|
|
2021-01-17 08:48:48 -05:00
|
|
|
test-ubuntu-io-threads:
|
|
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'iothreads')
|
2021-01-17 08:48:48 -05:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2021-01-17 08:48:48 -05:00
|
|
|
- name: make
|
|
|
|
|
run: |
|
2021-11-29 03:30:35 -05:00
|
|
|
make REDIS_CFLAGS='-Werror'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: sudo apt-get install tcl8.6 tclx
|
2021-01-17 08:48:48 -05:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest --config io-threads 4 --config io-threads-do-reads yes --accurate --verbose --tags network --dump-logs ${{github.event.inputs.test_args}}
|
2021-01-17 08:48:48 -05:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster --config io-threads 4 --config io-threads-do-reads yes ${{github.event.inputs.cluster_test_args}}
|
2021-01-17 08:48:48 -05:00
|
|
|
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
test-ubuntu-reclaim-cache:
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
if: |
|
|
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'specific')
|
|
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
- uses: actions/checkout@v3
|
|
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: |
|
|
|
|
|
make REDIS_CFLAGS='-Werror'
|
|
|
|
|
- name: testprep
|
|
|
|
|
run: |
|
|
|
|
|
sudo apt-get install vmtouch
|
|
|
|
|
mkdir /tmp/master
|
|
|
|
|
mkdir /tmp/slave
|
|
|
|
|
- name: warm up
|
|
|
|
|
run: |
|
|
|
|
|
./src/redis-server --daemonize yes --logfile /dev/null
|
|
|
|
|
./src/redis-benchmark -n 1 > /dev/null
|
|
|
|
|
./src/redis-cli save | grep OK > /dev/null
|
|
|
|
|
vmtouch -v ./dump.rdb > /dev/null
|
|
|
|
|
- name: test
|
|
|
|
|
run: |
|
|
|
|
|
echo "test SAVE doesn't increase cache"
|
|
|
|
|
CACHE0=$(grep -w file /sys/fs/cgroup/memory.stat | awk '{print $2}')
|
2023-02-19 11:38:07 -05:00
|
|
|
echo "$CACHE0"
|
|
|
|
|
./src/redis-server --daemonize yes --logfile /dev/null --dir /tmp/master --port 8080 --repl-diskless-sync no --pidfile /tmp/master/redis.pid --rdbcompression no --enable-debug-command yes
|
|
|
|
|
./src/redis-cli -p 8080 debug populate 10000 k 102400
|
|
|
|
|
./src/redis-server --daemonize yes --logfile /dev/null --dir /tmp/slave --port 8081 --repl-diskless-load disabled --rdbcompression no
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
./src/redis-cli -p 8080 save > /dev/null
|
|
|
|
|
VMOUT=$(vmtouch -v /tmp/master/dump.rdb)
|
|
|
|
|
echo $VMOUT
|
2023-04-05 07:45:42 -04:00
|
|
|
grep -q " 0%" <<< $VMOUT
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
CACHE=$(grep -w file /sys/fs/cgroup/memory.stat | awk '{print $2}')
|
2023-02-19 11:38:07 -05:00
|
|
|
echo "$CACHE"
|
2023-04-05 07:45:42 -04:00
|
|
|
if [ "$(( $CACHE-$CACHE0 ))" -gt "8000000" ]; then exit 1; fi
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
|
|
|
|
|
echo "test replication doesn't increase cache"
|
|
|
|
|
./src/redis-cli -p 8081 REPLICAOF 127.0.0.1 8080 > /dev/null
|
|
|
|
|
while [ $(./src/redis-cli -p 8081 info replication | grep "master_link_status:down") ]; do sleep 1; done;
|
|
|
|
|
sleep 1 # wait for the completion of cache reclaim bio
|
|
|
|
|
VMOUT=$(vmtouch -v /tmp/master/dump.rdb)
|
|
|
|
|
echo $VMOUT
|
2023-04-05 07:45:42 -04:00
|
|
|
grep -q " 0%" <<< $VMOUT
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
VMOUT=$(vmtouch -v /tmp/slave/dump.rdb)
|
|
|
|
|
echo $VMOUT
|
2023-04-05 07:45:42 -04:00
|
|
|
grep -q " 0%" <<< $VMOUT
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
CACHE=$(grep -w file /sys/fs/cgroup/memory.stat | awk '{print $2}')
|
2023-02-19 11:38:07 -05:00
|
|
|
echo "$CACHE"
|
2023-04-05 07:45:42 -04:00
|
|
|
if [ "$(( $CACHE-$CACHE0 ))" -gt "8000000" ]; then exit 1; fi
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
|
|
|
|
|
echo "test reboot doesn't increase cache"
|
|
|
|
|
PID=$(cat /tmp/master/redis.pid)
|
|
|
|
|
kill -15 $PID
|
|
|
|
|
while [ -x /proc/${PID} ]; do sleep 1; done
|
|
|
|
|
./src/redis-server --daemonize yes --logfile /dev/null --dir /tmp/master --port 8080
|
|
|
|
|
while [ $(./src/redis-cli -p 8080 info persistence | grep "loading:1") ]; do sleep 1; done;
|
|
|
|
|
sleep 1 # wait for the completion of cache reclaim bio
|
|
|
|
|
VMOUT=$(vmtouch -v /tmp/master/dump.rdb)
|
|
|
|
|
echo $VMOUT
|
2023-04-05 07:45:42 -04:00
|
|
|
grep -q " 0%" <<< $VMOUT
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
CACHE=$(grep -w file /sys/fs/cgroup/memory.stat | awk '{print $2}')
|
2023-02-19 11:38:07 -05:00
|
|
|
echo "$CACHE"
|
2023-04-05 07:45:42 -04:00
|
|
|
if [ "$(( $CACHE-$CACHE0 ))" -gt "8000000" ]; then exit 1; fi
|
Reclaim page cache of RDB file (#11248)
# Background
The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
# What the PR does
The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
# Something deserve noting
1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
# About test
A unit test is added to verify the effect of `posix_fadvise`.
In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
2023-02-12 02:23:29 -05:00
|
|
|
|
2022-03-22 11:38:01 -04:00
|
|
|
test-valgrind-test:
|
2020-05-03 02:31:50 -04:00
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'valgrind') && !contains(github.event.inputs.skiptests, 'redis')
|
2020-05-03 02:31:50 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2020-05-03 02:31:50 -04:00
|
|
|
- name: make
|
2021-03-10 02:13:11 -05:00
|
|
|
run: make valgrind REDIS_CFLAGS='-Werror -DREDIS_TEST'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
2020-05-03 02:31:50 -04:00
|
|
|
run: |
|
2020-09-13 06:51:21 -04:00
|
|
|
sudo apt-get update
|
2021-04-25 06:08:46 -04:00
|
|
|
sudo apt-get install tcl8.6 tclx valgrind -y
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-11-16 14:00:13 -05:00
|
|
|
run: ./runtest --valgrind --no-latency --verbose --clients 1 --timeout 2400 --dump-logs ${{github.event.inputs.test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
|
|
|
|
|
test-valgrind-misc:
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'valgrind') && !(contains(github.event.inputs.skiptests, 'modules') && contains(github.event.inputs.skiptests, 'unittest'))
|
2022-03-22 11:38:01 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: make valgrind REDIS_CFLAGS='-Werror -DREDIS_TEST'
|
|
|
|
|
- name: testprep
|
|
|
|
|
run: |
|
|
|
|
|
sudo apt-get update
|
|
|
|
|
sudo apt-get install tcl8.6 tclx valgrind -y
|
2020-05-03 02:31:50 -04:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-10 12:38:58 -05:00
|
|
|
run: ./runtest-moduleapi --valgrind --no-latency --verbose --clients 1 --timeout 2400 --dump-logs ${{github.event.inputs.test_args}}
|
2021-03-10 02:13:11 -05:00
|
|
|
- name: unittest
|
2022-02-13 10:43:19 -05:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'unittest')
|
2021-03-10 02:13:11 -05:00
|
|
|
run: |
|
2023-02-16 03:50:58 -05:00
|
|
|
valgrind --track-origins=yes --suppressions=./src/valgrind.sup --show-reachable=no --show-possibly-lost=no --leak-check=full --log-file=err.txt ./src/redis-server test all --valgrind
|
2021-03-10 02:13:11 -05:00
|
|
|
if grep -q 0x err.txt; then cat err.txt; exit 1; fi
|
2020-07-30 06:25:10 -04:00
|
|
|
|
2022-03-22 11:38:01 -04:00
|
|
|
test-valgrind-no-malloc-usable-size-test:
|
2021-02-25 02:24:41 -05:00
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'valgrind') && !contains(github.event.inputs.skiptests, 'redis')
|
2021-02-25 02:24:41 -05:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2021-02-25 02:24:41 -05:00
|
|
|
- name: make
|
2022-03-22 11:38:01 -04:00
|
|
|
run: make valgrind CFLAGS="-DNO_MALLOC_USABLE_SIZE -DREDIS_TEST" REDIS_CFLAGS='-Werror'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
2021-02-25 02:24:41 -05:00
|
|
|
run: |
|
|
|
|
|
sudo apt-get update
|
2021-04-25 06:08:46 -04:00
|
|
|
sudo apt-get install tcl8.6 tclx valgrind -y
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-11-16 14:00:13 -05:00
|
|
|
run: ./runtest --valgrind --no-latency --verbose --clients 1 --timeout 2400 --dump-logs ${{github.event.inputs.test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
|
|
|
|
|
test-valgrind-no-malloc-usable-size-misc:
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'valgrind') && !(contains(github.event.inputs.skiptests, 'modules') && contains(github.event.inputs.skiptests, 'unittest'))
|
2022-03-22 11:38:01 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: make valgrind CFLAGS="-DNO_MALLOC_USABLE_SIZE -DREDIS_TEST" REDIS_CFLAGS='-Werror'
|
|
|
|
|
- name: testprep
|
|
|
|
|
run: |
|
|
|
|
|
sudo apt-get update
|
|
|
|
|
sudo apt-get install tcl8.6 tclx valgrind -y
|
2021-02-25 02:24:41 -05:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-10 12:38:58 -05:00
|
|
|
run: ./runtest-moduleapi --valgrind --no-latency --verbose --clients 1 --timeout 2400 --dump-logs ${{github.event.inputs.test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
- name: unittest
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'unittest')
|
|
|
|
|
run: |
|
2023-02-16 03:50:58 -05:00
|
|
|
valgrind --track-origins=yes --suppressions=./src/valgrind.sup --show-reachable=no --show-possibly-lost=no --leak-check=full --log-file=err.txt ./src/redis-server test all --valgrind
|
2022-03-22 11:38:01 -04:00
|
|
|
if grep -q 0x err.txt; then cat err.txt; exit 1; fi
|
2021-02-25 02:24:41 -05:00
|
|
|
|
2021-11-11 06:51:33 -05:00
|
|
|
test-sanitizer-address:
|
|
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'sanitizer')
|
2021-11-11 06:51:33 -05:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
strategy:
|
|
|
|
|
matrix:
|
|
|
|
|
compiler: [ gcc, clang ]
|
|
|
|
|
env:
|
|
|
|
|
CC: ${{ matrix.compiler }}
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-11-11 06:51:33 -05:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
2021-11-29 03:30:35 -05:00
|
|
|
run: make SANITIZER=address REDIS_CFLAGS='-DREDIS_TEST -Werror'
|
2021-11-11 06:51:33 -05:00
|
|
|
- name: testprep
|
|
|
|
|
run: |
|
|
|
|
|
sudo apt-get update
|
|
|
|
|
sudo apt-get install tcl8.6 tclx -y
|
|
|
|
|
- name: test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
|
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
|
|
|
|
- name: module api test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-18 09:04:01 -05:00
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2021-11-11 06:51:33 -05:00
|
|
|
- name: sentinel tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
|
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: cluster tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
|
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: unittest
|
2022-02-13 10:43:19 -05:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'unittest')
|
2021-11-21 11:27:54 -05:00
|
|
|
run: ./src/redis-server test all
|
2021-11-11 06:51:33 -05:00
|
|
|
|
|
|
|
|
test-sanitizer-undefined:
|
|
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'sanitizer')
|
2021-11-11 06:51:33 -05:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
strategy:
|
|
|
|
|
matrix:
|
|
|
|
|
compiler: [ gcc, clang ]
|
|
|
|
|
env:
|
|
|
|
|
CC: ${{ matrix.compiler }}
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-11-11 06:51:33 -05:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
2021-11-29 03:30:35 -05:00
|
|
|
run: make SANITIZER=undefined REDIS_CFLAGS='-DREDIS_TEST -Werror' LUA_DEBUG=yes # we (ab)use this flow to also check Lua C API violations
|
2021-11-11 06:51:33 -05:00
|
|
|
- name: testprep
|
|
|
|
|
run: |
|
|
|
|
|
sudo apt-get update
|
|
|
|
|
sudo apt-get install tcl8.6 tclx -y
|
|
|
|
|
- name: test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
|
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
|
|
|
|
- name: module api test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-18 09:04:01 -05:00
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2021-11-11 06:51:33 -05:00
|
|
|
- name: sentinel tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
|
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: cluster tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
|
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: unittest
|
2022-02-13 10:43:19 -05:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'unittest')
|
2021-11-16 14:00:13 -05:00
|
|
|
run: ./src/redis-server test all --accurate
|
2021-11-11 06:51:33 -05:00
|
|
|
|
2020-07-30 06:25:10 -04:00
|
|
|
test-centos7-jemalloc:
|
|
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'centos')
|
2020-07-30 06:25:10 -04:00
|
|
|
container: centos:7
|
|
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2020-07-30 06:25:10 -04:00
|
|
|
- name: make
|
|
|
|
|
run: |
|
Implement redisAtomic to replace _Atomic C11 builtin (#7707)
Redis 6.0 introduces I/O threads, it is so cool and efficient, we use C11
_Atomic to establish inter-thread synchronization without mutex. But the
compiler that must supports C11 _Atomic can compile redis code, that brings a
lot of inconvenience since some common platforms can't support by default such
as CentOS7, so we want to implement redis atomic type to make it more portable.
We have implemented our atomic variable for redis that only has 'relaxed'
operations in src/atomicvar.h, so we implement some operations with
'sequentially-consistent', just like the default behavior of C11 _Atomic that
can establish inter-thread synchronization. And we replace all uses of C11
_Atomic with redis atomic variable.
Our implementation of redis atomic variable uses C11 _Atomic, __atomic or
__sync macros if available, it supports most common platforms, and we will
detect automatically which feature we use. In Makefile we use a dummy file to
detect if the compiler supports C11 _Atomic. Now for gcc, we can compile redis
code theoretically if your gcc version is not less than 4.1.2(starts to support
__sync_xxx operations). Otherwise, we remove use mutex fallback to implement
redis atomic variable for performance and test. You will get compiling errors
if your compiler doesn't support all features of above.
For cover redis atomic variable tests, we add other CI jobs that build redis on
CentOS6 and CentOS7 and workflow daily jobs that run the tests on them.
For them, we just install gcc by default in order to cover different compiler
versions, gcc is 4.4.7 by default installation on CentOS6 and 4.8.5 on CentOS7.
We restore the feature that we can test redis with Helgrind to find data race
errors. But you need install Valgrind in the default path configuration firstly
before running your tests, since we use macros in helgrind.h to tell Helgrind
inter-thread happens-before relationship explicitly for avoiding false positives.
Please open an issue on github if you find data race errors relate to this commit.
Unrelated:
- Fix redefinition of typedef 'RedisModuleUserChangedFunc'
For some old version compilers, they will report errors or warnings, if we
re-define function type.
2020-09-17 09:01:45 -04:00
|
|
|
yum -y install gcc make
|
2021-11-29 03:30:35 -05:00
|
|
|
make REDIS_CFLAGS='-Werror'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: yum -y install which tcl tclx
|
2020-07-30 06:25:10 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
Implement redisAtomic to replace _Atomic C11 builtin (#7707)
Redis 6.0 introduces I/O threads, it is so cool and efficient, we use C11
_Atomic to establish inter-thread synchronization without mutex. But the
compiler that must supports C11 _Atomic can compile redis code, that brings a
lot of inconvenience since some common platforms can't support by default such
as CentOS7, so we want to implement redis atomic type to make it more portable.
We have implemented our atomic variable for redis that only has 'relaxed'
operations in src/atomicvar.h, so we implement some operations with
'sequentially-consistent', just like the default behavior of C11 _Atomic that
can establish inter-thread synchronization. And we replace all uses of C11
_Atomic with redis atomic variable.
Our implementation of redis atomic variable uses C11 _Atomic, __atomic or
__sync macros if available, it supports most common platforms, and we will
detect automatically which feature we use. In Makefile we use a dummy file to
detect if the compiler supports C11 _Atomic. Now for gcc, we can compile redis
code theoretically if your gcc version is not less than 4.1.2(starts to support
__sync_xxx operations). Otherwise, we remove use mutex fallback to implement
redis atomic variable for performance and test. You will get compiling errors
if your compiler doesn't support all features of above.
For cover redis atomic variable tests, we add other CI jobs that build redis on
CentOS6 and CentOS7 and workflow daily jobs that run the tests on them.
For them, we just install gcc by default in order to cover different compiler
versions, gcc is 4.4.7 by default installation on CentOS6 and 4.8.5 on CentOS7.
We restore the feature that we can test redis with Helgrind to find data race
errors. But you need install Valgrind in the default path configuration firstly
before running your tests, since we use macros in helgrind.h to tell Helgrind
inter-thread happens-before relationship explicitly for avoiding false positives.
Please open an issue on github if you find data race errors relate to this commit.
Unrelated:
- Fix redefinition of typedef 'RedisModuleUserChangedFunc'
For some old version compilers, they will report errors or warnings, if we
re-define function type.
2020-09-17 09:01:45 -04:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-09 15:37:18 -05:00
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
Implement redisAtomic to replace _Atomic C11 builtin (#7707)
Redis 6.0 introduces I/O threads, it is so cool and efficient, we use C11
_Atomic to establish inter-thread synchronization without mutex. But the
compiler that must supports C11 _Atomic can compile redis code, that brings a
lot of inconvenience since some common platforms can't support by default such
as CentOS7, so we want to implement redis atomic type to make it more portable.
We have implemented our atomic variable for redis that only has 'relaxed'
operations in src/atomicvar.h, so we implement some operations with
'sequentially-consistent', just like the default behavior of C11 _Atomic that
can establish inter-thread synchronization. And we replace all uses of C11
_Atomic with redis atomic variable.
Our implementation of redis atomic variable uses C11 _Atomic, __atomic or
__sync macros if available, it supports most common platforms, and we will
detect automatically which feature we use. In Makefile we use a dummy file to
detect if the compiler supports C11 _Atomic. Now for gcc, we can compile redis
code theoretically if your gcc version is not less than 4.1.2(starts to support
__sync_xxx operations). Otherwise, we remove use mutex fallback to implement
redis atomic variable for performance and test. You will get compiling errors
if your compiler doesn't support all features of above.
For cover redis atomic variable tests, we add other CI jobs that build redis on
CentOS6 and CentOS7 and workflow daily jobs that run the tests on them.
For them, we just install gcc by default in order to cover different compiler
versions, gcc is 4.4.7 by default installation on CentOS6 and 4.8.5 on CentOS7.
We restore the feature that we can test redis with Helgrind to find data race
errors. But you need install Valgrind in the default path configuration firstly
before running your tests, since we use macros in helgrind.h to tell Helgrind
inter-thread happens-before relationship explicitly for avoiding false positives.
Please open an issue on github if you find data race errors relate to this commit.
Unrelated:
- Fix redefinition of typedef 'RedisModuleUserChangedFunc'
For some old version compilers, they will report errors or warnings, if we
re-define function type.
2020-09-17 09:01:45 -04:00
|
|
|
- name: sentinel tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
Implement redisAtomic to replace _Atomic C11 builtin (#7707)
Redis 6.0 introduces I/O threads, it is so cool and efficient, we use C11
_Atomic to establish inter-thread synchronization without mutex. But the
compiler that must supports C11 _Atomic can compile redis code, that brings a
lot of inconvenience since some common platforms can't support by default such
as CentOS7, so we want to implement redis atomic type to make it more portable.
We have implemented our atomic variable for redis that only has 'relaxed'
operations in src/atomicvar.h, so we implement some operations with
'sequentially-consistent', just like the default behavior of C11 _Atomic that
can establish inter-thread synchronization. And we replace all uses of C11
_Atomic with redis atomic variable.
Our implementation of redis atomic variable uses C11 _Atomic, __atomic or
__sync macros if available, it supports most common platforms, and we will
detect automatically which feature we use. In Makefile we use a dummy file to
detect if the compiler supports C11 _Atomic. Now for gcc, we can compile redis
code theoretically if your gcc version is not less than 4.1.2(starts to support
__sync_xxx operations). Otherwise, we remove use mutex fallback to implement
redis atomic variable for performance and test. You will get compiling errors
if your compiler doesn't support all features of above.
For cover redis atomic variable tests, we add other CI jobs that build redis on
CentOS6 and CentOS7 and workflow daily jobs that run the tests on them.
For them, we just install gcc by default in order to cover different compiler
versions, gcc is 4.4.7 by default installation on CentOS6 and 4.8.5 on CentOS7.
We restore the feature that we can test redis with Helgrind to find data race
errors. But you need install Valgrind in the default path configuration firstly
before running your tests, since we use macros in helgrind.h to tell Helgrind
inter-thread happens-before relationship explicitly for avoiding false positives.
Please open an issue on github if you find data race errors relate to this commit.
Unrelated:
- Fix redefinition of typedef 'RedisModuleUserChangedFunc'
For some old version compilers, they will report errors or warnings, if we
re-define function type.
2020-09-17 09:01:45 -04:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
Implement redisAtomic to replace _Atomic C11 builtin (#7707)
Redis 6.0 introduces I/O threads, it is so cool and efficient, we use C11
_Atomic to establish inter-thread synchronization without mutex. But the
compiler that must supports C11 _Atomic can compile redis code, that brings a
lot of inconvenience since some common platforms can't support by default such
as CentOS7, so we want to implement redis atomic type to make it more portable.
We have implemented our atomic variable for redis that only has 'relaxed'
operations in src/atomicvar.h, so we implement some operations with
'sequentially-consistent', just like the default behavior of C11 _Atomic that
can establish inter-thread synchronization. And we replace all uses of C11
_Atomic with redis atomic variable.
Our implementation of redis atomic variable uses C11 _Atomic, __atomic or
__sync macros if available, it supports most common platforms, and we will
detect automatically which feature we use. In Makefile we use a dummy file to
detect if the compiler supports C11 _Atomic. Now for gcc, we can compile redis
code theoretically if your gcc version is not less than 4.1.2(starts to support
__sync_xxx operations). Otherwise, we remove use mutex fallback to implement
redis atomic variable for performance and test. You will get compiling errors
if your compiler doesn't support all features of above.
For cover redis atomic variable tests, we add other CI jobs that build redis on
CentOS6 and CentOS7 and workflow daily jobs that run the tests on them.
For them, we just install gcc by default in order to cover different compiler
versions, gcc is 4.4.7 by default installation on CentOS6 and 4.8.5 on CentOS7.
We restore the feature that we can test redis with Helgrind to find data race
errors. But you need install Valgrind in the default path configuration firstly
before running your tests, since we use macros in helgrind.h to tell Helgrind
inter-thread happens-before relationship explicitly for avoiding false positives.
Please open an issue on github if you find data race errors relate to this commit.
Unrelated:
- Fix redefinition of typedef 'RedisModuleUserChangedFunc'
For some old version compilers, they will report errors or warnings, if we
re-define function type.
2020-09-17 09:01:45 -04:00
|
|
|
|
2022-11-21 15:53:13 -05:00
|
|
|
test-centos7-tls-module:
|
2020-07-30 06:25:10 -04:00
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'tls')
|
2020-07-30 06:25:10 -04:00
|
|
|
container: centos:7
|
|
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2020-07-30 06:25:10 -04:00
|
|
|
- name: make
|
|
|
|
|
run: |
|
|
|
|
|
yum -y install centos-release-scl epel-release
|
|
|
|
|
yum -y install devtoolset-7 openssl-devel openssl
|
Build TLS as a loadable module
* Support BUILD_TLS=module to be loaded as a module via config file or
command line. e.g. redis-server --loadmodule redis-tls.so
* Updates to redismodule.h to allow it to be used side by side with
server.h by defining REDISMODULE_CORE_MODULE
* Changes to server.h, redismodule.h and module.c to avoid repeated
type declarations (gcc 4.8 doesn't like these)
* Add a mechanism for non-ABI neutral modules (ones who include
server.h) to refuse loading if they detect not being built together with
redis (release.c)
* Fix wrong signature of RedisModuleDefragFunc, this could break
compilation of a module, but not the ABI
* Move initialization of listeners in server.c to be after loading
the modules
* Config TLS after initialization of listeners
* Init cluster after initialization of listeners
* Add TLS module to CI
* Fix a test suite race conditions:
Now that the listeners are initialized later, it's not sufficient to
wait for the PID message in the log, we need to wait for the "Server
Initialized" message.
* Fix issues with moduleconfigs test as a result from start_server
waiting for "Server Initialized"
* Fix issues with modules/infra test as a result of an additional module
present
Notes about Sentinel:
Sentinel can't really rely on the tls module, since it uses hiredis to
initiate connections and depends on OpenSSL (won't be able to use any
other connection modules for that), so it was decided that when TLS is
built as a module, sentinel does not support TLS at all.
This means that it keeps using redis_tls_ctx and redis_tls_client_ctx directly.
Example code of config in redis-tls.so(may be use in the future):
RedisModuleString *tls_cfg = NULL;
void tlsInfo(RedisModuleInfoCtx *ctx, int for_crash_report) {
UNUSED(for_crash_report);
RedisModule_InfoAddSection(ctx, "");
RedisModule_InfoAddFieldLongLong(ctx, "var", 42);
}
int tlsCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
{
if (argc != 2) return RedisModule_WrongArity(ctx);
return RedisModule_ReplyWithString(ctx, argv[1]);
}
RedisModuleString *getStringConfigCommand(const char *name, void *privdata) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(privdata);
return tls_cfg;
}
int setStringConfigCommand(const char *name, RedisModuleString *new, void *privdata, RedisModuleString **err) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(err);
REDISMODULE_NOT_USED(privdata);
if (tls_cfg) RedisModule_FreeString(NULL, tls_cfg);
RedisModule_RetainString(NULL, new);
tls_cfg = new;
return REDISMODULE_OK;
}
int RedisModule_OnLoad(void *ctx, RedisModuleString **argv, int argc)
{
....
if (RedisModule_CreateCommand(ctx,"tls",tlsCommand,"",0,0,0) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_RegisterStringConfig(ctx, "cfg", "", REDISMODULE_CONFIG_DEFAULT, getStringConfigCommand, setStringConfigCommand, NULL, NULL) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_LoadConfigs(ctx) == REDISMODULE_ERR) {
if (tls_cfg) {
RedisModule_FreeString(ctx, tls_cfg);
tls_cfg = NULL;
}
return REDISMODULE_ERR;
}
...
}
Co-authored-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
2022-08-22 03:53:56 -04:00
|
|
|
scl enable devtoolset-7 "make BUILD_TLS=module REDIS_CFLAGS='-Werror'"
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
2020-07-30 06:25:10 -04:00
|
|
|
run: |
|
2021-04-25 06:08:46 -04:00
|
|
|
yum -y install tcl tcltls tclx
|
2020-07-30 06:25:10 -04:00
|
|
|
./utils/gen-test-certs.sh
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: |
|
Build TLS as a loadable module
* Support BUILD_TLS=module to be loaded as a module via config file or
command line. e.g. redis-server --loadmodule redis-tls.so
* Updates to redismodule.h to allow it to be used side by side with
server.h by defining REDISMODULE_CORE_MODULE
* Changes to server.h, redismodule.h and module.c to avoid repeated
type declarations (gcc 4.8 doesn't like these)
* Add a mechanism for non-ABI neutral modules (ones who include
server.h) to refuse loading if they detect not being built together with
redis (release.c)
* Fix wrong signature of RedisModuleDefragFunc, this could break
compilation of a module, but not the ABI
* Move initialization of listeners in server.c to be after loading
the modules
* Config TLS after initialization of listeners
* Init cluster after initialization of listeners
* Add TLS module to CI
* Fix a test suite race conditions:
Now that the listeners are initialized later, it's not sufficient to
wait for the PID message in the log, we need to wait for the "Server
Initialized" message.
* Fix issues with moduleconfigs test as a result from start_server
waiting for "Server Initialized"
* Fix issues with modules/infra test as a result of an additional module
present
Notes about Sentinel:
Sentinel can't really rely on the tls module, since it uses hiredis to
initiate connections and depends on OpenSSL (won't be able to use any
other connection modules for that), so it was decided that when TLS is
built as a module, sentinel does not support TLS at all.
This means that it keeps using redis_tls_ctx and redis_tls_client_ctx directly.
Example code of config in redis-tls.so(may be use in the future):
RedisModuleString *tls_cfg = NULL;
void tlsInfo(RedisModuleInfoCtx *ctx, int for_crash_report) {
UNUSED(for_crash_report);
RedisModule_InfoAddSection(ctx, "");
RedisModule_InfoAddFieldLongLong(ctx, "var", 42);
}
int tlsCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
{
if (argc != 2) return RedisModule_WrongArity(ctx);
return RedisModule_ReplyWithString(ctx, argv[1]);
}
RedisModuleString *getStringConfigCommand(const char *name, void *privdata) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(privdata);
return tls_cfg;
}
int setStringConfigCommand(const char *name, RedisModuleString *new, void *privdata, RedisModuleString **err) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(err);
REDISMODULE_NOT_USED(privdata);
if (tls_cfg) RedisModule_FreeString(NULL, tls_cfg);
RedisModule_RetainString(NULL, new);
tls_cfg = new;
return REDISMODULE_OK;
}
int RedisModule_OnLoad(void *ctx, RedisModuleString **argv, int argc)
{
....
if (RedisModule_CreateCommand(ctx,"tls",tlsCommand,"",0,0,0) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_RegisterStringConfig(ctx, "cfg", "", REDISMODULE_CONFIG_DEFAULT, getStringConfigCommand, setStringConfigCommand, NULL, NULL) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_LoadConfigs(ctx) == REDISMODULE_ERR) {
if (tls_cfg) {
RedisModule_FreeString(ctx, tls_cfg);
tls_cfg = NULL;
}
return REDISMODULE_ERR;
}
...
}
Co-authored-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
2022-08-22 03:53:56 -04:00
|
|
|
./runtest --accurate --verbose --dump-logs --tls-module --dump-logs ${{github.event.inputs.test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
- name: module api test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
|
|
|
|
run: |
|
Build TLS as a loadable module
* Support BUILD_TLS=module to be loaded as a module via config file or
command line. e.g. redis-server --loadmodule redis-tls.so
* Updates to redismodule.h to allow it to be used side by side with
server.h by defining REDISMODULE_CORE_MODULE
* Changes to server.h, redismodule.h and module.c to avoid repeated
type declarations (gcc 4.8 doesn't like these)
* Add a mechanism for non-ABI neutral modules (ones who include
server.h) to refuse loading if they detect not being built together with
redis (release.c)
* Fix wrong signature of RedisModuleDefragFunc, this could break
compilation of a module, but not the ABI
* Move initialization of listeners in server.c to be after loading
the modules
* Config TLS after initialization of listeners
* Init cluster after initialization of listeners
* Add TLS module to CI
* Fix a test suite race conditions:
Now that the listeners are initialized later, it's not sufficient to
wait for the PID message in the log, we need to wait for the "Server
Initialized" message.
* Fix issues with moduleconfigs test as a result from start_server
waiting for "Server Initialized"
* Fix issues with modules/infra test as a result of an additional module
present
Notes about Sentinel:
Sentinel can't really rely on the tls module, since it uses hiredis to
initiate connections and depends on OpenSSL (won't be able to use any
other connection modules for that), so it was decided that when TLS is
built as a module, sentinel does not support TLS at all.
This means that it keeps using redis_tls_ctx and redis_tls_client_ctx directly.
Example code of config in redis-tls.so(may be use in the future):
RedisModuleString *tls_cfg = NULL;
void tlsInfo(RedisModuleInfoCtx *ctx, int for_crash_report) {
UNUSED(for_crash_report);
RedisModule_InfoAddSection(ctx, "");
RedisModule_InfoAddFieldLongLong(ctx, "var", 42);
}
int tlsCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
{
if (argc != 2) return RedisModule_WrongArity(ctx);
return RedisModule_ReplyWithString(ctx, argv[1]);
}
RedisModuleString *getStringConfigCommand(const char *name, void *privdata) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(privdata);
return tls_cfg;
}
int setStringConfigCommand(const char *name, RedisModuleString *new, void *privdata, RedisModuleString **err) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(err);
REDISMODULE_NOT_USED(privdata);
if (tls_cfg) RedisModule_FreeString(NULL, tls_cfg);
RedisModule_RetainString(NULL, new);
tls_cfg = new;
return REDISMODULE_OK;
}
int RedisModule_OnLoad(void *ctx, RedisModuleString **argv, int argc)
{
....
if (RedisModule_CreateCommand(ctx,"tls",tlsCommand,"",0,0,0) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_RegisterStringConfig(ctx, "cfg", "", REDISMODULE_CONFIG_DEFAULT, getStringConfigCommand, setStringConfigCommand, NULL, NULL) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_LoadConfigs(ctx) == REDISMODULE_ERR) {
if (tls_cfg) {
RedisModule_FreeString(ctx, tls_cfg);
tls_cfg = NULL;
}
return REDISMODULE_ERR;
}
...
}
Co-authored-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
2022-08-22 03:53:56 -04:00
|
|
|
./runtest-moduleapi --verbose --dump-logs --tls-module --dump-logs ${{github.event.inputs.test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
- name: sentinel tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
|
|
|
|
run: |
|
Build TLS as a loadable module
* Support BUILD_TLS=module to be loaded as a module via config file or
command line. e.g. redis-server --loadmodule redis-tls.so
* Updates to redismodule.h to allow it to be used side by side with
server.h by defining REDISMODULE_CORE_MODULE
* Changes to server.h, redismodule.h and module.c to avoid repeated
type declarations (gcc 4.8 doesn't like these)
* Add a mechanism for non-ABI neutral modules (ones who include
server.h) to refuse loading if they detect not being built together with
redis (release.c)
* Fix wrong signature of RedisModuleDefragFunc, this could break
compilation of a module, but not the ABI
* Move initialization of listeners in server.c to be after loading
the modules
* Config TLS after initialization of listeners
* Init cluster after initialization of listeners
* Add TLS module to CI
* Fix a test suite race conditions:
Now that the listeners are initialized later, it's not sufficient to
wait for the PID message in the log, we need to wait for the "Server
Initialized" message.
* Fix issues with moduleconfigs test as a result from start_server
waiting for "Server Initialized"
* Fix issues with modules/infra test as a result of an additional module
present
Notes about Sentinel:
Sentinel can't really rely on the tls module, since it uses hiredis to
initiate connections and depends on OpenSSL (won't be able to use any
other connection modules for that), so it was decided that when TLS is
built as a module, sentinel does not support TLS at all.
This means that it keeps using redis_tls_ctx and redis_tls_client_ctx directly.
Example code of config in redis-tls.so(may be use in the future):
RedisModuleString *tls_cfg = NULL;
void tlsInfo(RedisModuleInfoCtx *ctx, int for_crash_report) {
UNUSED(for_crash_report);
RedisModule_InfoAddSection(ctx, "");
RedisModule_InfoAddFieldLongLong(ctx, "var", 42);
}
int tlsCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
{
if (argc != 2) return RedisModule_WrongArity(ctx);
return RedisModule_ReplyWithString(ctx, argv[1]);
}
RedisModuleString *getStringConfigCommand(const char *name, void *privdata) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(privdata);
return tls_cfg;
}
int setStringConfigCommand(const char *name, RedisModuleString *new, void *privdata, RedisModuleString **err) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(err);
REDISMODULE_NOT_USED(privdata);
if (tls_cfg) RedisModule_FreeString(NULL, tls_cfg);
RedisModule_RetainString(NULL, new);
tls_cfg = new;
return REDISMODULE_OK;
}
int RedisModule_OnLoad(void *ctx, RedisModuleString **argv, int argc)
{
....
if (RedisModule_CreateCommand(ctx,"tls",tlsCommand,"",0,0,0) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_RegisterStringConfig(ctx, "cfg", "", REDISMODULE_CONFIG_DEFAULT, getStringConfigCommand, setStringConfigCommand, NULL, NULL) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_LoadConfigs(ctx) == REDISMODULE_ERR) {
if (tls_cfg) {
RedisModule_FreeString(ctx, tls_cfg);
tls_cfg = NULL;
}
return REDISMODULE_ERR;
}
...
}
Co-authored-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
2022-08-22 03:53:56 -04:00
|
|
|
./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
- name: cluster tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
|
|
|
|
run: |
|
Build TLS as a loadable module
* Support BUILD_TLS=module to be loaded as a module via config file or
command line. e.g. redis-server --loadmodule redis-tls.so
* Updates to redismodule.h to allow it to be used side by side with
server.h by defining REDISMODULE_CORE_MODULE
* Changes to server.h, redismodule.h and module.c to avoid repeated
type declarations (gcc 4.8 doesn't like these)
* Add a mechanism for non-ABI neutral modules (ones who include
server.h) to refuse loading if they detect not being built together with
redis (release.c)
* Fix wrong signature of RedisModuleDefragFunc, this could break
compilation of a module, but not the ABI
* Move initialization of listeners in server.c to be after loading
the modules
* Config TLS after initialization of listeners
* Init cluster after initialization of listeners
* Add TLS module to CI
* Fix a test suite race conditions:
Now that the listeners are initialized later, it's not sufficient to
wait for the PID message in the log, we need to wait for the "Server
Initialized" message.
* Fix issues with moduleconfigs test as a result from start_server
waiting for "Server Initialized"
* Fix issues with modules/infra test as a result of an additional module
present
Notes about Sentinel:
Sentinel can't really rely on the tls module, since it uses hiredis to
initiate connections and depends on OpenSSL (won't be able to use any
other connection modules for that), so it was decided that when TLS is
built as a module, sentinel does not support TLS at all.
This means that it keeps using redis_tls_ctx and redis_tls_client_ctx directly.
Example code of config in redis-tls.so(may be use in the future):
RedisModuleString *tls_cfg = NULL;
void tlsInfo(RedisModuleInfoCtx *ctx, int for_crash_report) {
UNUSED(for_crash_report);
RedisModule_InfoAddSection(ctx, "");
RedisModule_InfoAddFieldLongLong(ctx, "var", 42);
}
int tlsCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
{
if (argc != 2) return RedisModule_WrongArity(ctx);
return RedisModule_ReplyWithString(ctx, argv[1]);
}
RedisModuleString *getStringConfigCommand(const char *name, void *privdata) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(privdata);
return tls_cfg;
}
int setStringConfigCommand(const char *name, RedisModuleString *new, void *privdata, RedisModuleString **err) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(err);
REDISMODULE_NOT_USED(privdata);
if (tls_cfg) RedisModule_FreeString(NULL, tls_cfg);
RedisModule_RetainString(NULL, new);
tls_cfg = new;
return REDISMODULE_OK;
}
int RedisModule_OnLoad(void *ctx, RedisModuleString **argv, int argc)
{
....
if (RedisModule_CreateCommand(ctx,"tls",tlsCommand,"",0,0,0) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_RegisterStringConfig(ctx, "cfg", "", REDISMODULE_CONFIG_DEFAULT, getStringConfigCommand, setStringConfigCommand, NULL, NULL) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_LoadConfigs(ctx) == REDISMODULE_ERR) {
if (tls_cfg) {
RedisModule_FreeString(ctx, tls_cfg);
tls_cfg = NULL;
}
return REDISMODULE_ERR;
}
...
}
Co-authored-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
2022-08-22 03:53:56 -04:00
|
|
|
./runtest-cluster --tls-module ${{github.event.inputs.cluster_test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
|
2022-11-21 15:53:13 -05:00
|
|
|
test-centos7-tls-module-no-tls:
|
2022-03-22 11:38:01 -04:00
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'tls')
|
2022-03-22 11:38:01 -04:00
|
|
|
container: centos:7
|
|
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: |
|
|
|
|
|
yum -y install centos-release-scl epel-release
|
|
|
|
|
yum -y install devtoolset-7 openssl-devel openssl
|
Build TLS as a loadable module
* Support BUILD_TLS=module to be loaded as a module via config file or
command line. e.g. redis-server --loadmodule redis-tls.so
* Updates to redismodule.h to allow it to be used side by side with
server.h by defining REDISMODULE_CORE_MODULE
* Changes to server.h, redismodule.h and module.c to avoid repeated
type declarations (gcc 4.8 doesn't like these)
* Add a mechanism for non-ABI neutral modules (ones who include
server.h) to refuse loading if they detect not being built together with
redis (release.c)
* Fix wrong signature of RedisModuleDefragFunc, this could break
compilation of a module, but not the ABI
* Move initialization of listeners in server.c to be after loading
the modules
* Config TLS after initialization of listeners
* Init cluster after initialization of listeners
* Add TLS module to CI
* Fix a test suite race conditions:
Now that the listeners are initialized later, it's not sufficient to
wait for the PID message in the log, we need to wait for the "Server
Initialized" message.
* Fix issues with moduleconfigs test as a result from start_server
waiting for "Server Initialized"
* Fix issues with modules/infra test as a result of an additional module
present
Notes about Sentinel:
Sentinel can't really rely on the tls module, since it uses hiredis to
initiate connections and depends on OpenSSL (won't be able to use any
other connection modules for that), so it was decided that when TLS is
built as a module, sentinel does not support TLS at all.
This means that it keeps using redis_tls_ctx and redis_tls_client_ctx directly.
Example code of config in redis-tls.so(may be use in the future):
RedisModuleString *tls_cfg = NULL;
void tlsInfo(RedisModuleInfoCtx *ctx, int for_crash_report) {
UNUSED(for_crash_report);
RedisModule_InfoAddSection(ctx, "");
RedisModule_InfoAddFieldLongLong(ctx, "var", 42);
}
int tlsCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
{
if (argc != 2) return RedisModule_WrongArity(ctx);
return RedisModule_ReplyWithString(ctx, argv[1]);
}
RedisModuleString *getStringConfigCommand(const char *name, void *privdata) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(privdata);
return tls_cfg;
}
int setStringConfigCommand(const char *name, RedisModuleString *new, void *privdata, RedisModuleString **err) {
REDISMODULE_NOT_USED(name);
REDISMODULE_NOT_USED(err);
REDISMODULE_NOT_USED(privdata);
if (tls_cfg) RedisModule_FreeString(NULL, tls_cfg);
RedisModule_RetainString(NULL, new);
tls_cfg = new;
return REDISMODULE_OK;
}
int RedisModule_OnLoad(void *ctx, RedisModuleString **argv, int argc)
{
....
if (RedisModule_CreateCommand(ctx,"tls",tlsCommand,"",0,0,0) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_RegisterStringConfig(ctx, "cfg", "", REDISMODULE_CONFIG_DEFAULT, getStringConfigCommand, setStringConfigCommand, NULL, NULL) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_LoadConfigs(ctx) == REDISMODULE_ERR) {
if (tls_cfg) {
RedisModule_FreeString(ctx, tls_cfg);
tls_cfg = NULL;
}
return REDISMODULE_ERR;
}
...
}
Co-authored-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
2022-08-22 03:53:56 -04:00
|
|
|
scl enable devtoolset-7 "make BUILD_TLS=module REDIS_CFLAGS='-Werror'"
|
2022-03-22 11:38:01 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: |
|
|
|
|
|
yum -y install tcl tcltls tclx
|
|
|
|
|
./utils/gen-test-certs.sh
|
|
|
|
|
- name: test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
|
|
|
|
run: |
|
2021-06-22 10:23:59 -04:00
|
|
|
./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-07-30 06:25:10 -04:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2020-08-17 10:36:50 -04:00
|
|
|
run: |
|
2021-11-09 15:37:18 -05:00
|
|
|
./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2020-07-30 06:25:10 -04:00
|
|
|
- name: sentinel tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2020-08-17 10:36:50 -04:00
|
|
|
run: |
|
2021-06-22 10:23:59 -04:00
|
|
|
./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2020-07-30 06:25:10 -04:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2020-08-17 10:36:50 -04:00
|
|
|
run: |
|
2021-06-22 10:23:59 -04:00
|
|
|
./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
2020-07-30 06:25:10 -04:00
|
|
|
|
2020-09-08 03:59:25 -04:00
|
|
|
test-macos-latest:
|
|
|
|
|
runs-on: macos-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'macos') && !(contains(github.event.inputs.skiptests, 'redis') && contains(github.event.inputs.skiptests, 'modules'))
|
2020-09-08 03:59:25 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2020-09-08 03:59:25 -04:00
|
|
|
- name: make
|
2021-11-29 03:30:35 -05:00
|
|
|
run: make REDIS_CFLAGS='-Werror'
|
2020-09-08 03:59:25 -04:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
Attempt to solve MacOS CI issues in GH Actions (#12013)
The MacOS CI in github actions often hangs without any logs. GH argues that
it's due to resource utilization, either running out of disk space, memory, or CPU
starvation, and thus the runner is terminated.
This PR contains multiple attempts to resolve this:
1. introducing pause_process instead of SIGSTOP, which waits for the process
to stop before resuming the test, possibly resolving race conditions in some tests,
this was a suspect since there was one test that could result in an infinite loop in that
case, in practice this didn't help, but still a good idea to keep.
2. disable the `save` config in many tests that don't need it, specifically ones that use
heavy writes and could create large files.
3. change the `populate` proc to use short pipeline rather than an infinite one.
4. use `--clients 1` in the macos CI so that we don't risk running multiple resource
demanding tests in parallel.
5. enable `--verbose` to be repeated to elevate verbosity and print more info to stdout
when a test or a server starts.
2023-04-12 02:19:21 -04:00
|
|
|
run: ./runtest --accurate --verbose --verbose --clients 1 --no-latency --dump-logs ${{github.event.inputs.test_args}}
|
2020-09-08 03:59:25 -04:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
Attempt to solve MacOS CI issues in GH Actions (#12013)
The MacOS CI in github actions often hangs without any logs. GH argues that
it's due to resource utilization, either running out of disk space, memory, or CPU
starvation, and thus the runner is terminated.
This PR contains multiple attempts to resolve this:
1. introducing pause_process instead of SIGSTOP, which waits for the process
to stop before resuming the test, possibly resolving race conditions in some tests,
this was a suspect since there was one test that could result in an infinite loop in that
case, in practice this didn't help, but still a good idea to keep.
2. disable the `save` config in many tests that don't need it, specifically ones that use
heavy writes and could create large files.
3. change the `populate` proc to use short pipeline rather than an infinite one.
4. use `--clients 1` in the macos CI so that we don't risk running multiple resource
demanding tests in parallel.
5. enable `--verbose` to be repeated to elevate verbosity and print more info to stdout
when a test or a server starts.
2023-04-12 02:19:21 -04:00
|
|
|
run: ./runtest-moduleapi --verbose --verbose --clients 1 --no-latency --dump-logs ${{github.event.inputs.test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
|
|
|
|
|
test-macos-latest-sentinel:
|
|
|
|
|
runs-on: macos-latest
|
|
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'macos') && !contains(github.event.inputs.skiptests, 'sentinel')
|
2022-03-22 11:38:01 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: make REDIS_CFLAGS='-Werror'
|
2020-09-08 03:59:25 -04:00
|
|
|
- name: sentinel tests
|
2021-07-05 01:46:19 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2022-03-22 11:38:01 -04:00
|
|
|
|
|
|
|
|
test-macos-latest-cluster:
|
|
|
|
|
runs-on: macos-latest
|
|
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'macos') && !contains(github.event.inputs.skiptests, 'cluster')
|
2022-03-22 11:38:01 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: make REDIS_CFLAGS='-Werror'
|
2020-09-08 03:59:25 -04:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
2020-09-08 03:59:25 -04:00
|
|
|
|
2021-01-20 07:07:09 -05:00
|
|
|
test-freebsd:
|
2022-07-19 08:30:06 -04:00
|
|
|
runs-on: macos-12
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'freebsd') && !(contains(github.event.inputs.skiptests, 'redis') && contains(github.event.inputs.skiptests, 'modules'))
|
2021-01-20 07:07:09 -05:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2021-01-20 07:07:09 -05:00
|
|
|
- name: test
|
2023-06-27 02:17:34 -04:00
|
|
|
uses: vmactions/freebsd-vm@v0.3.1
|
2021-01-20 07:07:09 -05:00
|
|
|
with:
|
|
|
|
|
usesh: true
|
2021-02-03 10:35:28 -05:00
|
|
|
sync: rsync
|
2022-02-02 03:39:34 -05:00
|
|
|
copyback: false
|
2021-04-25 06:08:46 -04:00
|
|
|
prepare: pkg install -y bash gmake lang/tcl86 lang/tclx
|
2021-02-03 10:35:28 -05:00
|
|
|
run: >
|
2021-06-24 05:50:10 -04:00
|
|
|
gmake || exit 1 ;
|
2021-11-16 14:00:13 -05:00
|
|
|
if echo "${{github.event.inputs.skiptests}}" | grep -vq redis ; then ./runtest --verbose --timeout 2400 --no-latency --dump-logs ${{github.event.inputs.test_args}} || exit 1 ; fi ;
|
|
|
|
|
if echo "${{github.event.inputs.skiptests}}" | grep -vq modules ; then MAKE=gmake ./runtest-moduleapi --verbose --timeout 2400 --no-latency --dump-logs ${{github.event.inputs.test_args}} || exit 1 ; fi ;
|
2022-03-22 11:38:01 -04:00
|
|
|
|
|
|
|
|
test-freebsd-sentinel:
|
2022-07-19 08:30:06 -04:00
|
|
|
runs-on: macos-12
|
2022-03-22 11:38:01 -04:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'freebsd') && !contains(github.event.inputs.skiptests, 'sentinel')
|
2022-03-22 11:38:01 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: test
|
2023-06-27 02:17:34 -04:00
|
|
|
uses: vmactions/freebsd-vm@v0.3.1
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
usesh: true
|
|
|
|
|
sync: rsync
|
|
|
|
|
copyback: false
|
|
|
|
|
prepare: pkg install -y bash gmake lang/tcl86 lang/tclx
|
|
|
|
|
run: >
|
|
|
|
|
gmake || exit 1 ;
|
2021-06-24 05:50:10 -04:00
|
|
|
if echo "${{github.event.inputs.skiptests}}" | grep -vq sentinel ; then ./runtest-sentinel ${{github.event.inputs.cluster_test_args}} || exit 1 ; fi ;
|
2022-03-22 11:38:01 -04:00
|
|
|
|
|
|
|
|
test-freebsd-cluster:
|
2022-07-19 08:30:06 -04:00
|
|
|
runs-on: macos-12
|
2022-03-22 11:38:01 -04:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'freebsd') && !contains(github.event.inputs.skiptests, 'cluster')
|
2022-03-22 11:38:01 -04:00
|
|
|
timeout-minutes: 14400
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: test
|
2023-06-27 02:17:34 -04:00
|
|
|
uses: vmactions/freebsd-vm@v0.3.1
|
2022-03-22 11:38:01 -04:00
|
|
|
with:
|
|
|
|
|
usesh: true
|
|
|
|
|
sync: rsync
|
|
|
|
|
copyback: false
|
|
|
|
|
prepare: pkg install -y bash gmake lang/tcl86 lang/tclx
|
|
|
|
|
run: >
|
|
|
|
|
gmake || exit 1 ;
|
2021-06-24 05:50:10 -04:00
|
|
|
if echo "${{github.event.inputs.skiptests}}" | grep -vq cluster ; then ./runtest-cluster ${{github.event.inputs.cluster_test_args}} || exit 1 ; fi ;
|
2021-02-23 05:57:45 -05:00
|
|
|
|
2021-02-23 10:08:49 -05:00
|
|
|
test-alpine-jemalloc:
|
2021-02-23 05:57:45 -05:00
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'alpine')
|
2021-02-23 05:57:45 -05:00
|
|
|
container: alpine:latest
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2021-02-23 05:57:45 -05:00
|
|
|
- name: make
|
|
|
|
|
run: |
|
|
|
|
|
apk add build-base
|
|
|
|
|
make REDIS_CFLAGS='-Werror'
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: apk add tcl procps tclx
|
2021-02-23 05:57:45 -05:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2021-02-23 05:57:45 -05:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-09 15:37:18 -05:00
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2021-02-23 05:57:45 -05:00
|
|
|
- name: sentinel tests
|
2021-07-05 01:46:19 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2021-02-23 05:57:45 -05:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
2021-02-23 10:08:49 -05:00
|
|
|
|
|
|
|
|
test-alpine-libc-malloc:
|
|
|
|
|
runs-on: ubuntu-latest
|
2021-11-11 07:39:20 -05:00
|
|
|
if: |
|
2022-03-29 11:35:17 -04:00
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'alpine')
|
2021-02-23 10:08:49 -05:00
|
|
|
container: alpine:latest
|
|
|
|
|
steps:
|
2021-06-23 15:13:24 -04:00
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
2022-03-30 09:18:03 -04:00
|
|
|
- uses: actions/checkout@v3
|
2021-06-23 15:13:24 -04:00
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
2021-02-23 10:08:49 -05:00
|
|
|
- name: make
|
|
|
|
|
run: |
|
|
|
|
|
apk add build-base
|
2021-02-25 02:24:41 -05:00
|
|
|
make REDIS_CFLAGS='-Werror' USE_JEMALLOC=no CFLAGS=-DUSE_MALLOC_USABLE_SIZE
|
2021-06-22 10:23:59 -04:00
|
|
|
- name: testprep
|
|
|
|
|
run: apk add tcl procps tclx
|
2021-02-23 10:08:49 -05:00
|
|
|
- name: test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest --accurate --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2021-02-23 10:08:49 -05:00
|
|
|
- name: module api test
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2021-11-09 15:37:18 -05:00
|
|
|
run: ./runtest-moduleapi --verbose --dump-logs ${{github.event.inputs.test_args}}
|
2021-02-23 10:08:49 -05:00
|
|
|
- name: sentinel tests
|
2021-07-05 01:46:19 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-sentinel ${{github.event.inputs.cluster_test_args}}
|
2021-02-23 10:08:49 -05:00
|
|
|
- name: cluster tests
|
2021-06-23 16:56:40 -04:00
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
2021-06-22 10:23:59 -04:00
|
|
|
run: ./runtest-cluster ${{github.event.inputs.cluster_test_args}}
|
Add reply_schema to command json files (internal for now) (#10273)
Work in progress towards implementing a reply schema as part of COMMAND DOCS, see #9845
Since ironing the details of the reply schema of each and every command can take a long time, we
would like to merge this PR when the infrastructure is ready, and let this mature in the unstable branch.
Meanwhile the changes of this PR are internal, they are part of the repo, but do not affect the produced build.
### Background
In #9656 we add a lot of information about Redis commands, but we are missing information about the replies
### Motivation
1. Documentation. This is the primary goal.
2. It should be possible, based on the output of COMMAND, to be able to generate client code in typed
languages. In order to do that, we need Redis to tell us, in detail, what each reply looks like.
3. We would like to build a fuzzer that verifies the reply structure (for now we use the existing
testsuite, see the "Testing" section)
### Schema
The idea is to supply some sort of schema for the various replies of each command.
The schema will describe the conceptual structure of the reply (for generated clients), as defined in RESP3.
Note that the reply structure itself may change, depending on the arguments (e.g. `XINFO STREAM`, with
and without the `FULL` modifier)
We decided to use the standard json-schema (see https://json-schema.org/) as the reply-schema.
Example for `BZPOPMIN`:
```
"reply_schema": {
"oneOf": [
{
"description": "Timeout reached and no elements were popped.",
"type": "null"
},
{
"description": "The keyname, popped member, and its score.",
"type": "array",
"minItems": 3,
"maxItems": 3,
"items": [
{
"description": "Keyname",
"type": "string"
},
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
]
}
```
#### Notes
1. It is ok that some commands' reply structure depends on the arguments and it's the caller's responsibility
to know which is the relevant one. this comes after looking at other request-reply systems like OpenAPI,
where the reply schema can also be oneOf and the caller is responsible to know which schema is the relevant one.
2. The reply schemas will describe RESP3 replies only. even though RESP3 is structured, we want to use reply
schema for documentation (and possibly to create a fuzzer that validates the replies)
3. For documentation, the description field will include an explanation of the scenario in which the reply is sent,
including any relation to arguments. for example, for `ZRANGE`'s two schemas we will need to state that one
is with `WITHSCORES` and the other is without.
4. For documentation, there will be another optional field "notes" in which we will add a short description of
the representation in RESP2, in case it's not trivial (RESP3's `ZRANGE`'s nested array vs. RESP2's flat
array, for example)
Given the above:
1. We can generate the "return" section of all commands in [redis-doc](https://redis.io/commands/)
(given that "description" and "notes" are comprehensive enough)
2. We can generate a client in a strongly typed language (but the return type could be a conceptual
`union` and the caller needs to know which schema is relevant). see the section below for RESP2 support.
3. We can create a fuzzer for RESP3.
### Limitations (because we are using the standard json-schema)
The problem is that Redis' replies are more diverse than what the json format allows. This means that,
when we convert the reply to a json (in order to validate the schema against it), we lose information (see
the "Testing" section below).
The other option would have been to extend the standard json-schema (and json format) to include stuff
like sets, bulk-strings, error-string, etc. but that would mean also extending the schema-validator - and that
seemed like too much work, so we decided to compromise.
Examples:
1. We cannot tell the difference between an "array" and a "set"
2. We cannot tell the difference between simple-string and bulk-string
3. we cannot verify true uniqueness of items in commands like ZRANGE: json-schema doesn't cover the
case of two identical members with different scores (e.g. `[["m1",6],["m1",7]]`) because `uniqueItems`
compares (member,score) tuples and not just the member name.
### Testing
This commit includes some changes inside Redis in order to verify the schemas (existing and future ones)
are indeed correct (i.e. describe the actual response of Redis).
To do that, we added a debugging feature to Redis that causes it to produce a log of all the commands
it executed and their replies.
For that, Redis needs to be compiled with `-DLOG_REQ_RES` and run with
`--reg-res-logfile <file> --client-default-resp 3` (the testsuite already does that if you run it with
`--log-req-res --force-resp3`)
You should run the testsuite with the above args (and `--dont-clean`) in order to make Redis generate
`.reqres` files (same dir as the `stdout` files) which contain request-response pairs.
These files are later on processed by `./utils/req-res-log-validator.py` which does:
1. Goes over req-res files, generated by redis-servers, spawned by the testsuite (see logreqres.c)
2. For each request-response pair, it validates the response against the request's reply_schema
(obtained from the extended COMMAND DOCS)
5. In order to get good coverage of the Redis commands, and all their different replies, we chose to use
the existing redis test suite, rather than attempt to write a fuzzer.
#### Notes about RESP2
1. We will not be able to use the testing tool to verify RESP2 replies (we are ok with that, it's time to
accept RESP3 as the future RESP)
2. Since the majority of the test suite is using RESP2, and we want the server to reply with RESP3
so that we can validate it, we will need to know how to convert the actual reply to the one expected.
- number and boolean are always strings in RESP2 so the conversion is easy
- objects (maps) are always a flat array in RESP2
- others (nested array in RESP3's `ZRANGE` and others) will need some special per-command
handling (so the client will not be totally auto-generated)
Example for ZRANGE:
```
"reply_schema": {
"anyOf": [
{
"description": "A list of member elements",
"type": "array",
"uniqueItems": true,
"items": {
"type": "string"
}
},
{
"description": "Members and their scores. Returned in case `WITHSCORES` was used.",
"notes": "In RESP2 this is returned as a flat array",
"type": "array",
"uniqueItems": true,
"items": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": [
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
}
]
}
```
### Other changes
1. Some tests that behave differently depending on the RESP are now being tested for both RESP,
regardless of the special log-req-res mode ("Pub/Sub PING" for example)
2. Update the history field of CLIENT LIST
3. Added basic tests for commands that were not covered at all by the testsuite
### TODO
- [x] (maybe a different PR) add a "condition" field to anyOf/oneOf schemas that refers to args. e.g.
when `SET` return NULL, the condition is `arguments.get||arguments.condition`, for `OK` the condition
is `!arguments.get`, and for `string` the condition is `arguments.get` - https://github.com/redis/redis/issues/11896
- [x] (maybe a different PR) also run `runtest-cluster` in the req-res logging mode
- [x] add the new tests to GH actions (i.e. compile with `-DLOG_REQ_RES`, run the tests, and run the validator)
- [x] (maybe a different PR) figure out a way to warn about (sub)schemas that are uncovered by the output
of the tests - https://github.com/redis/redis/issues/11897
- [x] (probably a separate PR) add all missing schemas
- [x] check why "SDOWN is triggered by misconfigured instance replying with errors" fails with --log-req-res
- [x] move the response transformers to their own file (run both regular, cluster, and sentinel tests - need to
fight with the tcl including mechanism a bit)
- [x] issue: module API - https://github.com/redis/redis/issues/11898
- [x] (probably a separate PR): improve schemas: add `required` to `object`s - https://github.com/redis/redis/issues/11899
Co-authored-by: Ozan Tezcan <ozantezcan@gmail.com>
Co-authored-by: Hanna Fadida <hanna.fadida@redislabs.com>
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Shaya Potter <shaya@redislabs.com>
2023-03-11 03:14:16 -05:00
|
|
|
|
|
|
|
|
reply-schemas-validator:
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
timeout-minutes: 14400
|
|
|
|
|
if: |
|
|
|
|
|
(github.event_name == 'workflow_dispatch' || (github.event_name != 'workflow_dispatch' && github.repository == 'redis/redis')) &&
|
|
|
|
|
!contains(github.event.inputs.skipjobs, 'reply-schema')
|
|
|
|
|
steps:
|
|
|
|
|
- name: prep
|
|
|
|
|
if: github.event_name == 'workflow_dispatch'
|
|
|
|
|
run: |
|
|
|
|
|
echo "GITHUB_REPOSITORY=${{github.event.inputs.use_repo}}" >> $GITHUB_ENV
|
|
|
|
|
echo "GITHUB_HEAD_REF=${{github.event.inputs.use_git_ref}}" >> $GITHUB_ENV
|
2023-04-12 05:23:50 -04:00
|
|
|
echo "skipjobs: ${{github.event.inputs.skipjobs}}"
|
|
|
|
|
echo "skiptests: ${{github.event.inputs.skiptests}}"
|
|
|
|
|
echo "test_args: ${{github.event.inputs.test_args}}"
|
|
|
|
|
echo "cluster_test_args: ${{github.event.inputs.cluster_test_args}}"
|
Add reply_schema to command json files (internal for now) (#10273)
Work in progress towards implementing a reply schema as part of COMMAND DOCS, see #9845
Since ironing the details of the reply schema of each and every command can take a long time, we
would like to merge this PR when the infrastructure is ready, and let this mature in the unstable branch.
Meanwhile the changes of this PR are internal, they are part of the repo, but do not affect the produced build.
### Background
In #9656 we add a lot of information about Redis commands, but we are missing information about the replies
### Motivation
1. Documentation. This is the primary goal.
2. It should be possible, based on the output of COMMAND, to be able to generate client code in typed
languages. In order to do that, we need Redis to tell us, in detail, what each reply looks like.
3. We would like to build a fuzzer that verifies the reply structure (for now we use the existing
testsuite, see the "Testing" section)
### Schema
The idea is to supply some sort of schema for the various replies of each command.
The schema will describe the conceptual structure of the reply (for generated clients), as defined in RESP3.
Note that the reply structure itself may change, depending on the arguments (e.g. `XINFO STREAM`, with
and without the `FULL` modifier)
We decided to use the standard json-schema (see https://json-schema.org/) as the reply-schema.
Example for `BZPOPMIN`:
```
"reply_schema": {
"oneOf": [
{
"description": "Timeout reached and no elements were popped.",
"type": "null"
},
{
"description": "The keyname, popped member, and its score.",
"type": "array",
"minItems": 3,
"maxItems": 3,
"items": [
{
"description": "Keyname",
"type": "string"
},
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
]
}
```
#### Notes
1. It is ok that some commands' reply structure depends on the arguments and it's the caller's responsibility
to know which is the relevant one. this comes after looking at other request-reply systems like OpenAPI,
where the reply schema can also be oneOf and the caller is responsible to know which schema is the relevant one.
2. The reply schemas will describe RESP3 replies only. even though RESP3 is structured, we want to use reply
schema for documentation (and possibly to create a fuzzer that validates the replies)
3. For documentation, the description field will include an explanation of the scenario in which the reply is sent,
including any relation to arguments. for example, for `ZRANGE`'s two schemas we will need to state that one
is with `WITHSCORES` and the other is without.
4. For documentation, there will be another optional field "notes" in which we will add a short description of
the representation in RESP2, in case it's not trivial (RESP3's `ZRANGE`'s nested array vs. RESP2's flat
array, for example)
Given the above:
1. We can generate the "return" section of all commands in [redis-doc](https://redis.io/commands/)
(given that "description" and "notes" are comprehensive enough)
2. We can generate a client in a strongly typed language (but the return type could be a conceptual
`union` and the caller needs to know which schema is relevant). see the section below for RESP2 support.
3. We can create a fuzzer for RESP3.
### Limitations (because we are using the standard json-schema)
The problem is that Redis' replies are more diverse than what the json format allows. This means that,
when we convert the reply to a json (in order to validate the schema against it), we lose information (see
the "Testing" section below).
The other option would have been to extend the standard json-schema (and json format) to include stuff
like sets, bulk-strings, error-string, etc. but that would mean also extending the schema-validator - and that
seemed like too much work, so we decided to compromise.
Examples:
1. We cannot tell the difference between an "array" and a "set"
2. We cannot tell the difference between simple-string and bulk-string
3. we cannot verify true uniqueness of items in commands like ZRANGE: json-schema doesn't cover the
case of two identical members with different scores (e.g. `[["m1",6],["m1",7]]`) because `uniqueItems`
compares (member,score) tuples and not just the member name.
### Testing
This commit includes some changes inside Redis in order to verify the schemas (existing and future ones)
are indeed correct (i.e. describe the actual response of Redis).
To do that, we added a debugging feature to Redis that causes it to produce a log of all the commands
it executed and their replies.
For that, Redis needs to be compiled with `-DLOG_REQ_RES` and run with
`--reg-res-logfile <file> --client-default-resp 3` (the testsuite already does that if you run it with
`--log-req-res --force-resp3`)
You should run the testsuite with the above args (and `--dont-clean`) in order to make Redis generate
`.reqres` files (same dir as the `stdout` files) which contain request-response pairs.
These files are later on processed by `./utils/req-res-log-validator.py` which does:
1. Goes over req-res files, generated by redis-servers, spawned by the testsuite (see logreqres.c)
2. For each request-response pair, it validates the response against the request's reply_schema
(obtained from the extended COMMAND DOCS)
5. In order to get good coverage of the Redis commands, and all their different replies, we chose to use
the existing redis test suite, rather than attempt to write a fuzzer.
#### Notes about RESP2
1. We will not be able to use the testing tool to verify RESP2 replies (we are ok with that, it's time to
accept RESP3 as the future RESP)
2. Since the majority of the test suite is using RESP2, and we want the server to reply with RESP3
so that we can validate it, we will need to know how to convert the actual reply to the one expected.
- number and boolean are always strings in RESP2 so the conversion is easy
- objects (maps) are always a flat array in RESP2
- others (nested array in RESP3's `ZRANGE` and others) will need some special per-command
handling (so the client will not be totally auto-generated)
Example for ZRANGE:
```
"reply_schema": {
"anyOf": [
{
"description": "A list of member elements",
"type": "array",
"uniqueItems": true,
"items": {
"type": "string"
}
},
{
"description": "Members and their scores. Returned in case `WITHSCORES` was used.",
"notes": "In RESP2 this is returned as a flat array",
"type": "array",
"uniqueItems": true,
"items": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": [
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
}
]
}
```
### Other changes
1. Some tests that behave differently depending on the RESP are now being tested for both RESP,
regardless of the special log-req-res mode ("Pub/Sub PING" for example)
2. Update the history field of CLIENT LIST
3. Added basic tests for commands that were not covered at all by the testsuite
### TODO
- [x] (maybe a different PR) add a "condition" field to anyOf/oneOf schemas that refers to args. e.g.
when `SET` return NULL, the condition is `arguments.get||arguments.condition`, for `OK` the condition
is `!arguments.get`, and for `string` the condition is `arguments.get` - https://github.com/redis/redis/issues/11896
- [x] (maybe a different PR) also run `runtest-cluster` in the req-res logging mode
- [x] add the new tests to GH actions (i.e. compile with `-DLOG_REQ_RES`, run the tests, and run the validator)
- [x] (maybe a different PR) figure out a way to warn about (sub)schemas that are uncovered by the output
of the tests - https://github.com/redis/redis/issues/11897
- [x] (probably a separate PR) add all missing schemas
- [x] check why "SDOWN is triggered by misconfigured instance replying with errors" fails with --log-req-res
- [x] move the response transformers to their own file (run both regular, cluster, and sentinel tests - need to
fight with the tcl including mechanism a bit)
- [x] issue: module API - https://github.com/redis/redis/issues/11898
- [x] (probably a separate PR): improve schemas: add `required` to `object`s - https://github.com/redis/redis/issues/11899
Co-authored-by: Ozan Tezcan <ozantezcan@gmail.com>
Co-authored-by: Hanna Fadida <hanna.fadida@redislabs.com>
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Shaya Potter <shaya@redislabs.com>
2023-03-11 03:14:16 -05:00
|
|
|
- uses: actions/checkout@v3
|
|
|
|
|
with:
|
|
|
|
|
repository: ${{ env.GITHUB_REPOSITORY }}
|
|
|
|
|
ref: ${{ env.GITHUB_HEAD_REF }}
|
|
|
|
|
- name: make
|
|
|
|
|
run: make REDIS_CFLAGS='-Werror -DLOG_REQ_RES'
|
|
|
|
|
- name: testprep
|
|
|
|
|
run: sudo apt-get install tcl8.6 tclx
|
|
|
|
|
- name: test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'redis')
|
2023-03-23 04:49:09 -04:00
|
|
|
run: ./runtest --log-req-res --no-latency --dont-clean --force-resp3 --tags -slow --verbose --dump-logs ${{github.event.inputs.test_args}}
|
Add reply_schema to command json files (internal for now) (#10273)
Work in progress towards implementing a reply schema as part of COMMAND DOCS, see #9845
Since ironing the details of the reply schema of each and every command can take a long time, we
would like to merge this PR when the infrastructure is ready, and let this mature in the unstable branch.
Meanwhile the changes of this PR are internal, they are part of the repo, but do not affect the produced build.
### Background
In #9656 we add a lot of information about Redis commands, but we are missing information about the replies
### Motivation
1. Documentation. This is the primary goal.
2. It should be possible, based on the output of COMMAND, to be able to generate client code in typed
languages. In order to do that, we need Redis to tell us, in detail, what each reply looks like.
3. We would like to build a fuzzer that verifies the reply structure (for now we use the existing
testsuite, see the "Testing" section)
### Schema
The idea is to supply some sort of schema for the various replies of each command.
The schema will describe the conceptual structure of the reply (for generated clients), as defined in RESP3.
Note that the reply structure itself may change, depending on the arguments (e.g. `XINFO STREAM`, with
and without the `FULL` modifier)
We decided to use the standard json-schema (see https://json-schema.org/) as the reply-schema.
Example for `BZPOPMIN`:
```
"reply_schema": {
"oneOf": [
{
"description": "Timeout reached and no elements were popped.",
"type": "null"
},
{
"description": "The keyname, popped member, and its score.",
"type": "array",
"minItems": 3,
"maxItems": 3,
"items": [
{
"description": "Keyname",
"type": "string"
},
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
]
}
```
#### Notes
1. It is ok that some commands' reply structure depends on the arguments and it's the caller's responsibility
to know which is the relevant one. this comes after looking at other request-reply systems like OpenAPI,
where the reply schema can also be oneOf and the caller is responsible to know which schema is the relevant one.
2. The reply schemas will describe RESP3 replies only. even though RESP3 is structured, we want to use reply
schema for documentation (and possibly to create a fuzzer that validates the replies)
3. For documentation, the description field will include an explanation of the scenario in which the reply is sent,
including any relation to arguments. for example, for `ZRANGE`'s two schemas we will need to state that one
is with `WITHSCORES` and the other is without.
4. For documentation, there will be another optional field "notes" in which we will add a short description of
the representation in RESP2, in case it's not trivial (RESP3's `ZRANGE`'s nested array vs. RESP2's flat
array, for example)
Given the above:
1. We can generate the "return" section of all commands in [redis-doc](https://redis.io/commands/)
(given that "description" and "notes" are comprehensive enough)
2. We can generate a client in a strongly typed language (but the return type could be a conceptual
`union` and the caller needs to know which schema is relevant). see the section below for RESP2 support.
3. We can create a fuzzer for RESP3.
### Limitations (because we are using the standard json-schema)
The problem is that Redis' replies are more diverse than what the json format allows. This means that,
when we convert the reply to a json (in order to validate the schema against it), we lose information (see
the "Testing" section below).
The other option would have been to extend the standard json-schema (and json format) to include stuff
like sets, bulk-strings, error-string, etc. but that would mean also extending the schema-validator - and that
seemed like too much work, so we decided to compromise.
Examples:
1. We cannot tell the difference between an "array" and a "set"
2. We cannot tell the difference between simple-string and bulk-string
3. we cannot verify true uniqueness of items in commands like ZRANGE: json-schema doesn't cover the
case of two identical members with different scores (e.g. `[["m1",6],["m1",7]]`) because `uniqueItems`
compares (member,score) tuples and not just the member name.
### Testing
This commit includes some changes inside Redis in order to verify the schemas (existing and future ones)
are indeed correct (i.e. describe the actual response of Redis).
To do that, we added a debugging feature to Redis that causes it to produce a log of all the commands
it executed and their replies.
For that, Redis needs to be compiled with `-DLOG_REQ_RES` and run with
`--reg-res-logfile <file> --client-default-resp 3` (the testsuite already does that if you run it with
`--log-req-res --force-resp3`)
You should run the testsuite with the above args (and `--dont-clean`) in order to make Redis generate
`.reqres` files (same dir as the `stdout` files) which contain request-response pairs.
These files are later on processed by `./utils/req-res-log-validator.py` which does:
1. Goes over req-res files, generated by redis-servers, spawned by the testsuite (see logreqres.c)
2. For each request-response pair, it validates the response against the request's reply_schema
(obtained from the extended COMMAND DOCS)
5. In order to get good coverage of the Redis commands, and all their different replies, we chose to use
the existing redis test suite, rather than attempt to write a fuzzer.
#### Notes about RESP2
1. We will not be able to use the testing tool to verify RESP2 replies (we are ok with that, it's time to
accept RESP3 as the future RESP)
2. Since the majority of the test suite is using RESP2, and we want the server to reply with RESP3
so that we can validate it, we will need to know how to convert the actual reply to the one expected.
- number and boolean are always strings in RESP2 so the conversion is easy
- objects (maps) are always a flat array in RESP2
- others (nested array in RESP3's `ZRANGE` and others) will need some special per-command
handling (so the client will not be totally auto-generated)
Example for ZRANGE:
```
"reply_schema": {
"anyOf": [
{
"description": "A list of member elements",
"type": "array",
"uniqueItems": true,
"items": {
"type": "string"
}
},
{
"description": "Members and their scores. Returned in case `WITHSCORES` was used.",
"notes": "In RESP2 this is returned as a flat array",
"type": "array",
"uniqueItems": true,
"items": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": [
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
}
]
}
```
### Other changes
1. Some tests that behave differently depending on the RESP are now being tested for both RESP,
regardless of the special log-req-res mode ("Pub/Sub PING" for example)
2. Update the history field of CLIENT LIST
3. Added basic tests for commands that were not covered at all by the testsuite
### TODO
- [x] (maybe a different PR) add a "condition" field to anyOf/oneOf schemas that refers to args. e.g.
when `SET` return NULL, the condition is `arguments.get||arguments.condition`, for `OK` the condition
is `!arguments.get`, and for `string` the condition is `arguments.get` - https://github.com/redis/redis/issues/11896
- [x] (maybe a different PR) also run `runtest-cluster` in the req-res logging mode
- [x] add the new tests to GH actions (i.e. compile with `-DLOG_REQ_RES`, run the tests, and run the validator)
- [x] (maybe a different PR) figure out a way to warn about (sub)schemas that are uncovered by the output
of the tests - https://github.com/redis/redis/issues/11897
- [x] (probably a separate PR) add all missing schemas
- [x] check why "SDOWN is triggered by misconfigured instance replying with errors" fails with --log-req-res
- [x] move the response transformers to their own file (run both regular, cluster, and sentinel tests - need to
fight with the tcl including mechanism a bit)
- [x] issue: module API - https://github.com/redis/redis/issues/11898
- [x] (probably a separate PR): improve schemas: add `required` to `object`s - https://github.com/redis/redis/issues/11899
Co-authored-by: Ozan Tezcan <ozantezcan@gmail.com>
Co-authored-by: Hanna Fadida <hanna.fadida@redislabs.com>
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Shaya Potter <shaya@redislabs.com>
2023-03-11 03:14:16 -05:00
|
|
|
- name: module api test
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'modules')
|
2023-03-23 04:49:09 -04:00
|
|
|
run: ./runtest-moduleapi --log-req-res --no-latency --dont-clean --force-resp3 --dont-pre-clean --verbose --dump-logs ${{github.event.inputs.test_args}}
|
Add reply_schema to command json files (internal for now) (#10273)
Work in progress towards implementing a reply schema as part of COMMAND DOCS, see #9845
Since ironing the details of the reply schema of each and every command can take a long time, we
would like to merge this PR when the infrastructure is ready, and let this mature in the unstable branch.
Meanwhile the changes of this PR are internal, they are part of the repo, but do not affect the produced build.
### Background
In #9656 we add a lot of information about Redis commands, but we are missing information about the replies
### Motivation
1. Documentation. This is the primary goal.
2. It should be possible, based on the output of COMMAND, to be able to generate client code in typed
languages. In order to do that, we need Redis to tell us, in detail, what each reply looks like.
3. We would like to build a fuzzer that verifies the reply structure (for now we use the existing
testsuite, see the "Testing" section)
### Schema
The idea is to supply some sort of schema for the various replies of each command.
The schema will describe the conceptual structure of the reply (for generated clients), as defined in RESP3.
Note that the reply structure itself may change, depending on the arguments (e.g. `XINFO STREAM`, with
and without the `FULL` modifier)
We decided to use the standard json-schema (see https://json-schema.org/) as the reply-schema.
Example for `BZPOPMIN`:
```
"reply_schema": {
"oneOf": [
{
"description": "Timeout reached and no elements were popped.",
"type": "null"
},
{
"description": "The keyname, popped member, and its score.",
"type": "array",
"minItems": 3,
"maxItems": 3,
"items": [
{
"description": "Keyname",
"type": "string"
},
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
]
}
```
#### Notes
1. It is ok that some commands' reply structure depends on the arguments and it's the caller's responsibility
to know which is the relevant one. this comes after looking at other request-reply systems like OpenAPI,
where the reply schema can also be oneOf and the caller is responsible to know which schema is the relevant one.
2. The reply schemas will describe RESP3 replies only. even though RESP3 is structured, we want to use reply
schema for documentation (and possibly to create a fuzzer that validates the replies)
3. For documentation, the description field will include an explanation of the scenario in which the reply is sent,
including any relation to arguments. for example, for `ZRANGE`'s two schemas we will need to state that one
is with `WITHSCORES` and the other is without.
4. For documentation, there will be another optional field "notes" in which we will add a short description of
the representation in RESP2, in case it's not trivial (RESP3's `ZRANGE`'s nested array vs. RESP2's flat
array, for example)
Given the above:
1. We can generate the "return" section of all commands in [redis-doc](https://redis.io/commands/)
(given that "description" and "notes" are comprehensive enough)
2. We can generate a client in a strongly typed language (but the return type could be a conceptual
`union` and the caller needs to know which schema is relevant). see the section below for RESP2 support.
3. We can create a fuzzer for RESP3.
### Limitations (because we are using the standard json-schema)
The problem is that Redis' replies are more diverse than what the json format allows. This means that,
when we convert the reply to a json (in order to validate the schema against it), we lose information (see
the "Testing" section below).
The other option would have been to extend the standard json-schema (and json format) to include stuff
like sets, bulk-strings, error-string, etc. but that would mean also extending the schema-validator - and that
seemed like too much work, so we decided to compromise.
Examples:
1. We cannot tell the difference between an "array" and a "set"
2. We cannot tell the difference between simple-string and bulk-string
3. we cannot verify true uniqueness of items in commands like ZRANGE: json-schema doesn't cover the
case of two identical members with different scores (e.g. `[["m1",6],["m1",7]]`) because `uniqueItems`
compares (member,score) tuples and not just the member name.
### Testing
This commit includes some changes inside Redis in order to verify the schemas (existing and future ones)
are indeed correct (i.e. describe the actual response of Redis).
To do that, we added a debugging feature to Redis that causes it to produce a log of all the commands
it executed and their replies.
For that, Redis needs to be compiled with `-DLOG_REQ_RES` and run with
`--reg-res-logfile <file> --client-default-resp 3` (the testsuite already does that if you run it with
`--log-req-res --force-resp3`)
You should run the testsuite with the above args (and `--dont-clean`) in order to make Redis generate
`.reqres` files (same dir as the `stdout` files) which contain request-response pairs.
These files are later on processed by `./utils/req-res-log-validator.py` which does:
1. Goes over req-res files, generated by redis-servers, spawned by the testsuite (see logreqres.c)
2. For each request-response pair, it validates the response against the request's reply_schema
(obtained from the extended COMMAND DOCS)
5. In order to get good coverage of the Redis commands, and all their different replies, we chose to use
the existing redis test suite, rather than attempt to write a fuzzer.
#### Notes about RESP2
1. We will not be able to use the testing tool to verify RESP2 replies (we are ok with that, it's time to
accept RESP3 as the future RESP)
2. Since the majority of the test suite is using RESP2, and we want the server to reply with RESP3
so that we can validate it, we will need to know how to convert the actual reply to the one expected.
- number and boolean are always strings in RESP2 so the conversion is easy
- objects (maps) are always a flat array in RESP2
- others (nested array in RESP3's `ZRANGE` and others) will need some special per-command
handling (so the client will not be totally auto-generated)
Example for ZRANGE:
```
"reply_schema": {
"anyOf": [
{
"description": "A list of member elements",
"type": "array",
"uniqueItems": true,
"items": {
"type": "string"
}
},
{
"description": "Members and their scores. Returned in case `WITHSCORES` was used.",
"notes": "In RESP2 this is returned as a flat array",
"type": "array",
"uniqueItems": true,
"items": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": [
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
}
]
}
```
### Other changes
1. Some tests that behave differently depending on the RESP are now being tested for both RESP,
regardless of the special log-req-res mode ("Pub/Sub PING" for example)
2. Update the history field of CLIENT LIST
3. Added basic tests for commands that were not covered at all by the testsuite
### TODO
- [x] (maybe a different PR) add a "condition" field to anyOf/oneOf schemas that refers to args. e.g.
when `SET` return NULL, the condition is `arguments.get||arguments.condition`, for `OK` the condition
is `!arguments.get`, and for `string` the condition is `arguments.get` - https://github.com/redis/redis/issues/11896
- [x] (maybe a different PR) also run `runtest-cluster` in the req-res logging mode
- [x] add the new tests to GH actions (i.e. compile with `-DLOG_REQ_RES`, run the tests, and run the validator)
- [x] (maybe a different PR) figure out a way to warn about (sub)schemas that are uncovered by the output
of the tests - https://github.com/redis/redis/issues/11897
- [x] (probably a separate PR) add all missing schemas
- [x] check why "SDOWN is triggered by misconfigured instance replying with errors" fails with --log-req-res
- [x] move the response transformers to their own file (run both regular, cluster, and sentinel tests - need to
fight with the tcl including mechanism a bit)
- [x] issue: module API - https://github.com/redis/redis/issues/11898
- [x] (probably a separate PR): improve schemas: add `required` to `object`s - https://github.com/redis/redis/issues/11899
Co-authored-by: Ozan Tezcan <ozantezcan@gmail.com>
Co-authored-by: Hanna Fadida <hanna.fadida@redislabs.com>
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Shaya Potter <shaya@redislabs.com>
2023-03-11 03:14:16 -05:00
|
|
|
- name: sentinel tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'sentinel')
|
|
|
|
|
run: ./runtest-sentinel --log-req-res --dont-clean --force-resp3 ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: cluster tests
|
|
|
|
|
if: true && !contains(github.event.inputs.skiptests, 'cluster')
|
|
|
|
|
run: ./runtest-cluster --log-req-res --dont-clean --force-resp3 ${{github.event.inputs.cluster_test_args}}
|
|
|
|
|
- name: Install Python dependencies
|
|
|
|
|
uses: py-actions/py-dependency-install@v4
|
|
|
|
|
with:
|
|
|
|
|
path: "./utils/req-res-validator/requirements.txt"
|
|
|
|
|
- name: validator
|
2023-04-12 05:23:50 -04:00
|
|
|
run: ./utils/req-res-log-validator.py --verbose --fail-missing-reply-schemas ${{ (!contains(github.event.inputs.skiptests, 'redis') && !contains(github.event.inputs.skiptests, 'module') && !contains(github.event.inputs.sentinel, 'redis') && !contains(github.event.inputs.skiptests, 'cluster')) && github.event.inputs.test_args == '' && github.event.inputs.cluster_test_args == '' && '--fail-commands-not-all-hit' || '' }}
|
Add reply_schema to command json files (internal for now) (#10273)
Work in progress towards implementing a reply schema as part of COMMAND DOCS, see #9845
Since ironing the details of the reply schema of each and every command can take a long time, we
would like to merge this PR when the infrastructure is ready, and let this mature in the unstable branch.
Meanwhile the changes of this PR are internal, they are part of the repo, but do not affect the produced build.
### Background
In #9656 we add a lot of information about Redis commands, but we are missing information about the replies
### Motivation
1. Documentation. This is the primary goal.
2. It should be possible, based on the output of COMMAND, to be able to generate client code in typed
languages. In order to do that, we need Redis to tell us, in detail, what each reply looks like.
3. We would like to build a fuzzer that verifies the reply structure (for now we use the existing
testsuite, see the "Testing" section)
### Schema
The idea is to supply some sort of schema for the various replies of each command.
The schema will describe the conceptual structure of the reply (for generated clients), as defined in RESP3.
Note that the reply structure itself may change, depending on the arguments (e.g. `XINFO STREAM`, with
and without the `FULL` modifier)
We decided to use the standard json-schema (see https://json-schema.org/) as the reply-schema.
Example for `BZPOPMIN`:
```
"reply_schema": {
"oneOf": [
{
"description": "Timeout reached and no elements were popped.",
"type": "null"
},
{
"description": "The keyname, popped member, and its score.",
"type": "array",
"minItems": 3,
"maxItems": 3,
"items": [
{
"description": "Keyname",
"type": "string"
},
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
]
}
```
#### Notes
1. It is ok that some commands' reply structure depends on the arguments and it's the caller's responsibility
to know which is the relevant one. this comes after looking at other request-reply systems like OpenAPI,
where the reply schema can also be oneOf and the caller is responsible to know which schema is the relevant one.
2. The reply schemas will describe RESP3 replies only. even though RESP3 is structured, we want to use reply
schema for documentation (and possibly to create a fuzzer that validates the replies)
3. For documentation, the description field will include an explanation of the scenario in which the reply is sent,
including any relation to arguments. for example, for `ZRANGE`'s two schemas we will need to state that one
is with `WITHSCORES` and the other is without.
4. For documentation, there will be another optional field "notes" in which we will add a short description of
the representation in RESP2, in case it's not trivial (RESP3's `ZRANGE`'s nested array vs. RESP2's flat
array, for example)
Given the above:
1. We can generate the "return" section of all commands in [redis-doc](https://redis.io/commands/)
(given that "description" and "notes" are comprehensive enough)
2. We can generate a client in a strongly typed language (but the return type could be a conceptual
`union` and the caller needs to know which schema is relevant). see the section below for RESP2 support.
3. We can create a fuzzer for RESP3.
### Limitations (because we are using the standard json-schema)
The problem is that Redis' replies are more diverse than what the json format allows. This means that,
when we convert the reply to a json (in order to validate the schema against it), we lose information (see
the "Testing" section below).
The other option would have been to extend the standard json-schema (and json format) to include stuff
like sets, bulk-strings, error-string, etc. but that would mean also extending the schema-validator - and that
seemed like too much work, so we decided to compromise.
Examples:
1. We cannot tell the difference between an "array" and a "set"
2. We cannot tell the difference between simple-string and bulk-string
3. we cannot verify true uniqueness of items in commands like ZRANGE: json-schema doesn't cover the
case of two identical members with different scores (e.g. `[["m1",6],["m1",7]]`) because `uniqueItems`
compares (member,score) tuples and not just the member name.
### Testing
This commit includes some changes inside Redis in order to verify the schemas (existing and future ones)
are indeed correct (i.e. describe the actual response of Redis).
To do that, we added a debugging feature to Redis that causes it to produce a log of all the commands
it executed and their replies.
For that, Redis needs to be compiled with `-DLOG_REQ_RES` and run with
`--reg-res-logfile <file> --client-default-resp 3` (the testsuite already does that if you run it with
`--log-req-res --force-resp3`)
You should run the testsuite with the above args (and `--dont-clean`) in order to make Redis generate
`.reqres` files (same dir as the `stdout` files) which contain request-response pairs.
These files are later on processed by `./utils/req-res-log-validator.py` which does:
1. Goes over req-res files, generated by redis-servers, spawned by the testsuite (see logreqres.c)
2. For each request-response pair, it validates the response against the request's reply_schema
(obtained from the extended COMMAND DOCS)
5. In order to get good coverage of the Redis commands, and all their different replies, we chose to use
the existing redis test suite, rather than attempt to write a fuzzer.
#### Notes about RESP2
1. We will not be able to use the testing tool to verify RESP2 replies (we are ok with that, it's time to
accept RESP3 as the future RESP)
2. Since the majority of the test suite is using RESP2, and we want the server to reply with RESP3
so that we can validate it, we will need to know how to convert the actual reply to the one expected.
- number and boolean are always strings in RESP2 so the conversion is easy
- objects (maps) are always a flat array in RESP2
- others (nested array in RESP3's `ZRANGE` and others) will need some special per-command
handling (so the client will not be totally auto-generated)
Example for ZRANGE:
```
"reply_schema": {
"anyOf": [
{
"description": "A list of member elements",
"type": "array",
"uniqueItems": true,
"items": {
"type": "string"
}
},
{
"description": "Members and their scores. Returned in case `WITHSCORES` was used.",
"notes": "In RESP2 this is returned as a flat array",
"type": "array",
"uniqueItems": true,
"items": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": [
{
"description": "Member",
"type": "string"
},
{
"description": "Score",
"type": "number"
}
]
}
}
]
}
```
### Other changes
1. Some tests that behave differently depending on the RESP are now being tested for both RESP,
regardless of the special log-req-res mode ("Pub/Sub PING" for example)
2. Update the history field of CLIENT LIST
3. Added basic tests for commands that were not covered at all by the testsuite
### TODO
- [x] (maybe a different PR) add a "condition" field to anyOf/oneOf schemas that refers to args. e.g.
when `SET` return NULL, the condition is `arguments.get||arguments.condition`, for `OK` the condition
is `!arguments.get`, and for `string` the condition is `arguments.get` - https://github.com/redis/redis/issues/11896
- [x] (maybe a different PR) also run `runtest-cluster` in the req-res logging mode
- [x] add the new tests to GH actions (i.e. compile with `-DLOG_REQ_RES`, run the tests, and run the validator)
- [x] (maybe a different PR) figure out a way to warn about (sub)schemas that are uncovered by the output
of the tests - https://github.com/redis/redis/issues/11897
- [x] (probably a separate PR) add all missing schemas
- [x] check why "SDOWN is triggered by misconfigured instance replying with errors" fails with --log-req-res
- [x] move the response transformers to their own file (run both regular, cluster, and sentinel tests - need to
fight with the tcl including mechanism a bit)
- [x] issue: module API - https://github.com/redis/redis/issues/11898
- [x] (probably a separate PR): improve schemas: add `required` to `object`s - https://github.com/redis/redis/issues/11899
Co-authored-by: Ozan Tezcan <ozantezcan@gmail.com>
Co-authored-by: Hanna Fadida <hanna.fadida@redislabs.com>
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Shaya Potter <shaya@redislabs.com>
2023-03-11 03:14:16 -05:00
|
|
|
|
