GH-37384: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI

[thisisnic]

Rationale for this change

Checks fail on CRAN which don't fail on our CI - we should make them fail on our CI instead of just issue a warning

What changes are included in this PR?

Update settings for R builds so these checks raise error not warning

Are these changes tested?

Nope

Are there any user-facing changes?

No

• Closes: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI  #37384

[thisisnic]

On the initial CI run, we should hopefully get some R failures, as there's a rogue value in our code which this check should catch (I will fix it in another PR and then rebase this one once we've confirmed we successfully caught the failure)

[paleolimbot]

Good catch!

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

[thisisnic]

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

Alas, the problems are ones only visible in my inbox; it's caused us 3 (separate) email notifications from CRAN to say fix it or we'll get booted off! We've already had to do 1 additional release because of this, and have only avoided having to release 13.0.0.1 because of it as we haven't submitted 13.0.0 to CRAN yet, and so I don't want this to happen again.

[thisisnic]

PR isn't ready to merge yet, as the CI needs to be failing before we can say we're happy it's worked...

[thisisnic]

@github-actions crossbow submit test-r-gcc-11

[github-actions]

Revision: 2bfde615783f00aae21c9f143c507dc2b6fc782d

Submitted crossbow builds: ursacomputing/crossbow @ actions-582161a1fb

Task	Status
test-r-gcc-11

[thisisnic]

Hmm, this isn't working. I think the problem is that we're not using r-devel on these builds, and it's a new flag. I've added it to one of the Windows builds which is using r-devel.

[thisisnic]

Now I've got my failing CI job (the Windows one running R devel), I've rebased on main, which I've just pushed a fix for the problematic numeric version to, so now once the CI is green, we can merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit c079dac.

There were 3 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-25 20:07:06Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-02, scale_factor=1
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-03, scale_factor=1
• and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.

[thisisnic]

Rationale for this change

Checks fail on CRAN which don't fail on our CI - we should make them fail on our CI instead of just issue a warning

What changes are included in this PR?

Update settings for R builds so these checks raise error not warning

Are these changes tested?

Nope

Are there any user-facing changes?

No

• Closes: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI  #37384

[thisisnic]

On the initial CI run, we should hopefully get some R failures, as there's a rogue value in our code which this check should catch (I will fix it in another PR and then rebase this one once we've confirmed we successfully caught the failure)

[paleolimbot]

Good catch!

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

[thisisnic]

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

Alas, the problems are ones only visible in my inbox; it's caused us 3 (separate) email notifications from CRAN to say fix it or we'll get booted off! We've already had to do 1 additional release because of this, and have only avoided having to release 13.0.0.1 because of it as we haven't submitted 13.0.0 to CRAN yet, and so I don't want this to happen again.

[thisisnic]

PR isn't ready to merge yet, as the CI needs to be failing before we can say we're happy it's worked...

[thisisnic]

@github-actions crossbow submit test-r-gcc-11

[github-actions]

Revision: 2bfde615783f00aae21c9f143c507dc2b6fc782d

Submitted crossbow builds: ursacomputing/crossbow @ actions-582161a1fb

Task	Status
test-r-gcc-11

[thisisnic]

Hmm, this isn't working. I think the problem is that we're not using r-devel on these builds, and it's a new flag. I've added it to one of the Windows builds which is using r-devel.

[thisisnic]

Now I've got my failing CI job (the Windows one running R devel), I've rebased on main, which I've just pushed a fix for the problematic numeric version to, so now once the CI is green, we can merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit c079dac.

There were 3 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-25 20:07:06Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-02, scale_factor=1
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-03, scale_factor=1
• and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.

[thisisnic]

Rationale for this change

Checks fail on CRAN which don't fail on our CI - we should make them fail on our CI instead of just issue a warning

What changes are included in this PR?

Update settings for R builds so these checks raise error not warning

Are these changes tested?

Nope

Are there any user-facing changes?

No

• Closes: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI  #37384

[thisisnic]

On the initial CI run, we should hopefully get some R failures, as there's a rogue value in our code which this check should catch (I will fix it in another PR and then rebase this one once we've confirmed we successfully caught the failure)

[paleolimbot]

Good catch!

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

[thisisnic]

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

Alas, the problems are ones only visible in my inbox; it's caused us 3 (separate) email notifications from CRAN to say fix it or we'll get booted off! We've already had to do 1 additional release because of this, and have only avoided having to release 13.0.0.1 because of it as we haven't submitted 13.0.0 to CRAN yet, and so I don't want this to happen again.

[thisisnic]

PR isn't ready to merge yet, as the CI needs to be failing before we can say we're happy it's worked...

[thisisnic]

@github-actions crossbow submit test-r-gcc-11

[github-actions]

Revision: 2bfde615783f00aae21c9f143c507dc2b6fc782d

Submitted crossbow builds: ursacomputing/crossbow @ actions-582161a1fb

