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
Initial commit to create @actions/cache package #448
Conversation
7bdca7e
to
509f795
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't have to be in this PR, but we should consider adding some E2E workflow tests for this package, similar to https://github.com/actions/toolkit/blob/master/.github/workflows/artifact-tests.yml and what we have already for https://github.com/actions/cache
509f795
to
f5ca1ba
Compare
b5fa458
to
25662a5
Compare
25662a5
to
1413cd0
Compare
@joshmgross @dhadka @thboop Finally got all tests to pass. PR is ready for review 😄 |
11f82b2
to
b3c8e19
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks really really good 👍 A few minor things
) | ||
} | ||
} else { | ||
core.debug('Unable to validate download, no Content-Length header') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, what are the implications of not properly validating the download? If this is serious then maybe core.warning
should be used?
const response = await retryTypedResponse('getCacheEntry', async () => | ||
httpClient.getJson<ArtifactCacheEntry>(getCacheApiUrl(resource)) | ||
) | ||
if (response.statusCode === 204) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not needed for this PR, but 204 could be added to the HTTP Codes in our http-client
import {createTar, extractTar} from './internal/tar' | ||
import {UploadOptions} from './options' | ||
|
||
export class ValidationError extends Error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a pretty cool pattern! 👍
|
||
const compressionMethod = await utils.getCompressionMethod() | ||
|
||
core.debug('Reserving Cache') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an observation, core.debug
is used pretty frequently, but I think there should be some more uses of core.info
so users see more logs and information.
Most users won't have step-debugging turned on and I've noticed that a lot of our first party actions don't have the greatest output/logging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Package users/Action Authors might not want that verbose logging from a package they consume. I'd say leave as-is and if we get feedback we can add an option to the package to add verbose logging rather than verbose by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine for now, just be aware that once actions/cache
switches over to using this package, the same level of logging will apply (unless there is an option)
Side note: I really like documentation and visuals 🙂 For the artifacts package I added some charts to help make it easier for new users to understand what is going on (and maintainers when they need a refresh in the future). You can see it here: https://github.com/actions/toolkit/blob/master/packages/artifact/docs/implementation-details.md#uploadcompression-flow Absolutely not needed for this PR, but I think it would be pretty nice to have something similar for this package. Even some basic charts about how the decision is made between |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
export async function createTempDirectory(): Promise<string> { | ||
const IS_WINDOWS = process.platform === 'win32' | ||
|
||
let tempDirectory: string = process.env['RUNNER_TEMP'] || '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See below, if tempDIrectory
is empty we create our own temp directory. Note this is an edge case, as RUNNER_TEMP
should always be defined.
|
||
const compressionMethod = await utils.getCompressionMethod() | ||
|
||
core.debug('Reserving Cache') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Package users/Action Authors might not want that verbose logging from a package they consume. I'd say leave as-is and if we get feedback we can add an option to the package to add verbose logging rather than verbose by default
packages/cache/README.md
Outdated
const cacheId = await cache.saveCache(paths, key) | ||
``` | ||
|
||
## Additional Documentation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once actions/cache
starts to consume this package, we can update this doc to point to it as an example implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor thoughts but this PR looks great 🥇
packages/cache/RELEASES.md
Outdated
@@ -0,0 +1,5 @@ | |||
# @actions/cache Releases | |||
|
|||
### 1.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we consider doing a beta release and letting users try it out and provide feedback before we launch 1.0.0?
We can create an issue inviting users to try it out, and iterate on feedback they provide!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any guideline on how to do beta release? Set the release to 0.0.0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With artifacts, we had a 0.1.0
release: https://github.com/actions/toolkit/blob/master/packages/artifact/RELEASES.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other toolkit packages used 1.0.0 as the initial release, I'd prefer if we could do that, but it doesn't make a big difference either way.
Whether or not we want to do a beta release is another discussion.
If you set the version to 1.0.0-beta.0
we can push a beta tag using npm publish --tag beta
. Just make sure whoever is doing the first publish (I can) knows.
Since we are re-using a lot of this code and feel confident about the behavior and interfaces, we can also opt to skip a beta release and just release the package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉🎈 Ship it! 🚀
4dcea16
to
d2b2399
Compare
Initial commit to create @actions/cache package
Initial commit to create the @actions/cache package. ADR is here.
The original code can be found under the cache repo here. Differences between cache actions and the node package are:
Last commit included in this PR is: bac1a40
Addresses:
https://github.com/github/c2c-actions-service/issues/533
actions/cache#55