Commits
- Commit:
944358c9247f5fcfc750fe99f5194d51403736f5
- From:
- Sergey Bronnikov <sergeyb@tarantool.org>
- Date:
cmake: fix build with GCC's AddressSanitizer
GNU GCC compiler has AddressSanitizer support since 4.8.0 [1],
but it was unsupported in tarantool's build. The patch
fixes a build by GNU GCC with enabled AddressSanitizer.
1. https://gcc.gnu.org/gcc-4.8/changes.html
NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build
- Commit:
7cf41a1bb9b3f0a2eac82c296a764688f5d8b35c
- From:
- Alexander Turenko <alexander.turenko@tarantool.org>
- Via:
- Alexander Turenko <totktonada.ru@gmail.com>
- Date:
ci: fix module API publish job (again)
The new version of the publishing action leads to the following error:
NOWRAP
```
Error: File not found: '/home/runner/work/_actions/JamesIves/github-pages-deploy-action/v4.6.6/lib/main.js'
```
NOWRAP
Let's revert it to v4.6.4 (because v4.6.5 change was reverted in v4.6.6).
See also https://github.com/JamesIves/github-pages-deploy-action/issues/1697
NO_DOC=no code changes
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC
- Commit:
3e09e9f293925195ddebb13a4fcfd64762e52b89
- From:
- Alexander Turenko <alexander.turenko@tarantool.org>
- Via:
- Alexander Turenko <totktonada.ru@gmail.com>
- Date:
ci: fix module API build/publish job
The `ubuntu-latest` image is now `ubuntu-24.04`, see [1]. The job fails
on this image with the following error:
NOWRAP
```
CMake Error at /usr/local/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
Could NOT find Readline (missing: READLINE_INCLUDE_DIR READLINE_LIBRARY)
```
NOWRAP
It seems, the libreadline-dev package is missing. Let's install it.
Also, update a version of the publishing action to the latest at the
moment. I didn't perform any check, but I guess that a new version of
NodeJS is needed and the latest action version has better support of it.
[1]: https://github.blog/changelog/2024-09-25-actions-new-images-and-ubuntu-latest-changes/
NO_DOC=no code changes
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC
- Commit:
53d02c4d927bf1d20d74a9212d9c3dfaa0f2e3c9
- From:
- Georgiy Belyanin <belyaningeorge@ya.ru>
- Via:
- Alexander Turenko <totktonada.ru@gmail.com>
- Date:
test: specify the dir in the cluster helper
The cluster helper in `test/config-luatest/cluster.lua` is used to
define the clusters in an easy way. Though every time the `cluster.new`
is called it creates a new temporary directory, which is not good when
you're writing a test setting up the directory before the cluster
start.
This patch adds an `opts` object as the fourth parameter for
`cluster.new` and makes the function use `opts.dir` as a key for
specifying the directory to start the cluster.
Example:
```
local dir = '/some/long/dir'
local cluster_config = cbuilder:new(remote_config)
:use_replicaset('r-001')
:add_instance('i-001', {})
:config()
-- The cluster will be started in a new temp directory.
local cluster = cluster.new(g, cluster_config)
-- The cluster will be started in '/some/long/dir'.
local cluster = cluster.new(g, cluster_config, nil, { dir = dir })
```
Needed for testing tarantool/tarantool-ee#870.
NO_CHANGELOG=internal testing helper change
NO_TEST=internal testing helper change
NO_DOC=internal testing helper change
- Commit:
38c6b0d38254d5ebde82cd469366955e808798b0
- From:
- Maksim Tiushev <mandesero@gmail.com>
- Via:
- Alexander Turenko <totktonada.ru@gmail.com>
- Date:
config: grant runtime access to lua_call from config
This patch introduces the ability to grant execution privileges for Lua
functions through declarative configuration, even when the database is
in read-only mode or has an outdated schema version.
Users can specify `lua_call: [<func_name>]`, enabling the execution of
specified Lua functions (e.g., `failover:execute()` when all instance
are in read-only mode). The `lua_call: [all]` option is also supported,
allowing access to all global Lua functions except built-in ones,
regardless of database mode or status.
Privileges are still written to the database when possible for consistency
and compatibility.
Closes tarantool#10310
@TarantoolBot document
Title: Grant runtime access to Lua functions via configuration
It is now possible to grant execution privileges for Lua functions
through the declarative configuration, even when the database is in
read-only mode or has an outdated schema version.
You can specify function permissions using the `lua_call` option in
the configuration, for example:
```yaml
credentials:
users:
alice:
privileges:
- permissions: [execute]
lua_call: [my_func]
```
This grants the `alice` user permission to execute the `my_func` Lua
function, regardless of the database's mode or status. The special option
`lua_call: [all]` is also supported, granting access to all global Lua
functions except built-in ones, bypassing database restrictions.
Privileges will still be written to the database when possible to
maintain compatibility and consistency with other privilege types.