On 29-11-2020 05:12, kefu chai wrote:
On Sun, Nov 22, 2020 at 5:45 AM Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
Hi,
Since we are adding build targets in github,
I have a question/favour to ask....
Would it be possible to also compile the sources with Clang.
As far as I'm concerned it does not have to be a blocker to get a PR
merged. But it would at least signal that there could be something
wrong with the PR, and it would be appreciated if the submitter
looks into the errors Clang reports.
My FreeBSD ports depend on Clang compilation and I now spent a big
part of the free time during the weekend fixing errors that Clang
trips over. Not leaving much time to actually do development work.
Clang is available on Linux as well, so it would not even have to
be a jenkins setup running on FreeBSD. Perhaps even better so, since
there are also FreeBSD incompatabilities that would be hard for
non-FreeBSDers to fix.
Willem, thanks for bringing this up again. IIRC, we discussed this
before. our jenkins perf test jobs are already using clang-10, see
- https://github.com/ceph/ceph-build/blob/master/ceph-perf-pull-requests/config/definitions/ceph-perf-pull-requests.yml#L173
- https://github.com/ceph/ceph-build/blob/master/ceph-perf-pull-requests/config/definitions/ceph-perf-pull-requests.yml#L62
i think what you are after is the jenkins job triggered by a PR is
created / updated.
Exactly what I looking for, if only to warn submitters that there could
be an issue.
Some of the things I fix, are c++17 things that GCC does not mind but Clang
signals as error (or warning).
And that block my FreeBSD jenkins builds until I fix 'm. Which is not
always easy
since I need to figure out what the C++17 issue is, and what the author
intentions
are. And not all things are trivial, as you know.
i see couple options
- CI on GNU/Linux + Clang hosted in lab:
1. needs to setup a job in ceph-build
2. needs to allocate computing resources for running this job.
- CI on FreeBSD + Clang hosted in lab:
1. needs to make sure we have all necessary patches which apply to master.
2. needs to setup a job in ceph-build
3. needs to allocate computing resources for running this job.
4. needs to have time/admin help on setting up / maintaining the FreeBSD build
- CI on FreeBSD + Clang hosted in somewhere else (in your own Jenkins
setup, for instance)
1. needs to setup a webhook notifying your jenkins
2. the admin needs to take care of the rest on the jenkins side
(computing resources planning, jenkins setup, maintenance, etc)
i think all of these options above needs the help from the community.
ATM I would be happy with the first, since it'll catch the difference in
interpretations between GCC and Clang. Even more if it requires a pass
before a PR can be committed.
The second one would be quite invasive since then it requires the
maintenance
I now do on my private Jenkins runs. And I doubt that there are enough
people
willing to maintain FreeBSD within the current ceph community.
It would also require that I push more of the less important patches,
and keep
a sharper eye on things so FreeBSD building is not continuously failing
due to
a missing patch.
The third one is partly already what is going on. Every 2 hours I sample
github for
changes in master, octopus, nautilus, and then build what is there.
There is only
one jenkins instance doing the CI. I'd have to work on figuring out how
to build
more pipelines to start working parallel.
So sometimes I build a few PRs together. Which is fine for efficiency
purposes,
not for feeding back the build result of a specific PR.
I sort of cheat when building, since I do build in a VM and destroy the
VM everytime.
So I have a compile time below 20 minutes. (At least before I need to
start building Boost
1.74) And the build process is already split into building and testing
as separate jobs.
I would have a 4 node, 2 CPU, 128Mb mem system available to help with
building.
also, the answer in an AMA from Sage 5 years ago still applies. i am
quoting it for your reference:
We've merged patch series fixing the FreeBSD build in the past, but since we don't have CI tests that verify the build we inevitably break it. We're more than happy to take patches or time/admin help to get that set up in the lab so we can keep things working on an ongoing basis, though!
Yup, I know. That was also his answer when I first asked him I he would be
willing to take my PRs... And is also the reason why I running CI in a
FreeBSD jenkins
instance.
FWIW, we still have a pull request adding clang build to gitbuilder,
see https://github.com/ceph/autobuild-ceph/pull/22. the
autoobuild-ceph scripts were used for building Ceph packages before we
migrated to jenkins. somehow that pull request was not merged. i guess
we just don't have the resource for building / testing using Clang by
then. this might have changed now.
Not sure if it makes sense to me, but I'll look into it.
--WjW
In the process it just might catch a possible bug, because Clang
sees life different from GCC.
Like I said: it is a favour to ask.
Thanx,
--WjW
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
