From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Maxim Kokryashkin <max.kokryashkin@gmail.com> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit v3] ci: extend tarantool integration testing Date: Thu, 7 Mar 2024 18:22:05 +0300 [thread overview] Message-ID: <ZenbnWWnHYmntt-B@root> (raw) In-Reply-To: <20240306214724.32017-1-m.kokryashkin@tarantool.org> Hi, Max! Thanks for the fixes! Please, consider my general comments below. 1) Now we have 6 types of names (please correct me if I forgot something): * Build test ... / LuaJIT ... * Exotic builds testing / LuaJIT ... * Sanitizers testing / LuaJIT ... * Static analysis / LuaJIT linters * Testing / LuaJIT ... * Testing / Tarantool ... As part of the patch: I) "Testing / Tarantool ..." is renamed to "Tarantool exotic builds testing / Tarantool ...". I do not agree that these are exotic builds -- these are ordinary builds, where we run the integration of LuaJIT tests under Tarantool. Plus, there is duplicate information that this is Tarantool-related testing. Perhaps we should not change the name of the jobs, meaning that by all "Testing" we mean LuaJIT tests. II) We bring all sorts of other things from Tarantool: * Testing / test-tarantool-static_build / static_build (push) * Tarantool ecosystem integration testing / test-tarantool-integration / tarantool-python / run_tests (push) Here, we have a lot of names that are mixed together and don’t look consistent with the older ones. I would suggest at least starting to fit into the overall picture by renaming it like this, using the following naming (if I understand correctly that we cannot change the job names at the end): * "Integration / Tarantool static_build" or "Integration / Tarantool / static_build" * "Integration / Tarantool ecosystem / ..." or "Integration / Tarantool / ecosystem / ..." I like the first mentioned options more than the second. 2) About all "Integration" workflows mentioned above: I suggest file naming like integration-tarantool-ecosystem.yml etc. for consistency. 3) It would be nice to have an option to skip integration testing. This can be done later. I just thought that sometimes it would be useful to specify the "-no-integration" branch suffix and then not run integration tests with Tarantool (namely "Integration", not our tests under Tarantool) - useful if you are debugging only our tests. On 07.03.24, Maxim Kokryashkin wrote: <snipped> > > Workflow name |+/-| Reason > ----------------------------------------------------------------- > codeql | - | Not relevant to LuaJIT. > coverage | + | Long tests for profilers. > coverity | - | Cron workflow. > debug | + | Tarantool debug build. > debug_aarch64 | + | Tarantool debug build. > debug_asan_clang | + | Tarantool debug build. > default_gcc_centos_7 | + | gcc version (7) Minor: Old gcc version? > freebsd | - | Nightly build. > fuzzing | - | Impossible to bump LuaJIT. > integration | + | Tarantool ecosystem. > jepsen-cluster-txm | - | Manual workflow. > jepsen-cluster | - | Manual workflow. > jepsen-single-instance-txm | - | Cron workflow. > jepsen-single-instance | - | Cron workflow. > lango-stale-reviews | - | Cron workflow. > lint | - | LuaJIT has its own lint. > luajit-integration | + | Exotic LuaJIT options. I suggest the following reasoning: "Run tests under Tarantool" or something like that. > memtx_allocator_based_on_malloc | - | Not relevant to LuaJIT. > osx | - | Nightly build. > out_of_source | + | Out of source build. > packaging | - | No LuaJIT-relevant variety. > perf_cbench | - | Not enabled for PRs. > perf_linkbench_ssd | - | Not enabled for PRs. > perf_micro | - | Not relevant to LuaJIT. > perf_nosqlbench_hash | - | Not enabled for PRs. > perf_nosqlbench_tree | - | Not enabled for PRs. > perf_sysbench | - | Not enabled for PRs. > perf_tpcc | - | Not enabled for PRs. > perf_tpch | - | Not enabled for PRs. > perf_ycsb_hash | - | Not enabled for PRs. > perf_ycsb_tree | - | Not enabled for PRs. > publish-module-api-doc | - | No Doxygen in LuaJIT. > release | + | Tarantool release build. > release_asan_clang | + | Tarantool release build. > release_clang | + | Tarantool release build. > release_lto | + | Tarantool release build. > release_lto_clang | + | Tarantool release build. > reusable_build | - | Utility for integration. > source | - | Not enabled for PRs. > static_build | + | Tarantool static build. > static_build_cmake_linux | - | Just an OOS static build. > static_build_pack_test_deploy | - | Utility for packaging. > submodule_update | - | Not enabled for PRs. > > [1]: https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations > [2]: https://github.com/orgs/community/discussions/45342#discussioncomment-4779360 > --- > Changes in v3: > - Fixed comments as per review by Sergey Kaplun > - Fixed comments as per review by Sergey Bronnikov > > .github/workflows/tarantool-ecosystem.yml | 39 ++++++++ > .github/workflows/tarantool-exotic.yml | 67 +++++++++++++ > .github/workflows/testing.yml | 117 ++++++++++++++++------ <snipped> -- Best regards, Sergey Kaplun
prev parent reply other threads:[~2024-03-07 15:26 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-06 21:47 Maxim Kokryashkin via Tarantool-patches 2024-03-07 15:22 ` Sergey Kaplun via Tarantool-patches [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ZenbnWWnHYmntt-B@root \ --to=tarantool-patches@dev.tarantool.org \ --cc=max.kokryashkin@gmail.com \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit v3] ci: extend tarantool integration testing' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox