Skip to content

Cache expensive Go compilation and linting #3341

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.

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

Merged
merged 1 commit into from
Dec 9, 2019

Conversation

dgageot
Copy link
Contributor

@dgageot dgageot commented Dec 3, 2019

This will significantly reduce "unit tests" and "checks" jobs on TravisCI.

Signed-off-by: David Gageot [email protected]

@codecov
Copy link

codecov bot commented Dec 3, 2019

Codecov Report

Merging #3341 into master will not change coverage.
The diff coverage is n/a.

@tejal29
Copy link
Contributor

tejal29 commented Dec 6, 2019

I dont' like the idea of using cache for unit test running.
In my past team, we have seen some cases for pants test where some ci runs were false positive due to them being not invalidated.

But again, our team wrote pants cache, and developers write bugs :)
How is your confidence in go tests cache ?

I am ok with trying this and then reverting in case we see false positives :)

@dgageot
Copy link
Contributor Author

dgageot commented Dec 7, 2019

@tejal29 On linux, the test cache is disabled (with --count=1). So I thought the risk would only be that a mac/win test could be flaky and we wouldn't detect that.

@dgageot dgageot merged commit 3a40767 into GoogleContainerTools:master Dec 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants