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.

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

Actually use dependency caching in CI #310

Merged
merged 1 commit into from
Jun 15, 2020
Merged

Actually use dependency caching in CI #310

merged 1 commit into from
Jun 15, 2020

Conversation

owais
Copy link
Contributor

@owais owais commented Jun 11, 2020

This commit enables dependency caching in CI. It uses root go.sum file
to detect changes in dependencies but this is a good enough first step.
We can concat go.sum files from all modules and hash that to detect
changes in future if needed.

@owais owais requested review from a team and jrcamp June 11, 2020 16:21
@jrcamp jrcamp self-assigned this Jun 11, 2020
@owais owais added the enhancement New feature or request label Jun 11, 2020
@codecov
Copy link

codecov bot commented Jun 11, 2020

Codecov Report

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

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #310   +/-   ##
=======================================
  Coverage   79.64%   79.64%           
=======================================
  Files         163      163           
  Lines        8338     8338           
=======================================
  Hits         6641     6641           
  Misses       1343     1343           
  Partials      354      354           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9af3381...6e5b26a. Read the comment docs.

@jrcamp
Copy link
Contributor

jrcamp commented Jun 11, 2020

Does go/pkg/mod need to be persisted to workspace? Looks like that step is taking quite a while (1m) but shouldn't go/pkg/mod come from the cache?

lint:
executor: golang
steps:
- attach_to_workspace
- run:
name: Lint
command: CMD="make lint" make -j4 for-all
command: CMD="make lint" make -j16 for-all
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is another thing I noticed. I don't think -j will increase parallelism here because the looping is being done in bash embedded in the make. I think we'd have to change how the make target works for the parallelism to work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for-all:
	@$${CMD}
	@set -e; for dir in $(ALL_MODULES); do \
	  (cd "$${dir}" && \
	  	echo "running $${CMD} in $${dir}" && \
	 	$${CMD} ); \
	done

There's no way for make to parallelize this afaict.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't. Was working on a new target does actually runs everything in parallel. It's in now. I left for-all as is and named it for-all-make since it runs a make target.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it to work but looks like golangci-lint doesn't like to run in parallel 🤦

Static check finished successfully
 
golangci-lint run
 
ERRO Parallel golangci-lint is running            
 
../../Makefile.Common:95: recipe for target 'lint' failed
 
make[1]: *** [lint] Error 3
 
make[1]: Leaving directory '/home/circleci/project/exporter/honeycombexporter'
 
Makefile:67: recipe for target 'for-all-make-./exporter/honeycombexporter' failed
 
make: *** [for-all-make-./exporter/honeycombexporter] Error 2
 
make: *** Waiting for unfinished jobs....
 
ERRO Parallel golangci-lint is running            
 
ERRO Parallel golangci-lint is running            
 
../../Makefile.Common:95: recipe for target 'lint' failed
 
make[1]: *** [lint] Error 3
 
make[1]: Leaving directory '/home/circleci/project/exporter/splunkhecexporter'
 
ERRO Parallel golangci-lint is running 

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upgraded golangci-lint. Fixed now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would for-all-target maybe be more clear what it's for and naming CMD in it TARGET? Just an idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought of that but felt using same var was slightly nicer when browsing CLI history and just changing for-all to for-all-make. But it does indeed look better. Will change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One other option is to make for-all itself support parallelism using xargs:

.PHONY: for-all
PARALLEL?=1
for-all:
	@echo $(ALL_MODULES) | xargs -I% -n1 -P$(PARALLEL) sh -ec "echo 'running $(CMD) in %' ; cd % && $(CMD)"

The native make make one will probably be faster (less forking) but I'd be surprised if it's by much. Having the for-all one support parallel is nice for cases where the CMD isn't a Makefile target. Both probably have their uses. Don't have to add it if you don't need it but I probably will at some point.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually maybe the native one won't be faster since it's still doing an invocation for each subdirectory 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't see much value in changing it. People might be using it in the local dev flow so don't want to cause any annoyances. make based parallel build targets works as expected and integrates with the intuitive -jX flag as well so I think we should keep that separate.

@owais
Copy link
Contributor Author

owais commented Jun 11, 2020

Does go/pkg/mod need to be persisted to workspace? Looks like that step is taking quite a while (1m) but shouldn't go/pkg/mod come from the cache?

It doesn't have to come from the workspace but we have to restore the workspace anyway in these jobs (to get source code and installed binaries). We could not persist deps to workspace and restore cache instead every time but I don't think that would speed things up considerably as downloading deps cache also taking quite a while.

@owais
Copy link
Contributor Author

owais commented Jun 11, 2020

Tested deps as part of workspace vs cache. Cache turned out to be faster (6 minutes vs 8 minutes). I still feel using workspace is probably the more "correct" way to do and it being slow is just a CircleCI implementation detail. They should improve workspace performance at least when running in the same workflow.

Since the difference is significant enough, I'll use cache to restore dependencies in each job for now.

Makefile Outdated
@@ -60,6 +60,13 @@ for-all:
$${CMD} ); \
done

.PHONY: allmodules $(ALL_MODULES)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an allmodules?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Left behind from testing.

.circleci/config.yml Outdated Show resolved Hide resolved
lint:
executor: golang
steps:
- attach_to_workspace
- run:
name: Lint
command: CMD="make lint" make -j4 for-all
command: CMD="make lint" make -j16 for-all
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would for-all-target maybe be more clear what it's for and naming CMD in it TARGET? Just an idea.

@owais owais requested review from jrcamp and dmitryax June 11, 2020 21:28
This commit enables dependency caching in CI. It uses root go.sum file
to detect changes in dependencies but this is a good enough first step.
We can concat go.sum files from all modules and hash that to detect
changes in future if needed.
@owais owais self-assigned this Jun 12, 2020
@jrcamp
Copy link
Contributor

jrcamp commented Jun 15, 2020

@owais lgtm, is this ready for merge?

@owais
Copy link
Contributor Author

owais commented Jun 15, 2020

Yes, it's ready. Thanks for the review.

@tigrannajaryan tigrannajaryan merged commit a304ef1 into open-telemetry:master Jun 15, 2020
@owais owais deleted the cache-deps-in-ci branch June 15, 2020 23:19
wyTrivail referenced this pull request in mxiamxia/opentelemetry-collector-contrib Jul 13, 2020
This commit enables dependency caching in CI. It uses root go.sum file
to detect changes in dependencies but this is a good enough first step.
We can concat go.sum files from all modules and hash that to detect
changes in future if needed.
mxiamxia referenced this pull request in mxiamxia/opentelemetry-collector-contrib Jul 22, 2020
* Refactor extensions to new config format

* Refactored PProf

* Refactor health-check extension

* Refactor service application for extensions

* Refactor zPages and update docker compose example

* Fix staticcheck issue

* Update README and other comments/docs

* Remove tabs from yaml in extension/README.md

* Remove closeFn field from service and related functions

* PR Feedback 00

* Add doc.go to extensiontest package

* Move getAvailablePort to testutils package

* Add tests for testutils functions getting available endpoints
codeboten pushed a commit that referenced this pull request Nov 23, 2022
codeboten pushed a commit that referenced this pull request Nov 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants