[DISCUSS] Adding LTGM as gating PR checks

2021-12-16 Thread Robert Houghton
We have had LGTM tests enabled on Apache Geode PRs for quite some time, and 
have done a great job of trending those warnings and errors to in the right 
direction. I would like to make the change to our GitHub to make those changes 
blocking for all new PRs, given their reliability and lack-of-flakiness.

Does anyone have strong feelings against that?

-Robert Houghton


Re: [DISCUSS] Adding LTGM as gating PR checks

2021-12-16 Thread Robert Houghton
Excuse me. I meant to link the PR that would enable this behavior: 
https://github.com/apache/geode/pull/7197

-Robert Houghton

From: Robert Houghton 
Date: Thursday, December 16, 2021 at 10:08 AM
To: geode 
Subject: [DISCUSS] Adding LTGM as gating PR checks
We have had LGTM tests enabled on Apache Geode PRs for quite some time, and 
have done a great job of trending those warnings and errors to in the right 
direction. I would like to make the change to our GitHub to make those changes 
blocking for all new PRs, given their reliability and lack-of-flakiness.

Does anyone have strong feelings against that?

-Robert Houghton


Re: [DISCUSS] Adding LTGM as gating PR checks

2021-12-16 Thread Anthony Baker
Thanks Robert, I think this is important. I think this is a good first step. 

In future I think we should consider adding a CI job to ensure that 
pre-existing security errors are addressed. Perhaps GitHub code scanning is 
worth investigating since they have acquired the LGTM product.

Anthony


> On Dec 16, 2021, at 10:08 AM, Robert Houghton  wrote:
> 
> We have had LGTM tests enabled on Apache Geode PRs for quite some time, and 
> have done a great job of trending those warnings and errors to in the right 
> direction. I would like to make the change to our GitHub to make those 
> changes blocking for all new PRs, given their reliability and 
> lack-of-flakiness.
> 
> Does anyone have strong feelings against that?
> 
> -Robert Houghton



Re: [DISCUSS] Adding LTGM as gating PR checks

2021-12-16 Thread Owen Nichols
Requiring LGTM looks good to me.  It does not seem to have a high rate of 
false-positives like some other linters, but if we are making it gating, what 
would the process look like to override a false-positive?

On 12/16/21, 10:37 AM, "Anthony Baker"  wrote:

Thanks Robert, I think this is important. I think this is a good first 
step. 

In future I think we should consider adding a CI job to ensure that 
pre-existing security errors are addressed. Perhaps GitHub code scanning is 
worth investigating since they have acquired the LGTM product.

Anthony


> On Dec 16, 2021, at 10:08 AM, Robert Houghton  
wrote:
> 
> We have had LGTM tests enabled on Apache Geode PRs for quite some time, 
and have done a great job of trending those warnings and errors to in the right 
direction. I would like to make the change to our GitHub to make those changes 
blocking for all new PRs, given their reliability and lack-of-flakiness.
> 
> Does anyone have strong feelings against that?
> 
> -Robert Houghton




[VOTE] - Apache Geode Kafka Connector 1.1.0

2021-12-16 Thread Dan Smith
Hello Geode Dev Community,

This is a release candidate for Apache Geode Kafka Connector version 1.1.0. 
This contains a bump to log4j 2.16.

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Monday, December 20 2021.

Please note that we are voting upon the source tag: rel/v1.1.0


Source and Binary Distributions: 
https://dist.apache.org/repos/dist/dev/geode/kafka-connector-1.1.0/

Github: https://github.com/apache/geode-kafka-connector/tree/rel/v1.1.0

Command to build the connector:
mvn package




Re: [VOTE] - Apache Geode Kafka Connector 1.1.0

2021-12-16 Thread Dan Smith
This is related to the earlier discussion about the kafka connector. This code 
was already linked from the confluent hub, but I want to make sure we're in 
compliance with the apache release policy.

To create this release, I took the source code and binaries Naba mentioned and 
compared them with the rel/1.1.0 source tag and the results of building that 
tag. They were identical except for the build date in the metadata.json file 
for the binary.

I added gpg and sha256sum signatures and uploaded the artifacts to the apache 
staging repo for you all to review.

I checked out the license, notice, and source code headers and everything 
looked ok to me from that perspective.

In the future, we may want to release this in sync with the rest of the geode 
artifacts, but for now I'm just trying to create an official release that 
follows the release policy - https://www.apache.org/legal/release-policy.html.

-Dan

From: Dan Smith 
Sent: Thursday, December 16, 2021 11:25 AM
To: dev@geode.apache.org 
Subject: [VOTE] - Apache Geode Kafka Connector 1.1.0

Hello Geode Dev Community,

This is a release candidate for Apache Geode Kafka Connector version 1.1.0. 
This contains a bump to log4j 2.16.

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Monday, December 20 2021.

Please note that we are voting upon the source tag: rel/v1.1.0


Source and Binary Distributions: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2Fkafka-connector-1.1.0%2F&data=04%7C01%7Cdasmith%40vmware.com%7C4193eea06e6447ac697008d9c0c9e8a4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752795694599729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=A%2Btmhypx13HzF10U%2B5gEo3P%2F2GCdrbm3JC9cZAr8HGY%3D&reserved=0

