Re: errors from logging code in unit tests
Every "distributed" unit test I've run lately has had it. I just tried ClusterCommunicationsDUnitTest. createEntryAndVerifyUpdate(), for instance, and see these ERRORs in the output. For some reason the test runner ignores these messages and the tests pass. On 2/24/21, 4:07 PM, "Udo Kohlmeyer" wrote: What test(s) are you running? Version? --Udo On 2/25/21, 8:39 AM, "Ernie Burghardt" wrote: Its not just you Bruce, I get this... 2021-02-24 13:38:10,891 main ERROR Error processing element GeodeConsole ([Appenders: null]): CLASS_NOT_FOUND 2021-02-24 13:38:10,898 main ERROR Error processing element GeodeLogWriter ([Appenders: null]): CLASS_NOT_FOUND 2021-02-24 13:38:10,898 main ERROR Error processing element GeodeLogWriter ([Appenders: null]): CLASS_NOT_FOUND 2021-02-24 13:38:10,933 main ERROR Appenders contains an invalid element or attribute "GeodeAlert" 2021-02-24 13:38:10,954 main ERROR Unable to locate appender "STDOUT" for logger config "root" 2021-02-24 13:38:10,954 main ERROR Unable to locate appender "LOGWRITER" for logger config "root" 2021-02-24 13:38:10,955 main ERROR Unable to locate appender "ALERT" for logger config "root" 2021-02-24 13:38:10,956 main ERROR Unable to locate appender "SECURITYLOGWRITER" for logger config "org.apache.geode.security" waiting for views to stabilize sending SerialAckedMessage from m1 to m2 On 2/24/21, 1:30 PM, "Bruce Schuchardt" wrote: This has started showing up in all of my test runs. Is anyone else seeing it? Maybe something in my environment? 2021-02-24 11:19:44,765 main ERROR Error processing element GeodeConsole ([Appenders: null]): CLASS_NOT_FOUND 2021-02-24 11:19:44,778 main ERROR Error processing element GeodeLogWriter ([Appenders: null]): CLASS_NOT_FOUND 2021-02-24 11:19:44,779 main ERROR Error processing element GeodeLogWriter ([Appenders: null]): CLASS_NOT_FOUND 2021-02-24 11:19:44,805 main ERROR Appenders contains an invalid element or attribute "GeodeAlert" 2021-02-24 11:19:44,819 main ERROR Unable to locate appender "STDOUT" for logger config "root" 2021-02-24 11:19:44,820 main ERROR Unable to locate appender "LOGWRITER" for logger config "root" 2021-02-24 11:19:44,820 main ERROR Unable to locate appender "ALERT" for logger config "root" 2021-02-24 11:19:44,820 main ERROR Unable to locate appender "SECURITYLOGWRITER" for logger config "org.apache.geode.security"
Concourse access
Hi everyone, I am trying to access one of the jobs for the geode-native concourse pipeline (I.E: https://concourse.apachegeode-ci.info/builds/7105), but the only thing I can see is a loading message. Do I need any read permissions? If that's the case, this is my GitHub username is 'gaussianrecurrence' BR, Mario
Geode Native Tooling
Hey Geode Native devs, You may have noticed this new CI that looks a lot like the Java CI. PRs will now be executed against this CI and several platforms. All unit and integration tests are executed on all the platforms as well. It also takes over the tasks of the old Travis CI of validating your sources for formatting, license and static analysis for correctness. https://concourse.apachegeode-ci.info/teams/main/pipelines/geode-native-develop The clang-format and clang-tidy tools used by the CI have been upgraded to clang 11. When checking locally please make sure your clang-tidy and clang-format detected by CMake is version 11. There are some slight formatting differences between clang-format 11 and the previous version 6. The new clang-tidy also detects things that version 6 did not detect. Thanks, Jake
Re: Geode Native Tooling
Hi Jacob, No words to describe what a huge effort you put into this. I think it's really going to ease verification work for everyone in the future. However, today I was running one PR on Concourse and I noticed that Windows 2019 job was failing. Could it be that there are some details to polish for that pipeline? BR, Mario. From: Jacob Barrett Sent: Thursday, February 25, 2021 6:04 PM To: dev@geode.apache.org Subject: Geode Native Tooling Hey Geode Native devs, You may have noticed this new CI that looks a lot like the Java CI. PRs will now be executed against this CI and several platforms. All unit and integration tests are executed on all the platforms as well. It also takes over the tasks of the old Travis CI of validating your sources for formatting, license and static analysis for correctness. https://concourse.apachegeode-ci.info/teams/main/pipelines/geode-native-develop The clang-format and clang-tidy tools used by the CI have been upgraded to clang 11. When checking locally please make sure your clang-tidy and clang-format detected by CMake is version 11. There are some slight formatting differences between clang-format 11 and the previous version 6. The new clang-tidy also detects things that version 6 did not detect. Thanks, Jake
Re: code-owners seems to have some problems
Hi Owen, Is there a way to ensure that draft mode PRs aren't requesting reviews from code owners? Thanks, Mark On 2/19/21, 11:44 AM, "Owen Nichols" wrote: GitHub provides some tools to answer this kind of question. Step 1: Under the PR's "Files Changed" tab, click File Filter > Your CODEOWNER files Step 2: Hover over the keyhole/shield icon (to the left of the red/green changecount graphic to the left of each filename) to see who else is also owner. Step 3: If the ownership doesn't seem quite right, click on the keyhole/shield icon to see the exact line in CODEOWNERS that was applied. Please note, if a file has NO codeowner, it will still show up in the "Your CODEOWNER files" (but no keyhole/shield indicator will be displayed). It would be fantastic to find owners for these remaining unowned files, but until then owned-by-no-one == owned-by-everyone. Improvements to CODEOWNERS can always be submitted via PR. Some files in your list below have no owner, but several are owned by someone else so they shouldn't be showing up in your list. Perhaps you copy&pasted this list from the Jump To dropdown? If so, it seems that a File Filter selection does not filter the Jump To dropdown, only the display below. On 2/19/21, 11:30 AM, "Bruce Schuchardt" wrote: I was pulled in to PR 5989 but can’t figure out how that happened with the current CODEOWNERS file. These all seem out of my area: boms/geode-all-bom/src/test/resources/expected-pom.xml buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy extensions/geode-modules-session/build.gradle extensions/geode-modules/build.gradle extensions/geode-modules/src/test/resources/expected-pom.xml extensions/session-testing-war/build.gradle ...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java ...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java ...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java .../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java ...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java geode-assembly/src/integrationTest/resources/assembly_content.txt geode-assembly/src/integrationTest/resources/dependency_classpath.txt .../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java geode-core/build.gradle ...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java
Re: code-owners seems to have some problems
GitHub does not add reviewers from CODEOWNERS to PRs created as draft PRs (until you mark it not-draft by clicking Ready For Review). However if you subsequently change it back to a draft, GitHub will not remove any reviewers. On 2/25/21, 10:28 AM, "Mark Hanson" wrote: Hi Owen, Is there a way to ensure that draft mode PRs aren't requesting reviews from code owners? Thanks, Mark On 2/19/21, 11:44 AM, "Owen Nichols" wrote: GitHub provides some tools to answer this kind of question. Step 1: Under the PR's "Files Changed" tab, click File Filter > Your CODEOWNER files Step 2: Hover over the keyhole/shield icon (to the left of the red/green changecount graphic to the left of each filename) to see who else is also owner. Step 3: If the ownership doesn't seem quite right, click on the keyhole/shield icon to see the exact line in CODEOWNERS that was applied. Please note, if a file has NO codeowner, it will still show up in the "Your CODEOWNER files" (but no keyhole/shield indicator will be displayed). It would be fantastic to find owners for these remaining unowned files, but until then owned-by-no-one == owned-by-everyone. Improvements to CODEOWNERS can always be submitted via PR. Some files in your list below have no owner, but several are owned by someone else so they shouldn't be showing up in your list. Perhaps you copy&pasted this list from the Jump To dropdown? If so, it seems that a File Filter selection does not filter the Jump To dropdown, only the display below. On 2/19/21, 11:30 AM, "Bruce Schuchardt" wrote: I was pulled in to PR 5989 but can’t figure out how that happened with the current CODEOWNERS file. These all seem out of my area: boms/geode-all-bom/src/test/resources/expected-pom.xml buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy extensions/geode-modules-session/build.gradle extensions/geode-modules/build.gradle extensions/geode-modules/src/test/resources/expected-pom.xml extensions/session-testing-war/build.gradle ...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java ...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java ...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java .../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java ...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java geode-assembly/src/integrationTest/resources/assembly_content.txt geode-assembly/src/integrationTest/resources/dependency_classpath.txt .../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java geode-core/build.gradle ...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java
Re: code-owners seems to have some problems
Hi Owen, Two more questions. Is it the case that only one of the code owners for that area has to review the PR? Also, is there a way to tell that a code owner has reviewed an area, so you don't have to as one of the other code owners? Thanks, Mark On 2/25/21, 10:31 AM, "Owen Nichols" wrote: GitHub does not add reviewers from CODEOWNERS to PRs created as draft PRs (until you mark it not-draft by clicking Ready For Review). However if you subsequently change it back to a draft, GitHub will not remove any reviewers. On 2/25/21, 10:28 AM, "Mark Hanson" wrote: Hi Owen, Is there a way to ensure that draft mode PRs aren't requesting reviews from code owners? Thanks, Mark On 2/19/21, 11:44 AM, "Owen Nichols" wrote: GitHub provides some tools to answer this kind of question. Step 1: Under the PR's "Files Changed" tab, click File Filter > Your CODEOWNER files Step 2: Hover over the keyhole/shield icon (to the left of the red/green changecount graphic to the left of each filename) to see who else is also owner. Step 3: If the ownership doesn't seem quite right, click on the keyhole/shield icon to see the exact line in CODEOWNERS that was applied. Please note, if a file has NO codeowner, it will still show up in the "Your CODEOWNER files" (but no keyhole/shield indicator will be displayed). It would be fantastic to find owners for these remaining unowned files, but until then owned-by-no-one == owned-by-everyone. Improvements to CODEOWNERS can always be submitted via PR. Some files in your list below have no owner, but several are owned by someone else so they shouldn't be showing up in your list. Perhaps you copy&pasted this list from the Jump To dropdown? If so, it seems that a File Filter selection does not filter the Jump To dropdown, only the display below. On 2/19/21, 11:30 AM, "Bruce Schuchardt" wrote: I was pulled in to PR 5989 but can’t figure out how that happened with the current CODEOWNERS file. These all seem out of my area: boms/geode-all-bom/src/test/resources/expected-pom.xml buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy extensions/geode-modules-session/build.gradle extensions/geode-modules/build.gradle extensions/geode-modules/src/test/resources/expected-pom.xml extensions/session-testing-war/build.gradle ...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java ...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java ...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java .../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java ...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java geode-assembly/src/integrationTest/resources/assembly_content.txt geode-assembly/src/integrationTest/resources/dependency_classpath.txt .../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java geode-core/build.gradle ...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java
Re: Geode Native Tooling
Aka different versions of clang-format are not compatible in a sense... also, watch out for non-standard clang-format versions that may come with certain IDEs... On 2/25/21, 9:04 AM, "Jacob Barrett" wrote: Hey Geode Native devs, You may have noticed this new CI that looks a lot like the Java CI. PRs will now be executed against this CI and several platforms. All unit and integration tests are executed on all the platforms as well. It also takes over the tasks of the old Travis CI of validating your sources for formatting, license and static analysis for correctness. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fgeode-native-develop&data=04%7C01%7Cburghardte%40vmware.com%7C205541686f0144b8d73b08d8d9af6f7a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637498694801612706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=L1X4YxLX14MVjti%2FIpvMgU%2FS0nWzJ5bN87fsuTN9Q10%3D&reserved=0 The clang-format and clang-tidy tools used by the CI have been upgraded to clang 11. When checking locally please make sure your clang-tidy and clang-format detected by CMake is version 11. There are some slight formatting differences between clang-format 11 and the previous version 6. The new clang-tidy also detects things that version 6 did not detect. Thanks, Jake
Re: Geode Native Tooling
Running the legacy tests on windows is still flaky. Windows! > On Feb 25, 2021, at 9:46 AM, Mario Salazar de Torres > wrote: > > Hi Jacob, > > No words to describe what a huge effort you put into this. I think it's > really going to ease verification work for everyone in the future. > However, today I was running one PR on Concourse and I noticed that Windows > 2019 job was failing. Could it be that there are some details to polish for > that pipeline? > > BR, > Mario. > > From: Jacob Barrett > Sent: Thursday, February 25, 2021 6:04 PM > To: dev@geode.apache.org > Subject: Geode Native Tooling > > Hey Geode Native devs, > > You may have noticed this new CI that looks a lot like the Java CI. PRs will > now be executed against this CI and several platforms. All unit and > integration tests are executed on all the platforms as well. It also takes > over the tasks of the old Travis CI of validating your sources for > formatting, license and static analysis for correctness. > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fgeode-native-develop&data=04%7C01%7Cjabarrett%40vmware.com%7Cac0f398338d7416dfc5808d8d9b55faa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637498720303119021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMHK1Yxe1axWH6wCUHG6y%2F2%2By8t%2Fl6dDFMzBoWkL1Sk%3D&reserved=0 > > The clang-format and clang-tidy tools used by the CI have been upgraded to > clang 11. When checking locally please make sure your clang-tidy and > clang-format detected by CMake is version 11. There are some slight > formatting differences between clang-format 11 and the previous version 6. > The new clang-tidy also detects things that version 6 did not detect. > > > Thanks, > Jake >
RE: Geode Native Tooling
Very good news for the native client. Thanks for the improvement Jacob! BR/ Alberto B. De: Jacob Barrett Enviado: jueves, 25 de febrero de 2021 20:49 Para: dev@geode.apache.org Asunto: Re: Geode Native Tooling Running the legacy tests on windows is still flaky. Windows! > On Feb 25, 2021, at 9:46 AM, Mario Salazar de Torres > wrote: > > Hi Jacob, > > No words to describe what a huge effort you put into this. I think it's > really going to ease verification work for everyone in the future. > However, today I was running one PR on Concourse and I noticed that Windows > 2019 job was failing. Could it be that there are some details to polish for > that pipeline? > > BR, > Mario. > > From: Jacob Barrett > Sent: Thursday, February 25, 2021 6:04 PM > To: dev@geode.apache.org > Subject: Geode Native Tooling > > Hey Geode Native devs, > > You may have noticed this new CI that looks a lot like the Java CI. PRs will > now be executed against this CI and several platforms. All unit and > integration tests are executed on all the platforms as well. It also takes > over the tasks of the old Travis CI of validating your sources for > formatting, license and static analysis for correctness. > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fgeode-native-develop&data=04%7C01%7Cjabarrett%40vmware.com%7Cac0f398338d7416dfc5808d8d9b55faa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637498720303119021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMHK1Yxe1axWH6wCUHG6y%2F2%2By8t%2Fl6dDFMzBoWkL1Sk%3D&reserved=0 > > The clang-format and clang-tidy tools used by the CI have been upgraded to > clang 11. When checking locally please make sure your clang-tidy and > clang-format detected by CMake is version 11. There are some slight > formatting differences between clang-format 11 and the previous version 6. > The new clang-tidy also detects things that version 6 did not detect. > > > Thanks, > Jake >
Re: Concourse access
I made the pipelines public. If you want more access than that let us know. Before that though can you give me a sense for the usability of the public access on the pipelines? Thanks, Jake > On Feb 25, 2021, at 8:31 AM, Mario Salazar de Torres > wrote: > > Hi everyone, > I am trying to access one of the jobs for the geode-native concourse pipeline > (I.E: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fbuilds%2F7105&data=04%7C01%7Cjabarrett%40vmware.com%7Ce185d8a90bbc465b627d08d8d9aac74f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637498674804124104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i3BkZhXIcGAPBlyv0%2BoSCYhCEUzr%2BpLOM4nZj416kYY%3D&reserved=0), > but the only thing I can see is a loading message. Do I need any read > permissions? > If that's the case, this is my GitHub username is 'gaussianrecurrence' > > BR, > Mario
Re: code-owners seems to have some problems
Hi Mark, Yes, each area of ownership only needs one review-by-owner. Your following question, I do not understand, but I'll try: Any PR that needs review, will have text in the "reviewers needed and status-required" area, that states who is still needed to review. However, there is not a direct way to see if a co-owner has already reviewed a file you are looking at. -Robert On 2/25/21, 10:36 AM, "Mark Hanson" wrote: Hi Owen, Two more questions. Is it the case that only one of the code owners for that area has to review the PR? Also, is there a way to tell that a code owner has reviewed an area, so you don't have to as one of the other code owners? Thanks, Mark On 2/25/21, 10:31 AM, "Owen Nichols" wrote: GitHub does not add reviewers from CODEOWNERS to PRs created as draft PRs (until you mark it not-draft by clicking Ready For Review). However if you subsequently change it back to a draft, GitHub will not remove any reviewers. On 2/25/21, 10:28 AM, "Mark Hanson" wrote: Hi Owen, Is there a way to ensure that draft mode PRs aren't requesting reviews from code owners? Thanks, Mark On 2/19/21, 11:44 AM, "Owen Nichols" wrote: GitHub provides some tools to answer this kind of question. Step 1: Under the PR's "Files Changed" tab, click File Filter > Your CODEOWNER files Step 2: Hover over the keyhole/shield icon (to the left of the red/green changecount graphic to the left of each filename) to see who else is also owner. Step 3: If the ownership doesn't seem quite right, click on the keyhole/shield icon to see the exact line in CODEOWNERS that was applied. Please note, if a file has NO codeowner, it will still show up in the "Your CODEOWNER files" (but no keyhole/shield indicator will be displayed). It would be fantastic to find owners for these remaining unowned files, but until then owned-by-no-one == owned-by-everyone. Improvements to CODEOWNERS can always be submitted via PR. Some files in your list below have no owner, but several are owned by someone else so they shouldn't be showing up in your list. Perhaps you copy&pasted this list from the Jump To dropdown? If so, it seems that a File Filter selection does not filter the Jump To dropdown, only the display below. On 2/19/21, 11:30 AM, "Bruce Schuchardt" wrote: I was pulled in to PR 5989 but can’t figure out how that happened with the current CODEOWNERS file. These all seem out of my area: boms/geode-all-bom/src/test/resources/expected-pom.xml buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy extensions/geode-modules-session/build.gradle extensions/geode-modules/build.gradle extensions/geode-modules/src/test/resources/expected-pom.xml extensions/session-testing-war/build.gradle ...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java ...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java ...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java .../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java ...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java geode-assembly/src/integrationTest/resources/assembly_content.txt geode-assembly/src/integrationTest/resources/dependency_classpath.txt .../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java geode-core/build.gradle ...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java
Re: Concourse access
Hi Jacob, In my case, I can see now both geode-native-develop and geode-native-develop-pr set of pipelines, but when I try to see any execution of any of its pipelines I am stuck at the loading message. Interestingly I've noticed that one of the underlying requests sent (https://concourse.apachegeode-ci.info/api/v1/builds/7105/plan) returns 403, so maybe I am missing still some permissions? BR, Mario. From: Jacob Barrett Sent: Thursday, February 25, 2021 9:55 PM To: dev@geode.apache.org Subject: Re: Concourse access I made the pipelines public. If you want more access than that let us know. Before that though can you give me a sense for the usability of the public access on the pipelines? Thanks, Jake > On Feb 25, 2021, at 8:31 AM, Mario Salazar de Torres > wrote: > > Hi everyone, > I am trying to access one of the jobs for the geode-native concourse pipeline > (I.E: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fbuilds%2F7105&data=04%7C01%7Cjabarrett%40vmware.com%7Ce185d8a90bbc465b627d08d8d9aac74f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637498674804124104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i3BkZhXIcGAPBlyv0%2BoSCYhCEUzr%2BpLOM4nZj416kYY%3D&reserved=0), > but the only thing I can see is a loading message. Do I need any read > permissions? > If that's the case, this is my GitHub username is 'gaussianrecurrence' > > BR, > Mario
Re: code-owners seems to have some problems
Hi Robert, Thanks! You answered the question the way I intended. Thanks, Mark On 2/25/21, 12:57 PM, "Robert Houghton" wrote: Hi Mark, Yes, each area of ownership only needs one review-by-owner. Your following question, I do not understand, but I'll try: Any PR that needs review, will have text in the "reviewers needed and status-required" area, that states who is still needed to review. However, there is not a direct way to see if a co-owner has already reviewed a file you are looking at. -Robert On 2/25/21, 10:36 AM, "Mark Hanson" wrote: Hi Owen, Two more questions. Is it the case that only one of the code owners for that area has to review the PR? Also, is there a way to tell that a code owner has reviewed an area, so you don't have to as one of the other code owners? Thanks, Mark On 2/25/21, 10:31 AM, "Owen Nichols" wrote: GitHub does not add reviewers from CODEOWNERS to PRs created as draft PRs (until you mark it not-draft by clicking Ready For Review). However if you subsequently change it back to a draft, GitHub will not remove any reviewers. On 2/25/21, 10:28 AM, "Mark Hanson" wrote: Hi Owen, Is there a way to ensure that draft mode PRs aren't requesting reviews from code owners? Thanks, Mark On 2/19/21, 11:44 AM, "Owen Nichols" wrote: GitHub provides some tools to answer this kind of question. Step 1: Under the PR's "Files Changed" tab, click File Filter > Your CODEOWNER files Step 2: Hover over the keyhole/shield icon (to the left of the red/green changecount graphic to the left of each filename) to see who else is also owner. Step 3: If the ownership doesn't seem quite right, click on the keyhole/shield icon to see the exact line in CODEOWNERS that was applied. Please note, if a file has NO codeowner, it will still show up in the "Your CODEOWNER files" (but no keyhole/shield indicator will be displayed). It would be fantastic to find owners for these remaining unowned files, but until then owned-by-no-one == owned-by-everyone. Improvements to CODEOWNERS can always be submitted via PR. Some files in your list below have no owner, but several are owned by someone else so they shouldn't be showing up in your list. Perhaps you copy&pasted this list from the Jump To dropdown? If so, it seems that a File Filter selection does not filter the Jump To dropdown, only the display below. On 2/19/21, 11:30 AM, "Bruce Schuchardt" wrote: I was pulled in to PR 5989 but can’t figure out how that happened with the current CODEOWNERS file. These all seem out of my area: boms/geode-all-bom/src/test/resources/expected-pom.xml buildSrc/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy extensions/geode-modules-session/build.gradle extensions/geode-modules/build.gradle extensions/geode-modules/src/test/resources/expected-pom.xml extensions/session-testing-war/build.gradle ...embly/geode-assembly-test/src/main/java/org/apache/geode/session/tests/TomcatInstall.java geode-assembly/src/acceptanceTest/java/org/apache/geode/modules/DeployJarAcceptanceTest.java ...butedTest/java/org/apache/geode/management/internal/rest/DeployToMultiGroupDUnitTest.java ...tedTest/java/org/apache/geode/management/internal/rest/DeploymentManagementDUnitTest.java .../java/org/apache/geode/management/internal/rest/DeploymentManagementRedployDUnitTest.java ...java/org/apache/geode/management/internal/rest/DeploymentSemanticVersionJarDUnitTest.java geode-assembly/src/integrationTest/resources/assembly_content.txt geode-assembly/src/integrationTest/resources/dependency_classpath.txt .../java/org/apache/geode/connectors/jdbc/internal/cli/CreateDataSourceCommandDUnitTest.java geode-core/build.gradle ...a/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java geode-core/src/integrationTest/java/org/apache/geode/internal/ClassPathLoaderDeployTest.java
Re: [VOTE] Apache Geode 1.12.1.RC4
It's past the announced deadline and we have enough votes to close the vote. Voting status == +1: 4 binding votes * Dick Cavender (PMC member) * John Blum (PMC member) * Dave Barnes (PMC member) * Robert Houghton (PMC member) * Donal Evans +0: zero votes -0: zero votes -1: zero votes The voting meets the requirements of at least 3 PMC members with +1 votes and has the required majority of +1 votes. Apache Geode 1.12.1.RC4 has passed the vote and we will finalize the release shortly. Thanks everyone for the great work! -Owen Nichols On 2/24/21, 10:34 AM, "Dave Barnes" wrote: +1 Docs. - Geode API docs header correctly updated to 1.12.1 - User guide build scripts generated correct 1.12.1 manual - Native client user guides built correctly - Native client api docs not tested -- they're generated by the full software build, so I assume they're OK. We publish only the latest version (1.13) on the Apache Geode website. On Mon, Feb 22, 2021 at 10:23 AM Robert Houghton wrote: > +1 > > I verified the version.properties file contents to match the pipeline > version that we've tested and verified. > -Robert Houghton > > > On 2/21/21, 12:08 PM, "Owen Nichols" wrote: > > Hello Geode Dev Community, > > This is a release candidate for Apache Geode version 1.12.1.RC4. > Thanks to all the community members for their contributions to this > release! > > Please do a review and give your feedback, including the checks you > performed. > > Voting deadline: > 3PM PST Thu, February 25 2021. > > Please note that we are voting upon the source tag: > rel/v1.12.1.RC4 > > Release notes: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.1&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2Oli0NZ%2FidveHD4sACL%2BB076IKBMC4tWCOXr8u9SYIY%3D&reserved=0 > > Source and binary distributions: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.1.RC4%2F&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Fp%2Bfe74hYiYC5lHwK95%2BVh1eFy9bS6kpP5ijR7yOQ9I%3D&reserved=0 > > Maven staging repo: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1075&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hcHUuLYYyNym7kX1xrc3TV%2BcLIl8LLhFyrM4GgKZMI4%3D&reserved=0 > > GitHub: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.1.RC4&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TtmpXgSKX6lNeun1XJPuMWPXG%2FwfRgxMKWd8ikjDhHA%3D&reserved=0 > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.1.RC4&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848684647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HvHDHpZQpG5%2F3PILgxICazAJXYiu1IeD3qZ1UGQzUsU%3D&reserved=0 > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.1.RC4&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848694605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oV9pdJb5xTavMmYjXgUgqNGSjqc8gPGNv9Pe5ODhyTk%3D&reserved=0 > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.1.RC4&data=04%7C01%7Conichols%40vmware.com%7C8e0202a62f654bae0c9008d8d8f2da3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884848694605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lC2B09NNk7JdslKnW%2BpYILC%2BQSHYARDzGUSwTJ
Passed: apache/geode-examples#527 (rel/v1.12.1 - 75ead25)
Build Update for apache/geode-examples - Build: #527 Status: Passed Duration: 22 mins and 59 secs Commit: 75ead25 (rel/v1.12.1) Author: Owen Nichols Message: Revert "temporarily point to staging repo for CI purposes" View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.12.1 View the full build log and details: https://travis-ci.com/github/apache/geode-examples/builds/218309776?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/geode-examples repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16807635&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://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.
Passed: apache/geode-native#3060 (rel/v1.12.1 - ba8fd9b)
Build Update for apache/geode-native - Build: #3060 Status: Passed Duration: 1 hr, 17 mins, and 34 secs Commit: ba8fd9b (rel/v1.12.1) Author: Owen Nichols Message: Bumping copyright year to 2021 View the changeset: https://github.com/apache/geode-native/compare/rel/v1.12.1 View the full build log and details: https://travis-ci.com/github/apache/geode-native/builds/218309781?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/geode-native repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16807653&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://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.
Broken: apache/geode-native#3062 (support/1.12 - 3e855a8)
Build Update for apache/geode-native - Build: #3062 Status: Broken Duration: 3 mins and 19 secs Commit: 3e855a8 (support/1.12) Author: Owen Nichols Message: Bumping Geode version to 1.12.1 for CI View the changeset: https://github.com/apache/geode-native/compare/22f5b37de679...3e855a83bea5 View the full build log and details: https://travis-ci.com/github/apache/geode-native/builds/218315955?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/geode-native repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16807653&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://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.