Commits
- Commit:
c456ecad7722f43455226bdac6a396ea428789c7
- From:
- Sergey Bronnikov <sergeyb@tarantool.org>
- Date:
build: bump clang version to 19
The patch bumps Clang version from 16 to 19 in workflows that
intended to use the most modern Clang version. Many things
were changed since version 16, see release notes in [1], [2], [3].
The `-Ofast` command-line option has been deprecated in Clang 19,
see [3]. It is advised to switch to `-O3 -ffast-math` if the use
of non-standard math behavior is intended, and -O3 otherwise.
The patch replaces `-Ofast` with `-O3 -ffast-math` to suppress
a message below in a build log:
NO_WRAP
clang-19: warning: argument '-Ofast' is deprecated; use '-O3 -ffast-math' for
the same behavior, or '-O3' to enable only conforming optimizations [-Wdeprecated-ofast]
NO_WRAP
The bump had needed an update of Dockerfile used for building
Docker image used in aforementioned workflows, see pull request
in [4].
1. https://releases.llvm.org/17.0.1/tools/clang/docs/ReleaseNotes.html
2. https://releases.llvm.org/18.1.6/tools/clang/docs/ReleaseNotes.html
3. https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html
4. https://github.com/tarantool/infra/pull/206
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.