Task	Status
test-r-gcc-11

[thisisnic]

Hmm, this isn't working. I think the problem is that we're not using r-devel on these builds, and it's a new flag. I've added it to one of the Windows builds which is using r-devel.

[thisisnic]

Now I've got my failing CI job (the Windows one running R devel), I've rebased on main, which I've just pushed a fix for the problematic numeric version to, so now once the CI is green, we can merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit c079dac.

There were 3 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-25 20:07:06Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-02, scale_factor=1
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-03, scale_factor=1
• and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.

[thisisnic]

Rationale for this change

Checks fail on CRAN which don't fail on our CI - we should make them fail on our CI instead of just issue a warning

What changes are included in this PR?

Update settings for R builds so these checks raise error not warning

Are these changes tested?

Nope

Are there any user-facing changes?

No

• Closes: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI  #37384

[thisisnic]

On the initial CI run, we should hopefully get some R failures, as there's a rogue value in our code which this check should catch (I will fix it in another PR and then rebase this one once we've confirmed we successfully caught the failure)

[paleolimbot]

Good catch!

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

[thisisnic]

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

Alas, the problems are ones only visible in my inbox; it's caused us 3 (separate) email notifications from CRAN to say fix it or we'll get booted off! We've already had to do 1 additional release because of this, and have only avoided having to release 13.0.0.1 because of it as we haven't submitted 13.0.0 to CRAN yet, and so I don't want this to happen again.

[thisisnic]

PR isn't ready to merge yet, as the CI needs to be failing before we can say we're happy it's worked...

[thisisnic]

@github-actions crossbow submit test-r-gcc-11

[github-actions]

Revision: 2bfde615783f00aae21c9f143c507dc2b6fc782d

Submitted crossbow builds: ursacomputing/crossbow @ actions-582161a1fb

Task	Status
test-r-gcc-11

[thisisnic]

Hmm, this isn't working. I think the problem is that we're not using r-devel on these builds, and it's a new flag. I've added it to one of the Windows builds which is using r-devel.

[thisisnic]

Now I've got my failing CI job (the Windows one running R devel), I've rebased on main, which I've just pushed a fix for the problematic numeric version to, so now once the CI is green, we can merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit c079dac.

There were 3 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-25 20:07:06Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-02, scale_factor=1
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-03, scale_factor=1
• and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.

[thisisnic]

Rationale for this change

Checks fail on CRAN which don't fail on our CI - we should make them fail on our CI instead of just issue a warning

What changes are included in this PR?

Update settings for R builds so these checks raise error not warning

Are these changes tested?

Nope

Are there any user-facing changes?

No

• Closes: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI  #37384

[thisisnic]

On the initial CI run, we should hopefully get some R failures, as there's a rogue value in our code which this check should catch (I will fix it in another PR and then rebase this one once we've confirmed we successfully caught the failure)

[paleolimbot]

Good catch!

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

[thisisnic]

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

Alas, the problems are ones only visible in my inbox; it's caused us 3 (separate) email notifications from CRAN to say fix it or we'll get booted off! We've already had to do 1 additional release because of this, and have only avoided having to release 13.0.0.1 because of it as we haven't submitted 13.0.0 to CRAN yet, and so I don't want this to happen again.

[thisisnic]

PR isn't ready to merge yet, as the CI needs to be failing before we can say we're happy it's worked...

[thisisnic]

@github-actions crossbow submit test-r-gcc-11

[github-actions]

Revision: 2bfde615783f00aae21c9f143c507dc2b6fc782d

Submitted crossbow builds: ursacomputing/crossbow @ actions-582161a1fb

Task	Status
test-r-gcc-11

[thisisnic]

Hmm, this isn't working. I think the problem is that we're not using r-devel on these builds, and it's a new flag. I've added it to one of the Windows builds which is using r-devel.

[thisisnic]

Now I've got my failing CI job (the Windows one running R devel), I've rebased on main, which I've just pushed a fix for the problematic numeric version to, so now once the CI is green, we can merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit c079dac.

There were 3 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-25 20:07:06Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-02, scale_factor=1
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-03, scale_factor=1
• and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.

[thisisnic]

Rationale for this change

Checks fail on CRAN which don't fail on our CI - we should make them fail on our CI instead of just issue a warning

What changes are included in this PR?

Update settings for R builds so these checks raise error not warning

Are these changes tested?

Nope

Are there any user-facing changes?

No

• Closes: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI  #37384

[thisisnic]

On the initial CI run, we should hopefully get some R failures, as there's a rogue value in our code which this check should catch (I will fix it in another PR and then rebase this one once we've confirmed we successfully caught the failure)

[paleolimbot]

Good catch!

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

[thisisnic]

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

Alas, the problems are ones only visible in my inbox; it's caused us 3 (separate) email notifications from CRAN to say fix it or we'll get booted off! We've already had to do 1 additional release because of this, and have only avoided having to release 13.0.0.1 because of it as we haven't submitted 13.0.0 to CRAN yet, and so I don't want this to happen again.

