You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Josh Elser <jo...@gmail.com> on 2016/01/10 19:10:06 UTC
Apache-hosted CI (was Re: Build error in master branch)
There are actually a number of options.
1. We can enable some jobs that will build Calcite on commit via Jenkins
(https://builds.apache.org).
2. We can enable a PreCommit job which should build every
Patch/PullRequest that is attached to JIRA or Github via Apache Yetus
(https://yetus.apache.org) and provide some verification that a
contribution, from anyone who provides one, compiles, passes tests,
passes checkstyle, etc.
Both should be pretty trivial to set up (just going through the last
steps of getting PreCommit w/ Yetus set up for a different project).
Speak up for what everyone would find beneficial.
- Josh
Vladimir Sitnikov wrote:
> By the way, can we have Apache CI instance?
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
So, I see this as two things. What I did last night is just a regular CI
build that runs periodically to make sure the repository is good. We
will also want to have a PreCommit job which is a TBD for me to hook up
(this is where Yetus will come into play) which will run some changeset
through rules and say yay/nay.
I think I know what I have to do for Yetus configuration-wise, but I
need to prod the Yetus folks about our Github-based workflow. It has the
support to build/test pull requests, but I'm not sure if there is an
example integration for this in Apache-based infra yet. We might be
guinea pigs :)
Julian Hyde wrote:
> Yes. I see this build as the basic minimum, so we want it to pass 100% of the time.
>
> By the way, that means that committers should run through this process BEFORE they commit. If there are even checkstyle errors, they should be fixed before the commit.
>
>> On Feb 9, 2016, at 11:36 AM, Josh Elser<jo...@gmail.com> wrote:
>>
>> Are we good with Jenkins notifications coming to dev@calcite for now?
>>
>> Julian Hyde wrote:
>>> Anyway, don’t worry too much about why the test is failing. We’ll figure out it. The task is complete when you’ve added a link to the web page. And thanks again.
>>>
>>> Julian
>>>
>>>> On Feb 9, 2016, at 11:12 AM, Josh Elser<jo...@gmail.com> wrote:
>>>>
>>>> I'm not sure, actually. The first run passed, I haven't looked closely enough to guess why it fails. Will try to take a look tonight.
>>>>
>>>> For those who don't already have Jenkins accounts, I think Julian (as VP) should have the karma to give you the necessary permission to update/tweak the Jenkins job (or he will have the ability to request such a permission).
>>>>
>>>> Julian Hyde wrote:
>>>>> Fantastic! We’ve needed CI for a long time.
>>>>>
>>>>> I think the only thing left is to link to that site from somewhere on our web site, maybe http://calcite.apache.org/develop/<http://calcite.apache.org/develop/>. I’ve assigned https://issues.apache.org/jira/browse/CALCITE-623 to you. Can you mark it fixed when you’ve added that link. I’m happy to re-publish the web site.
>>>>>
>>>>> Any idea why the JDK 1.7 build is failing? Maybe some interference between tests?
>>>>>
>>>>> Julian
>>>>>
>>>>>
>>>>>> On Feb 8, 2016, at 9:39 PM, Josh Elser<jo...@gmail.com> wrote:
>>>>>>
>>>>>> Better late than never?
>>>>>>
>>>>>> https://builds.apache.org/view/A-D/view/Calcite/
>>>>>>
>>>>>> Here are two jobs that will run hourly (if changes are present), compile, run tests, and build javadocs. As an added perk, if the build was successful, it will deploy the snapshot to the Apache snapshots repository (hooray). We can also have the job send a message to one of our lists on pass/fail. Both jobs are presently configured just to message me for now.
>>>>>>
>>>>>> Let me know what you all think.
>>>>>>
>>>>>> Getting some precommit stuff wired up will be next.
>>>>>>
>>>>>> Josh Elser wrote:
>>>>>>> Ugh, sorry, I've been otherwise swamped and haven't looked into this at
>>>>>>> all.
>>>>>>>
>>>>>>> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>>>>>>> covers the infra post on what they recently providing for
>>>>>>> building/testing pull requests.
>>>>>>>
>>>>>>> In general, we have access to a Jenkins instance which we can configure
>>>>>>> to run builds on commits. We can investigate using Yetus[1] as an entry
>>>>>>> point for automating builds (can also double as an alternative for
>>>>>>> building PR's).
>>>>>>>
>>>>>>> [1] https://yetus.apache.org
>>>>>>>
>>>>>>> Vladimir Sitnikov wrote:
>>>>>>>> Any success with CI?
>>>>>>>>
>>>>>>>> I just came across https://travis-ci.org/apache/jackrabbit-oak, and
>>>>>>>> they somehow managed to enable Travis for an Apache project.
>>>>>>>>
>>>>>>>> I've no idea what opportunities Apache's CI provides, however having
>>>>>>>> some sort (e.g. Travis) of "github PR testing" would be good.
>>>>>>>>
>>>>>>>> Vladimir
>
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
Julian Hyde wrote:
> A*contributor* doesn’t need to run checkstyle every build. But a*committer* has a special role in Apache as a gatekeeper. I think a committer should run checkstyle before every commit to master. I don’t think it is an undue burden to ask a committer to run checkstyle and javadoc on JDK1.8. Those things tend to break fairly often, and it’s a pain to make small fixes and bad practice to force-push.
At risk of de-railing things: this gets even scarier when you start
thinking about release-audit-tool (RAT) checks, and even changes that
affect us in how we apply the ASL to Calcite as well as ASF guidelines
per their by-laws (e.g. do you need to update LICENSE? do you need to
update NOTICE? What about updating L&N in the JARs we build?)
Some days, I think code is the easiest part and can even breath a sigh
of relief when I have some repeatable system I can rely on to run a
contribution through a battery of checks.
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Julian Hyde <jh...@apache.org>.
As you say, it’s a matter of pragmatics what standards we set for what goes into master.
In my opinion, we should check things which are binary. We can’t check non-deterministic tests, and we can’t check for performance. Those will show up over time. We can check for compliance with automated checks.
A *contributor* doesn’t need to run checkstyle every build. But a *committer* has a special role in Apache as a gatekeeper. I think a committer should run checkstyle before every commit to master. I don’t think it is an undue burden to ask a committer to run checkstyle and javadoc on JDK 1.8. Those things tend to break fairly often, and it’s a pain to make small fixes and bad practice to force-push.
For what it’s worth, I run a clean build, checkstyle, javadoc and the full regress using https://github.com/vlsi/calcite-test-dataset <https://github.com/vlsi/calcite-test-dataset>, on both JDK 1.7 and JDK 1.8. I do it in a sandbox that I only use for validating commits, on a server that runs in my home office. But the full regress doesn’t find errors very often, and not every committer has enough memory to run a VM, so I’d make that optional.
Julian
> On Feb 9, 2016, at 1:30 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>> especially considering the benefit to all of having the master branch always at a particular standard.
>
> That is of no discussion.
> You are 100% right here.
>
> However, that statement is a bit sparse.
> What I mean is "a standard" could be to "test javadoc in CI only".
> Or even "skip checkstyle for default builds, and check that is CI".
> That would allow non-styled code to sneak into repository for a short
> time (yet the code is buildable), however it would dramatically reduce
> the build times for everyone => thus more time to write better code
> and tests.
>
>> I said that I would not put an “undue burden” on committers
>
> I do not ignore that. I'm just trying to understand how far are you
> pushing "put more burden" part of the equation.
>
> I do not like this one as it is a bit broad:
> Julian> But I would be inclined to put more burden on the committer
>
>
> Julian> committers need to use whatever tools are that their disposal
>
> If you mean "committers should use CI" here ^^^, that is perfectly fine for me.
>
>
> Julian> If the river is not clean it makes everyone’s life more difficult.
>
> Frankly speaking, I see no problems if "javadoc build" fails from time to time.
> Does "100% quality" indeed matters that much?
> An example how "pre-commit-testing saved the world" would help here to
> change my mind.
> On the other hand, we have recently used --amend to fix some things
> with a great success.
> Thus I treat 99.x% as "good enough".
>
> Just in case: there's a "performance river" (I do remember there's an
> issue I need to look into).
> I'm not sure if we can and/or need to keep it 100% safe (e.g. "no
> commit is allowed to degrade performance for no reason").
>
> Well, instead of discussing things in theory, we could just vote to
> hear from others.
>
> Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Vladimir Sitnikov <si...@gmail.com>.
>especially considering the benefit to all of having the master branch always at a particular standard.
That is of no discussion.
You are 100% right here.
However, that statement is a bit sparse.
What I mean is "a standard" could be to "test javadoc in CI only".
Or even "skip checkstyle for default builds, and check that is CI".
That would allow non-styled code to sneak into repository for a short
time (yet the code is buildable), however it would dramatically reduce
the build times for everyone => thus more time to write better code
and tests.
> I said that I would not put an “undue burden” on committers
I do not ignore that. I'm just trying to understand how far are you
pushing "put more burden" part of the equation.
I do not like this one as it is a bit broad:
Julian> But I would be inclined to put more burden on the committer
Julian> committers need to use whatever tools are that their disposal
If you mean "committers should use CI" here ^^^, that is perfectly fine for me.
Julian> If the river is not clean it makes everyone’s life more difficult.
Frankly speaking, I see no problems if "javadoc build" fails from time to time.
Does "100% quality" indeed matters that much?
An example how "pre-commit-testing saved the world" would help here to
change my mind.
On the other hand, we have recently used --amend to fix some things
with a great success.
Thus I treat 99.x% as "good enough".
Just in case: there's a "performance river" (I do remember there's an
issue I need to look into).
I'm not sure if we can and/or need to keep it 100% safe (e.g. "no
commit is allowed to degrade performance for no reason").
Well, instead of discussing things in theory, we could just vote to
hear from others.
Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Julian Hyde <jh...@apache.org>.
Vladimir,
We’re not going to be able to have a civilized discussion if you don’t read what I write.
I said that I would not put an “undue burden” on committers, and you chose to ignore that.
Let’s consider what is a reasonable burden, especially considering the benefit to all of having the master branch always at a particular standard.
Julian
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Is the water in the river safe to drink?
You need a test for that (== CI).
No tests -- no safety.
Frankly speaking, I would rather go though "send PR, wait CI, then use
that commit" route instead of "mvn test in my dev environment, then
commit".
At the end of the day, my git working copy is never clean.
>But I would be inclined to put more burden
Does that mean you want each committer to manually execute the tests
against all the JDK versions times all the DBs times all the operation
systems times all the hemispheres (as in "timezones")?
Do you expect each committer to track code coverage?
In theory, there is no difference between theory and practice. In
practice, there is.
I would happily accept some "oops" commits (and even --amend / rebase
ones) as I think committers should spend more time on understanding
the logic behind the commit.
Basic things like checkstyle should be offloaded to the machines.
So instead of taking committers words "I've tested that", I would
rather work on improving CI.
In-dev testing extends test matrix (e.g. our CI might miss OSX),
however I would not consider it as a "primary source of truth"
Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Julian Hyde <jh...@apache.org>.
Is the water in the river safe to drink?
Each committer is ensuring that it is safe to drink. We can change the definition of “safe” so we don’t put an undue burden on the committer. But I would be inclined to put more burden on the committer so that each developer knows that the master branch meets a given minimum standard.
I totally agree with you that we need PR testing. That helps developers submitting PRs, and also helps committers. I don’t worry too much that the PR test takes ~20 minutes (including a javadoc build). But until then, committers need to use whatever tools are that their disposal to make sure the water is clean before they put it into the river. If the river is not clean it makes everyone’s life more difficult.
Julian
> On Feb 9, 2016, at 11:52 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>> If there are even checkstyle errors, they should be fixed before the commit.
>
> Of course they should.
> However, I am not sure if it wise to ask "full javadoc build" before
> each commit. It takes enormous time (especially, if jdk sources are
> included to properly inherit javadocs from java.* classes).
>
> I mean:
> 1) Having checkstyle separate shaves time on "test execution".
> 2) Assuming we'll implement PR testing shortly, "checkstyle" job might
> catch non-yet-well-formed PRs
>
> PR-testing is something a bit different from "CI-testing of the main
> brach". I wonder if we need a separate set of jobs for that (e.g. in
> order not to clutter main build history).
>
> What are the opinions here?
>
> For my in-house Jenkins deployment I'm having great fun with a mix of
> Job DSL plugin + Multijob plugin.
> The former allows to script job configuration (in groovy), so I do not
> need to edit jobs manually here and there.
> The latter allows to organize job hierarchy in a series of phases when
> each phase launches a set of concurrent jobs.
> We do not need OOP for current couple of jobs, however it might be
> something to consider.
>
> Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Vladimir Sitnikov <si...@gmail.com>.
> If there are even checkstyle errors, they should be fixed before the commit.
Of course they should.
However, I am not sure if it wise to ask "full javadoc build" before
each commit. It takes enormous time (especially, if jdk sources are
included to properly inherit javadocs from java.* classes).
I mean:
1) Having checkstyle separate shaves time on "test execution".
2) Assuming we'll implement PR testing shortly, "checkstyle" job might
catch non-yet-well-formed PRs
PR-testing is something a bit different from "CI-testing of the main
brach". I wonder if we need a separate set of jobs for that (e.g. in
order not to clutter main build history).
What are the opinions here?
For my in-house Jenkins deployment I'm having great fun with a mix of
Job DSL plugin + Multijob plugin.
The former allows to script job configuration (in groovy), so I do not
need to edit jobs manually here and there.
The latter allows to organize job hierarchy in a series of phases when
each phase launches a set of concurrent jobs.
We do not need OOP for current couple of jobs, however it might be
something to consider.
Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Julian Hyde <jh...@apache.org>.
Yes. I see this build as the basic minimum, so we want it to pass 100% of the time.
By the way, that means that committers should run through this process BEFORE they commit. If there are even checkstyle errors, they should be fixed before the commit.
> On Feb 9, 2016, at 11:36 AM, Josh Elser <jo...@gmail.com> wrote:
>
> Are we good with Jenkins notifications coming to dev@calcite for now?
>
> Julian Hyde wrote:
>> Anyway, don’t worry too much about why the test is failing. We’ll figure out it. The task is complete when you’ve added a link to the web page. And thanks again.
>>
>> Julian
>>
>>> On Feb 9, 2016, at 11:12 AM, Josh Elser<jo...@gmail.com> wrote:
>>>
>>> I'm not sure, actually. The first run passed, I haven't looked closely enough to guess why it fails. Will try to take a look tonight.
>>>
>>> For those who don't already have Jenkins accounts, I think Julian (as VP) should have the karma to give you the necessary permission to update/tweak the Jenkins job (or he will have the ability to request such a permission).
>>>
>>> Julian Hyde wrote:
>>>> Fantastic! We’ve needed CI for a long time.
>>>>
>>>> I think the only thing left is to link to that site from somewhere on our web site, maybe http://calcite.apache.org/develop/<http://calcite.apache.org/develop/>. I’ve assigned https://issues.apache.org/jira/browse/CALCITE-623 to you. Can you mark it fixed when you’ve added that link. I’m happy to re-publish the web site.
>>>>
>>>> Any idea why the JDK 1.7 build is failing? Maybe some interference between tests?
>>>>
>>>> Julian
>>>>
>>>>
>>>>> On Feb 8, 2016, at 9:39 PM, Josh Elser<jo...@gmail.com> wrote:
>>>>>
>>>>> Better late than never?
>>>>>
>>>>> https://builds.apache.org/view/A-D/view/Calcite/
>>>>>
>>>>> Here are two jobs that will run hourly (if changes are present), compile, run tests, and build javadocs. As an added perk, if the build was successful, it will deploy the snapshot to the Apache snapshots repository (hooray). We can also have the job send a message to one of our lists on pass/fail. Both jobs are presently configured just to message me for now.
>>>>>
>>>>> Let me know what you all think.
>>>>>
>>>>> Getting some precommit stuff wired up will be next.
>>>>>
>>>>> Josh Elser wrote:
>>>>>> Ugh, sorry, I've been otherwise swamped and haven't looked into this at
>>>>>> all.
>>>>>>
>>>>>> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>>>>>> covers the infra post on what they recently providing for
>>>>>> building/testing pull requests.
>>>>>>
>>>>>> In general, we have access to a Jenkins instance which we can configure
>>>>>> to run builds on commits. We can investigate using Yetus[1] as an entry
>>>>>> point for automating builds (can also double as an alternative for
>>>>>> building PR's).
>>>>>>
>>>>>> [1] https://yetus.apache.org
>>>>>>
>>>>>> Vladimir Sitnikov wrote:
>>>>>>> Any success with CI?
>>>>>>>
>>>>>>> I just came across https://travis-ci.org/apache/jackrabbit-oak, and
>>>>>>> they somehow managed to enable Travis for an Apache project.
>>>>>>>
>>>>>>> I've no idea what opportunities Apache's CI provides, however having
>>>>>>> some sort (e.g. Travis) of "github PR testing" would be good.
>>>>>>>
>>>>>>> Vladimir
>>>>
>>
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
Are we good with Jenkins notifications coming to dev@calcite for now?
Julian Hyde wrote:
> Anyway, don’t worry too much about why the test is failing. We’ll figure out it. The task is complete when you’ve added a link to the web page. And thanks again.
>
> Julian
>
>> On Feb 9, 2016, at 11:12 AM, Josh Elser<jo...@gmail.com> wrote:
>>
>> I'm not sure, actually. The first run passed, I haven't looked closely enough to guess why it fails. Will try to take a look tonight.
>>
>> For those who don't already have Jenkins accounts, I think Julian (as VP) should have the karma to give you the necessary permission to update/tweak the Jenkins job (or he will have the ability to request such a permission).
>>
>> Julian Hyde wrote:
>>> Fantastic! We’ve needed CI for a long time.
>>>
>>> I think the only thing left is to link to that site from somewhere on our web site, maybe http://calcite.apache.org/develop/<http://calcite.apache.org/develop/>. I’ve assigned https://issues.apache.org/jira/browse/CALCITE-623 to you. Can you mark it fixed when you’ve added that link. I’m happy to re-publish the web site.
>>>
>>> Any idea why the JDK 1.7 build is failing? Maybe some interference between tests?
>>>
>>> Julian
>>>
>>>
>>>> On Feb 8, 2016, at 9:39 PM, Josh Elser<jo...@gmail.com> wrote:
>>>>
>>>> Better late than never?
>>>>
>>>> https://builds.apache.org/view/A-D/view/Calcite/
>>>>
>>>> Here are two jobs that will run hourly (if changes are present), compile, run tests, and build javadocs. As an added perk, if the build was successful, it will deploy the snapshot to the Apache snapshots repository (hooray). We can also have the job send a message to one of our lists on pass/fail. Both jobs are presently configured just to message me for now.
>>>>
>>>> Let me know what you all think.
>>>>
>>>> Getting some precommit stuff wired up will be next.
>>>>
>>>> Josh Elser wrote:
>>>>> Ugh, sorry, I've been otherwise swamped and haven't looked into this at
>>>>> all.
>>>>>
>>>>> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>>>>> covers the infra post on what they recently providing for
>>>>> building/testing pull requests.
>>>>>
>>>>> In general, we have access to a Jenkins instance which we can configure
>>>>> to run builds on commits. We can investigate using Yetus[1] as an entry
>>>>> point for automating builds (can also double as an alternative for
>>>>> building PR's).
>>>>>
>>>>> [1] https://yetus.apache.org
>>>>>
>>>>> Vladimir Sitnikov wrote:
>>>>>> Any success with CI?
>>>>>>
>>>>>> I just came across https://travis-ci.org/apache/jackrabbit-oak, and
>>>>>> they somehow managed to enable Travis for an Apache project.
>>>>>>
>>>>>> I've no idea what opportunities Apache's CI provides, however having
>>>>>> some sort (e.g. Travis) of "github PR testing" would be good.
>>>>>>
>>>>>> Vladimir
>>>
>
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
Vladimir Sitnikov wrote:
>> We can get as fancy as we'd like :)
>
> I suppose job tuning require some grants.
> What is the process to get that?
>
> Vladimir
See my earlier comment, Julian should be the one to assign your Karma.
You either have an account already (from a PMC committership) or you
sign up for one (it's been years since I've done this, so I don't recall :).
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Vladimir Sitnikov <si...@gmail.com>.
>We can get as fancy as we'd like :)
I suppose job tuning require some grants.
What is the process to get that?
Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
Vladimir Sitnikov wrote:
> Cool.
>
> I wonder:
> 1) Can we use Docker? I think that is the easiest way to launch "real
> databases" in there.
> Well, docker management is no way easy, however if you have other
> options, just propose. I do not think it is wise to "install DB from
> scratch for each CI run".
> 2) Are there startup penalties for that? For instance, Travis' Trusty
> images (the new ones with sudo:required& support of docker command)
> take 25+ seconds to startup
I know that the ASF has some infra for Docker, but I am not familiar
with what is available.
> 3) Who configures the set of build jobs? For instance, we might want
> split "checkstyle", "javadoc", etc to a separate job so "bad style"
> does not immediately mark all the jobs red.
We can split up stuff however we'd like. I just looked at what the
.travis.yml did, and used a similar Maven invocation. We can get as
fancy as we'd like :)
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Vladimir Sitnikov <si...@gmail.com>.
Cool.
I wonder:
1) Can we use Docker? I think that is the easiest way to launch "real
databases" in there.
Well, docker management is no way easy, however if you have other
options, just propose. I do not think it is wise to "install DB from
scratch for each CI run".
2) Are there startup penalties for that? For instance, Travis' Trusty
images (the new ones with sudo:required & support of docker command)
take 25+ seconds to startup
3) Who configures the set of build jobs? For instance, we might want
split "checkstyle", "javadoc", etc to a separate job so "bad style"
does not immediately mark all the jobs red.
Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Julian Hyde <jh...@apache.org>.
Anyway, don’t worry too much about why the test is failing. We’ll figure out it. The task is complete when you’ve added a link to the web page. And thanks again.
Julian
> On Feb 9, 2016, at 11:12 AM, Josh Elser <jo...@gmail.com> wrote:
>
> I'm not sure, actually. The first run passed, I haven't looked closely enough to guess why it fails. Will try to take a look tonight.
>
> For those who don't already have Jenkins accounts, I think Julian (as VP) should have the karma to give you the necessary permission to update/tweak the Jenkins job (or he will have the ability to request such a permission).
>
> Julian Hyde wrote:
>> Fantastic! We’ve needed CI for a long time.
>>
>> I think the only thing left is to link to that site from somewhere on our web site, maybe http://calcite.apache.org/develop/<http://calcite.apache.org/develop/>. I’ve assigned https://issues.apache.org/jira/browse/CALCITE-623 to you. Can you mark it fixed when you’ve added that link. I’m happy to re-publish the web site.
>>
>> Any idea why the JDK 1.7 build is failing? Maybe some interference between tests?
>>
>> Julian
>>
>>
>>> On Feb 8, 2016, at 9:39 PM, Josh Elser<jo...@gmail.com> wrote:
>>>
>>> Better late than never?
>>>
>>> https://builds.apache.org/view/A-D/view/Calcite/
>>>
>>> Here are two jobs that will run hourly (if changes are present), compile, run tests, and build javadocs. As an added perk, if the build was successful, it will deploy the snapshot to the Apache snapshots repository (hooray). We can also have the job send a message to one of our lists on pass/fail. Both jobs are presently configured just to message me for now.
>>>
>>> Let me know what you all think.
>>>
>>> Getting some precommit stuff wired up will be next.
>>>
>>> Josh Elser wrote:
>>>> Ugh, sorry, I've been otherwise swamped and haven't looked into this at
>>>> all.
>>>>
>>>> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>>>> covers the infra post on what they recently providing for
>>>> building/testing pull requests.
>>>>
>>>> In general, we have access to a Jenkins instance which we can configure
>>>> to run builds on commits. We can investigate using Yetus[1] as an entry
>>>> point for automating builds (can also double as an alternative for
>>>> building PR's).
>>>>
>>>> [1] https://yetus.apache.org
>>>>
>>>> Vladimir Sitnikov wrote:
>>>>> Any success with CI?
>>>>>
>>>>> I just came across https://travis-ci.org/apache/jackrabbit-oak, and
>>>>> they somehow managed to enable Travis for an Apache project.
>>>>>
>>>>> I've no idea what opportunities Apache's CI provides, however having
>>>>> some sort (e.g. Travis) of "github PR testing" would be good.
>>>>>
>>>>> Vladimir
>>
>>
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
I'm not sure, actually. The first run passed, I haven't looked closely
enough to guess why it fails. Will try to take a look tonight.
For those who don't already have Jenkins accounts, I think Julian (as
VP) should have the karma to give you the necessary permission to
update/tweak the Jenkins job (or he will have the ability to request
such a permission).
Julian Hyde wrote:
> Fantastic! We’ve needed CI for a long time.
>
> I think the only thing left is to link to that site from somewhere on our web site, maybe http://calcite.apache.org/develop/<http://calcite.apache.org/develop/>. I’ve assigned https://issues.apache.org/jira/browse/CALCITE-623 to you. Can you mark it fixed when you’ve added that link. I’m happy to re-publish the web site.
>
> Any idea why the JDK 1.7 build is failing? Maybe some interference between tests?
>
> Julian
>
>
>> On Feb 8, 2016, at 9:39 PM, Josh Elser<jo...@gmail.com> wrote:
>>
>> Better late than never?
>>
>> https://builds.apache.org/view/A-D/view/Calcite/
>>
>> Here are two jobs that will run hourly (if changes are present), compile, run tests, and build javadocs. As an added perk, if the build was successful, it will deploy the snapshot to the Apache snapshots repository (hooray). We can also have the job send a message to one of our lists on pass/fail. Both jobs are presently configured just to message me for now.
>>
>> Let me know what you all think.
>>
>> Getting some precommit stuff wired up will be next.
>>
>> Josh Elser wrote:
>>> Ugh, sorry, I've been otherwise swamped and haven't looked into this at
>>> all.
>>>
>>> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>>> covers the infra post on what they recently providing for
>>> building/testing pull requests.
>>>
>>> In general, we have access to a Jenkins instance which we can configure
>>> to run builds on commits. We can investigate using Yetus[1] as an entry
>>> point for automating builds (can also double as an alternative for
>>> building PR's).
>>>
>>> [1] https://yetus.apache.org
>>>
>>> Vladimir Sitnikov wrote:
>>>> Any success with CI?
>>>>
>>>> I just came across https://travis-ci.org/apache/jackrabbit-oak, and
>>>> they somehow managed to enable Travis for an Apache project.
>>>>
>>>> I've no idea what opportunities Apache's CI provides, however having
>>>> some sort (e.g. Travis) of "github PR testing" would be good.
>>>>
>>>> Vladimir
>
>
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Julian Hyde <jh...@apache.org>.
Fantastic! We’ve needed CI for a long time.
I think the only thing left is to link to that site from somewhere on our web site, maybe http://calcite.apache.org/develop/ <http://calcite.apache.org/develop/>. I’ve assigned https://issues.apache.org/jira/browse/CALCITE-623 to you. Can you mark it fixed when you’ve added that link. I’m happy to re-publish the web site.
Any idea why the JDK 1.7 build is failing? Maybe some interference between tests?
Julian
> On Feb 8, 2016, at 9:39 PM, Josh Elser <jo...@gmail.com> wrote:
>
> Better late than never?
>
> https://builds.apache.org/view/A-D/view/Calcite/
>
> Here are two jobs that will run hourly (if changes are present), compile, run tests, and build javadocs. As an added perk, if the build was successful, it will deploy the snapshot to the Apache snapshots repository (hooray). We can also have the job send a message to one of our lists on pass/fail. Both jobs are presently configured just to message me for now.
>
> Let me know what you all think.
>
> Getting some precommit stuff wired up will be next.
>
> Josh Elser wrote:
>> Ugh, sorry, I've been otherwise swamped and haven't looked into this at
>> all.
>>
>> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>> covers the infra post on what they recently providing for
>> building/testing pull requests.
>>
>> In general, we have access to a Jenkins instance which we can configure
>> to run builds on commits. We can investigate using Yetus[1] as an entry
>> point for automating builds (can also double as an alternative for
>> building PR's).
>>
>> [1] https://yetus.apache.org
>>
>> Vladimir Sitnikov wrote:
>>> Any success with CI?
>>>
>>> I just came across https://travis-ci.org/apache/jackrabbit-oak, and
>>> they somehow managed to enable Travis for an Apache project.
>>>
>>> I've no idea what opportunities Apache's CI provides, however having
>>> some sort (e.g. Travis) of "github PR testing" would be good.
>>>
>>> Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
Better late than never?
https://builds.apache.org/view/A-D/view/Calcite/
Here are two jobs that will run hourly (if changes are present),
compile, run tests, and build javadocs. As an added perk, if the build
was successful, it will deploy the snapshot to the Apache snapshots
repository (hooray). We can also have the job send a message to one of
our lists on pass/fail. Both jobs are presently configured just to
message me for now.
Let me know what you all think.
Getting some precommit stuff wired up will be next.
Josh Elser wrote:
> Ugh, sorry, I've been otherwise swamped and haven't looked into this at
> all.
>
> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
> covers the infra post on what they recently providing for
> building/testing pull requests.
>
> In general, we have access to a Jenkins instance which we can configure
> to run builds on commits. We can investigate using Yetus[1] as an entry
> point for automating builds (can also double as an alternative for
> building PR's).
>
> [1] https://yetus.apache.org
>
> Vladimir Sitnikov wrote:
>> Any success with CI?
>>
>> I just came across https://travis-ci.org/apache/jackrabbit-oak, and
>> they somehow managed to enable Travis for an Apache project.
>>
>> I've no idea what opportunities Apache's CI provides, however having
>> some sort (e.g. Travis) of "github PR testing" would be good.
>>
>> Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
Ugh, sorry, I've been otherwise swamped and haven't looked into this at all.
https://blogs.apache.org/infra/entry/github_pull_request_builds_now
covers the infra post on what they recently providing for
building/testing pull requests.
In general, we have access to a Jenkins instance which we can configure
to run builds on commits. We can investigate using Yetus[1] as an entry
point for automating builds (can also double as an alternative for
building PR's).
[1] https://yetus.apache.org
Vladimir Sitnikov wrote:
> Any success with CI?
>
> I just came across https://travis-ci.org/apache/jackrabbit-oak, and
> they somehow managed to enable Travis for an Apache project.
>
> I've no idea what opportunities Apache's CI provides, however having
> some sort (e.g. Travis) of "github PR testing" would be good.
>
> Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Vladimir Sitnikov <si...@gmail.com>.
Any success with CI?
I just came across https://travis-ci.org/apache/jackrabbit-oak, and
they somehow managed to enable Travis for an Apache project.
I've no idea what opportunities Apache's CI provides, however having
some sort (e.g. Travis) of "github PR testing" would be good.
Vladimir
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Josh Elser <jo...@gmail.com>.
#1 and #4 are easily achieved. We could easily run the failsafe-plugin
runnable ITs, but I'm not sure about automating Vladimir's VM for the
rest of #2.
I'll have to see what Windows support actually exists within the ASF for #3.
Let me see about getting the ball rolling..
Julian Hyde wrote:
> Here are the tasks that I see, at varying levels of ambition.
>
> 1. Most basic would be to have Jenkins running a build and core tests after each commit, just so we’re sure the basics work.
>
> 2. More advanced than that would be to run the integration tests. Those require a running VM set up by Vladimir’s vagrant script https://github.com/vlsi/calcite-test-dataset, and optionally also an Oracle instance. I don’t know whether Apache’s build infrastructure would allow that. I run those tests on my home Linux server, and I send out emails when I see regressions.
>
> 3. We also need to run tests on a Windows machine. I currently do that manually every few weeks, and before each release, but there could be a Jenkins instance running Windows.
>
> 4. It would be helpful to committers if any pull request automatically triggered a Jenkins build.
>
> Julian
>
>
>> On Jan 10, 2016, at 10:10 AM, Josh Elser<jo...@gmail.com> wrote:
>>
>> There are actually a number of options.
>>
>> 1. We can enable some jobs that will build Calcite on commit via Jenkins (https://builds.apache.org).
>>
>> 2. We can enable a PreCommit job which should build every Patch/PullRequest that is attached to JIRA or Github via Apache Yetus (https://yetus.apache.org) and provide some verification that a contribution, from anyone who provides one, compiles, passes tests, passes checkstyle, etc.
>>
>> Both should be pretty trivial to set up (just going through the last steps of getting PreCommit w/ Yetus set up for a different project). Speak up for what everyone would find beneficial.
>>
>> - Josh
>>
>> Vladimir Sitnikov wrote:
>>> By the way, can we have Apache CI instance?
>
Re: Apache-hosted CI (was Re: Build error in master branch)
Posted by Julian Hyde <jh...@apache.org>.
Here are the tasks that I see, at varying levels of ambition.
1. Most basic would be to have Jenkins running a build and core tests after each commit, just so we’re sure the basics work.
2. More advanced than that would be to run the integration tests. Those require a running VM set up by Vladimir’s vagrant script https://github.com/vlsi/calcite-test-dataset, and optionally also an Oracle instance. I don’t know whether Apache’s build infrastructure would allow that. I run those tests on my home Linux server, and I send out emails when I see regressions.
3. We also need to run tests on a Windows machine. I currently do that manually every few weeks, and before each release, but there could be a Jenkins instance running Windows.
4. It would be helpful to committers if any pull request automatically triggered a Jenkins build.
Julian
> On Jan 10, 2016, at 10:10 AM, Josh Elser <jo...@gmail.com> wrote:
>
> There are actually a number of options.
>
> 1. We can enable some jobs that will build Calcite on commit via Jenkins (https://builds.apache.org).
>
> 2. We can enable a PreCommit job which should build every Patch/PullRequest that is attached to JIRA or Github via Apache Yetus (https://yetus.apache.org) and provide some verification that a contribution, from anyone who provides one, compiles, passes tests, passes checkstyle, etc.
>
> Both should be pretty trivial to set up (just going through the last steps of getting PreCommit w/ Yetus set up for a different project). Speak up for what everyone would find beneficial.
>
> - Josh
>
> Vladimir Sitnikov wrote:
>> By the way, can we have Apache CI instance?