Skip to content

Specify a localRepositoryPath for integration tests.#1451

Merged
copybara-service[bot] merged 0 commit intomainfrom
test_main_510172220
Feb 16, 2023
Merged

Specify a localRepositoryPath for integration tests.#1451
copybara-service[bot] merged 0 commit intomainfrom
test_main_510172220

Conversation

@copybara-service
Copy link
Copy Markdown
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