@ -163,7 +163,7 @@ in different subdirectories. The input supports glob patterns.
If some problem that prevents success caching happens then the action issues the warning in the log and continues the execution of the pipeline.
**Caching in monorepos**
### Caching in monorepos
```yaml
steps:
@ -171,15 +171,131 @@ steps:
- uses: actions/setup-go@v4
with:
go-version: '1.17'
check-latest: true
cache-dependency-path: |
subdir/go.sum
tools/go.sum
# cache-dependency-path: "**/*.sum"
cache-dependency-path: subdir/go.sum
- run: go run hello.go
```
### Caching in multirepos
`cache-dependency-path` input assepts glob patterns and multi-line values:
```yaml
steps:
- uses: actions/checkout@v3
- uses: actions/setup-go@v4
with:
go-version: '1.17'
cache-dependency-path: **/go.sum
- run: go run hello.go
```
```yaml
steps:
- uses: actions/checkout@v3
- uses: actions/setup-go@v4
with:
go-version: '1.17'
cache-dependency-path: |
subdir1/go.sum
subdir2/go.mod
- run: go run hello.go
```
### Multi-target builds
The 'cache-dependency-path' input doesn't limit itself to dependency lock files only. It can also be used with additional files that contain details about the build settings. By using this method, caches for builds created for various operating systems, architectures, etc. can be separated.
```yaml
env:
GOOS: ...
GOARCH: ...
steps:
- run: echo "$GOOS $GOARCH" > /tmp/env
- uses: actions/setup-go@v4
with:
go-version: '1.17'
cache-dependency-path: |
go.sum
/tmp/env
- run: go run hello.go
```
### Invalidate cache when source code changes
Besides the dependencise the action caches the build outputs
([GOCACHE](https://pkg.go.dev/cmd/go#hdr-Build_and_test_caching) directory) but by default this
cache is not update in order to avoid unpredictable and frequent cache invaldation. Nevertheless
including the source code files into `cache-dependency-path` input.
```yaml
- uses: actions/setup-go@v4
with:
go-version: '1.17'
cache-dependency-path: go.sum **/*.go
- run: go run hello.go
```
### Caching with actions/cache
The caching capabilities of setup-go are limited to the simplest and most popular use cases. If fine-grained tuning of caching is required, it's recommended to disable the built-in caching and use [actions/cache](https://github.com/actions/cache).
The example workflow below utilizes the `actions/cache` action and adds flexibility, for instance, it:
- allows to configure cache path
- allows to have different caches for rare changed dependencies and more often changed intermediate build files
- uses the `restore-key` input to restore the previous cache even if the current key cache has changed
- has different caches for the compiler's build outputs for different architectures