[thisisnic]

PR isn't ready to merge yet, as the CI needs to be failing before we can say we're happy it's worked...

[thisisnic]

@github-actions crossbow submit test-r-gcc-11

[github-actions]

Revision: 2bfde615783f00aae21c9f143c507dc2b6fc782d

Submitted crossbow builds: ursacomputing/crossbow @ actions-582161a1fb

Task	Status
test-r-gcc-11

[thisisnic]

Hmm, this isn't working. I think the problem is that we're not using r-devel on these builds, and it's a new flag. I've added it to one of the Windows builds which is using r-devel.

[thisisnic]

Now I've got my failing CI job (the Windows one running R devel), I've rebased on main, which I've just pushed a fix for the problematic numeric version to, so now once the CI is green, we can merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit c079dac.

There were 3 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-25 20:07:06Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-02, scale_factor=1
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-03, scale_factor=1
• and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.

[thisisnic]

Rationale for this change

Checks fail on CRAN which don't fail on our CI - we should make them fail on our CI instead of just issue a warning

What changes are included in this PR?

Update settings for R builds so these checks raise error not warning

Are these changes tested?

Nope

Are there any user-facing changes?

No

• Closes: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI  #37384

[thisisnic]

On the initial CI run, we should hopefully get some R failures, as there's a rogue value in our code which this check should catch (I will fix it in another PR and then rebase this one once we've confirmed we successfully caught the failure)

[paleolimbot]

Good catch!

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

[thisisnic]

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

Alas, the problems are ones only visible in my inbox; it's caused us 3 (separate) email notifications from CRAN to say fix it or we'll get booted off! We've already had to do 1 additional release because of this, and have only avoided having to release 13.0.0.1 because of it as we haven't submitted 13.0.0 to CRAN yet, and so I don't want this to happen again.

[thisisnic]

PR isn't ready to merge yet, as the CI needs to be failing before we can say we're happy it's worked...

[thisisnic]

@github-actions crossbow submit test-r-gcc-11

[github-actions]

Revision: 2bfde615783f00aae21c9f143c507dc2b6fc782d

Submitted crossbow builds: ursacomputing/crossbow @ actions-582161a1fb

Task	Status
test-r-gcc-11

[thisisnic]

Hmm, this isn't working. I think the problem is that we're not using r-devel on these builds, and it's a new flag. I've added it to one of the Windows builds which is using r-devel.

[thisisnic]

Now I've got my failing CI job (the Windows one running R devel), I've rebased on main, which I've just pushed a fix for the problematic numeric version to, so now once the CI is green, we can merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit c079dac.

There were 3 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-25 20:07:06Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-02, scale_factor=1
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-03, scale_factor=1
• and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.

[thisisnic]

Rationale for this change

Checks fail on CRAN which don't fail on our CI - we should make them fail on our CI instead of just issue a warning

What changes are included in this PR?

Update settings for R builds so these checks raise error not warning

Are these changes tested?

Nope

Are there any user-facing changes?

No

• Closes: [R] Set _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_ = TRUE on CI  #37384

[thisisnic]

On the initial CI run, we should hopefully get some R failures, as there's a rogue value in our code which this check should catch (I will fix it in another PR and then rebase this one once we've confirmed we successfully caught the failure)

[paleolimbot]

Good catch!

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

[thisisnic]

It's worth noting that the ability to use something other than a string in packageVersion() comparison is rather obscure and, while it's certainly no problem to add this, I'm not personally worried that this particular issue will cause us future problems (unless, of course, there's still one lurking somewhere that we haven't caught yet...).

Alas, the problems are ones only visible in my inbox; it's caused us 3 (separate) email notifications from CRAN to say fix it or we'll get booted off! We've already had to do 1 additional release because of this, and have only avoided having to release 13.0.0.1 because of it as we haven't submitted 13.0.0 to CRAN yet, and so I don't want this to happen again.

[thisisnic]

PR isn't ready to merge yet, as the CI needs to be failing before we can say we're happy it's worked...

[thisisnic]

@github-actions crossbow submit test-r-gcc-11

[github-actions]

Revision: 2bfde615783f00aae21c9f143c507dc2b6fc782d

Submitted crossbow builds: ursacomputing/crossbow @ actions-582161a1fb

Task	Status
test-r-gcc-11

[thisisnic]

Hmm, this isn't working. I think the problem is that we're not using r-devel on these builds, and it's a new flag. I've added it to one of the Windows builds which is using r-devel.

[thisisnic]

Now I've got my failing CI job (the Windows one running R devel), I've rebased on main, which I've just pushed a fix for the problematic numeric version to, so now once the CI is green, we can merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit c079dac.

There were 3 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-25 20:07:06Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-02, scale_factor=1
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-03, scale_factor=1
• and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.