Skip to content

failOnPassedAfterRetry should not be a part of the cache key #113

Open

Description

@runningcode

Many projects have a different value set for failOnPassedAfterRetry locally vs on CI systems. This will cause a remote cache miss for test tasks.

Since this property causes a test task to fail in more cases and thus not generate a cache entry it would mean that the successful outcomes of the test task are the same, its just a smaller set of cases where a cache entry is created.

Because of this, would it be possible to remove this flag as an input to the task and thus avoid this cache miss?

Activity

  1. bigdaz commented on Jul 22, 2021

    @bigdaz
    Member

    The problem with removing the flag as an input would be the following case:

    • build1 runs with failOnPassedAfterRetry=false. The test task passes after some tests required a retry. Success is written to cache.
    • build2 runs with failOnPassedAfterRetry=true. This task uses the cached output from build1 and the test task passes when it should have failed.

    Consider a hypothetical test that always fails on the first invocation and always passes on retry. The test task on build2 should never pass, but with the proposed change it could pass when the result is taken from the cache.

    The real solution would be to consider a cache entry from build2 to satisfy build1, but not vice versa.

    Something similar could be used for a task that runs a subset of tests: if there's a cache entry where all tests pass, then we could use it to avoid running a subset of tests. But we would never want to do the opposite.

  2. runningcode commented on Jul 23, 2021

    @runningcode
    ContributorAuthor

    That makes sense. For an ideal world we would only want caching in one direction. But in practice, I think the outcomes and successful task executions that are cached are the same. These are flaky tests. We are just caching the result when they're not flaky. This would be same as if the test happend to execute successfully the first time.

    Another thing to consider is that the maxRetries property is not considered an input.

  3. runningcode commented on Sep 29, 2021

    @runningcode
    ContributorAuthor

    For those who experience this miss but one of the two builds has maxRetries set to 0 setting failOnPassedAfterRetry = true on both CI and local builds will have the same effect. That is since there are no retries for local builds the pass / failure behavior is the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions