The stale bot's `operations-per-run`
(https://github.com/actions/stale#operations-per-run) corresponds to the max
number of API calls it is allowed to make per hour. Currently,
`operations-per-run` is set to 30, which means that the stale bot
can make up to 30 API calls per hour.
With this limit in place, the stale bot is only able to process 400 PRs at a time.
Since there are 900+ PRs in the Ceph repository, we should increase the number of
operations to cover them all. This needs to be done with care though, since GitHub
has a rate limit
(https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting)
depending on business plan.
According to GitHub's documentation on GitHub action requests
(https://docs.github.com/en/rest/overview/resources-in-the-rest-api#requests-from-github-actions),
the rate limit is 1,000 requests per hour per repository when using `GITHUB_TOKEN` (which we are).
For enterprise accounts, GitHub Enterprise Cloud's rate limit applies, and the limit is 15,000
requests per hour per repository.
Based on this information, we should be fine to increase the max `operations-per-run`
to 100. This would cover a little over 1000 PRs, which should be enough
to process the 900-some-odd PRs in the Ceph repository.
Signed-off-by: Laura Flores <lflores@redhat.com>
we are facing following FTBFS on jammy + GCC-11.2 + Cython 0.29 +
CMake 3.22:
creating /home/jenkins-build/build/workspace/ceph-api/build/lib/cython_modules/temp.linux-x86_64-3.10/home/jenkins-build/build/workspace/ceph-api/build/src/pybind/cephfs
compile options: '-I/usr/include/python3.10 -I/usr/include/python3.10 -c'
extra options: '-Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -iquote/home/jenkins-build/build/workspace/ceph-api/src/include -w -Dvoid0=dead_function(void) -D__Pyx_check_single_interpreter(ARG)=ARG ## 0 -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2'
cc: /home/jenkins-build/build/workspace/ceph-api/build/src/pybind/cephfs/cephfs.c
cc: warning: ##: linker input file unused because linking not done
cc: error: ##: linker input file not found: No such file or directory
cc: warning: 0: linker input file unused because linking not done
cc: error: 0: linker input file not found: No such file or directory
it seems cython is not able to escape the space in the "extra options"
anymore, so the "##" and "0" are considered as object files passed to
compiler in addition to cephfs.c.
in this change the spaces are removed to help cython to make the right
decision.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
docs: minor doc fixes of showing in progress clones for a snapshot
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Ramana Raja <rraja@redhat.com>
Reviewed-by: Rishabh Dave <ridave@redhat.com>
Reviewed-by: Neeraj Pratap Singh <neesingh@redhat.com>
Reviewed-by: Kotresh HR <khiremat@redhat.com>
Reviewed-by: Anthony D'Atri <anthony.datri@gmail.com>
Reviewed-by: Dhairya Parmar <dparmar@redhat.com
despite that we are using clang in `run-make-check.sh`, `do_cmake.sh`
is still used by some workflows like jenkins' ceph-pr-api job.
now that we've migrated to C++20, we need to use GCC-11 or up for
building the tree. GCC-11 is installed from PPA repo in
`install-deps.sh`, but to avoid interfere with the build of older
branches which do not use GCC-11, as their builds might break if
we use GCC-11 for building them. we don't use the alternative machinary
to point gcc to gcc-11, see 8f342a32ce.
so, in this change, we try to use the newest GCC in system when
running `do_cmake.sh`.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
in ubuntu 22.04 and debian unstable, the layout (scheme) for system
python module is named "deb_system", the default one is 'posix_local'.
and 'posix_local' installs python modules into paths like
usr/local/lib/python3.10/dist-packages/. hence dh_install fails
when it tries to find the files to be packaged under directory of
usr/lib/python3*/site-packages/.
in this change, the "deb_system" scheme is used if it is available,
and fall back to "posix_prefix" to be backward compatible with older
debian (derivative) distros.
also, update the source directories of pure python's installation
from `site-packages` to `*-packages`, to be compatible with ubuntu focal
and ubuntu jammy. as we are now using the specified scheme instead of
the default one.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
to fix the FTBFS due to following warning:
```
/home/jenkins-build/build/workspace/ceph-windows-pull-requests/ceph/build.deps/src/dokany/dokan/dokan.h:723:22: error: narrowing conversion of '-1' from 'int' to 'long unsigned int' [-Wnarrowing]
723 | #define DOKAN_ERROR -1
| ^
```
also, clean up the following warning:
```
/home/jenkins-build/build/workspace/ceph-windows-pull-requests/ceph/src/dokan/dbg.cc:142:62: warning: NULL used in arithmetic [-Wpointer-arith]
142 | o << "\n\tIsDirectory: " << (DokanFileInfo->IsDirectory != NULL);
|
```
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
to silence warnings like:
```
configure.ac:3671: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:3671: You should run autoupdate.
```
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
this is the prerequisite for implementing the three-way comparison
operator for types which aggregates these basic types
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
the default-generated comparison operators can fulfill our needs.
the order of member variables of `ghobject_t` is adjusted to match
the ordering of `ghobject_t`. the default-generated three-way
comparison operator uses the order in which the member variables
are declared to do the lexical comparison.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
mgr/dashboard: host list tables doesn't show all services deployed
Reviewed-by: Aashish Sharma <aasharma@redhat.com>
Reviewed-by: Nizamudeen A <nia@redhat.com>
Reviewed-by: sunilangadi2 <NOT@FOUND>
to address following failure when generating the building system
using CMake:
```
-- Performing Test HAVE_LIBATOMIC
-- Performing Test HAVE_LIBATOMIC - Failed
CMake Error at cmake/modules/CheckCxxAtomic.cmake:66 (message):
Host compiler /opt/rh/gcc-toolset-11/root/usr/bin/c++ requires libatomic,
but it is not found
```
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
before this change %enable_devtoolset11 is called only when building
with crimson on centos8.
after this change %enable_devtoolset11 is called when building on
centos8. because we've started using gcc-toolset-11 for building
rpm packages on centos8 after the C++20 migration. so, to build
with gcc-11, we need to enable it.
also, because gcc-toolset-11 is used, we have to disable
annotated_build.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