Github: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Ftree%2Frel%2Fv1.1.0&data=04%7C01%7Cdasmith%40vmware.com%7C4193eea06e6447ac697008d9c0c9e8a4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752795694599729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PdLRRAIh%2FN%2B66PY9jPkdyVrIUI5rSsBPfbHTskwhSVU%3D&reserved=0

Command to build the connector:
mvn package




Errored: apache/geode-examples#659 (master - 7c15c4a)

2021-12-16 Thread Travis CI
Build Update for apache/geode-examples
-

Build: #659
Status: Errored

Duration: 51 secs
Commit: 7c15c4a (master)
Author: Owen Nichols
Message: Replacing master with contents of rel/v1.14.2

View the changeset: 
https://github.com/apache/geode-examples/compare/0e2116f13120...7c15c4a73194

View the full build log and details: 
https://app.travis-ci.com/github/apache/geode-examples/builds/243549647?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://app.travis-ci.com/account/preferences/unsubscribe?repository=16807635&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.


Errored: apache/geode-examples#657 (rel/v1.14.2 - bb8a717)

2021-12-16 Thread Travis CI
Build Update for apache/geode-examples
-

Build: #657
Status: Errored

Duration: 48 secs
Commit: bb8a717 (rel/v1.14.2)
Author: Owen Nichols
Message: Bumping version to 1.14.2

View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.14.2

View the full build log and details: 
https://app.travis-ci.com/github/apache/geode-examples/builds/243549253?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://app.travis-ci.com/account/preferences/unsubscribe?repository=16807635&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.


Errored: apache/geode-examples#655 (rel/v1.13.6 - b760ba6)

2021-12-16 Thread Travis CI
Build Update for apache/geode-examples
-

Build: #655
Status: Errored

Duration: 1 min and 5 secs
Commit: b760ba6 (rel/v1.13.6)
Author: Owen Nichols
Message: Bumping version to 1.13.6

View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.13.6

View the full build log and details: 
https://app.travis-ci.com/github/apache/geode-examples/builds/243548509?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://app.travis-ci.com/account/preferences/unsubscribe?repository=16807635&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.


Re: [DISCUSS] Adding LTGM as gating PR checks

2021-12-16 Thread Robert Houghton
Short answer would be to work with the rest of the community to get the check 
to pass, fix the LGTM configuration, something like that. Otherwise, the 
Concourse CI has the ability to set PR context messages.

-Robert

From: Owen Nichols 
Date: Thursday, December 16, 2021 at 10:40 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding LTGM as gating PR checks
Requiring LGTM looks good to me.  It does not seem to have a high rate of 
false-positives like some other linters, but if we are making it gating, what 
would the process look like to override a false-positive?

On 12/16/21, 10:37 AM, "Anthony Baker"  wrote:

Thanks Robert, I think this is important. I think this is a good first step.

In future I think we should consider adding a CI job to ensure that 
pre-existing security errors are addressed. Perhaps GitHub code scanning is 
worth investigating since they have acquired the LGTM product.

Anthony


> On Dec 16, 2021, at 10:08 AM, Robert Houghton  
wrote:
>
> We have had LGTM tests enabled on Apache Geode PRs for quite some time, 
and have done a great job of trending those warnings and errors to in the right 
direction. I would like to make the change to our GitHub to make those changes 
blocking for all new PRs, given their reliability and lack-of-flakiness.
>
> Does anyone have strong feelings against that?
>
> -Robert Houghton



Re: [DISCUSS] Adding LTGM as gating PR checks

2021-12-16 Thread Alexander Murmann
+1 to adding this. Given it has a low false-positive rate, only checks on code 
actually changed in the PR and runs quickly compared to some of our other steps 
that already happen for every PR, this seems like an easy decision.


From: Robert Houghton 
Sent: Thursday, December 16, 2021 14:20
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding LTGM as gating PR checks

Short answer would be to work with the rest of the community to get the check 
to pass, fix the LGTM configuration, something like that. Otherwise, the 
Concourse CI has the ability to set PR context messages.

-Robert

From: Owen Nichols 
Date: Thursday, December 16, 2021 at 10:40 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding LTGM as gating PR checks
Requiring LGTM looks good to me.  It does not seem to have a high rate of 
false-positives like some other linters, but if we are making it gating, what 
would the process look like to override a false-positive?

On 12/16/21, 10:37 AM, "Anthony Baker"  wrote:

Thanks Robert, I think this is important. I think this is a good first step.

In future I think we should consider adding a CI job to ensure that 
pre-existing security errors are addressed. Perhaps GitHub code scanning is 
worth investigating since they have acquired the LGTM product.

Anthony


> On Dec 16, 2021, at 10:08 AM, Robert Houghton  
wrote:
>
> We have had LGTM tests enabled on Apache Geode PRs for quite some time, 
and have done a great job of trending those warnings and errors to in the right 
direction. I would like to make the change to our GitHub to make those changes 
blocking for all new PRs, given their reliability and lack-of-flakiness.
>
> Does anyone have strong feelings against that?
>
> -Robert Houghton