Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Specify a localRepositoryPath for integration tests. #1451

Merged
merged 0 commits into from
Feb 16, 2023
Merged

Specify a localRepositoryPath for integration tests. #1451

merged 0 commits into from
Feb 16, 2023

Conversation

copybara-service[bot]
Copy link
Contributor

@copybara-service copybara-service bot commented Feb 16, 2023 •
edited
Loading

Specify a localRepositoryPath for integration tests.

The upgrade to version 3.5.0 of maven-invoker-plugin caused this project to fail, with the message here:

Failed to execute goal org.apache.maven.plugins:maven-invoker-plugin:3.5.0:install (integration-test) on project auto-value: Failed to install artifact com.google.auto:auto-common:jar:1.2.1: cannot install /home/runner/.m2/repository/com/google/auto/auto-common/1.2.1/auto-common-1.2.1.jar to same path -> [Help 1]

Setting localRepositoryPath fixes this.

I believe the change in behaviour was caused by this PR, which may have broken other projects similarly. But it has always been recommended to use a non-default localRepositoryPath anyway.

RELNOTES=n/a

@copybara-service copybara-service bot closed this Feb 16, 2023
@copybara-service copybara-service bot merged commit 56764c4 into main Feb 16, 2023
@copybara-service copybara-service bot deleted the test_main_510172220 branch February 16, 2023 18:15
@copybara-service copybara-service bot mentioned this pull request Feb 20, 2023
Closed
copybara-service bot pushed a commit that referenced this pull request Feb 20, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
4918acc 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

RELNOTES=n/a
PiperOrigin-RevId: 510868745
@copybara-service copybara-service bot mentioned this pull request Feb 20, 2023
Closed
copybara-service bot pushed a commit that referenced this pull request Feb 20, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
b1dc313 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 511051082
copybara-service bot pushed a commit that referenced this pull request Feb 20, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
fb411da 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 511051082
copybara-service bot pushed a commit that referenced this pull request Feb 20, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
2a858c5 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 511051082
copybara-service bot pushed a commit that referenced this pull request Feb 20, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
4e122c1 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 511051082
copybara-service bot pushed a commit that referenced this pull request Feb 20, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
01abe95 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 511051082
copybara-service bot pushed a commit that referenced this pull request Feb 21, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
829da22 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 511051082
copybara-service bot pushed a commit that referenced this pull request Feb 21, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
8fb3072 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 510868745
copybara-service bot pushed a commit that referenced this pull request Feb 21, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
2daaaa7 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 511051082
copybara-service bot pushed a commit that referenced this pull request Feb 22, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
969c1a5 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 510868745
copybara-service bot pushed a commit that referenced this pull request Feb 22, 2023
@eamonnmcmanus
Arrange for the Gradle integration test to run in the install phase.
4b55fef 
I am not sure how this test worked before. I think it happened to work as a side effect of other integration tests installing the `HEAD-SNAPSHOT` artifacts, which we stopped doing in #1451. It happens that we noticed the breakage with a Dependabot [PR](#1452) to update `gradle-test-kit`, but I think the CI was already broken.

Anyway, the Gradle test assumes it can depend on the artifacts for the current AutoValue version, and those are only available in the `install` phase.

By following the Maven convention whereby regular unit tests are called `FooTest` and integration tests are called `FooIT`, we get the right tests run in the right phases without having to specify `<include>` and the like.

RELNOTES=n/a
PiperOrigin-RevId: 511489324
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants