Remove toolcache decorator #1104
Conversation
a10c3a0 to
ae0f195
Compare
eaee63c to
41d6ac4
Compare
This decorator enabled us to use the functionality of the Actions toolcache within the runner too. Now that we've deleted the runner we no longer need it.
9953936 to
b1742f8
Compare
|
Rebased to fix a merge conflict in one of the sourcemap files. |
| @@ -14,8 +14,8 @@ npm run-script build | |||
| # Check that repo is still clean | |||
| if [ ! -z "$(git status --porcelain)" ]; then | |||
| # If we get a fail here then the PR needs attention | |||
| >&2 echo "Failed: JavaScript files are not up to date. Run 'npm run-script build' to update" | |||
| >&2 echo "Failed: JavaScript files are not up to date. Run 'rm -rf lib && npm run-script build' to update" | |||
There was a problem hiding this comment.
minor: We should probably just move rm -rf lib into the npm build script itself.
There was a problem hiding this comment.
Hmm, wouldn't that break incremental compilation though?
There was a problem hiding this comment.
Incremental compilation is done through tsc --watch. At least that's how I run it. tsc --build is always a full build.
There was a problem hiding this comment.
My understanding is tsc --build does some incremental stuff to speed itself up: https://www.typescriptlang.org/docs/handbook/project-references.html#build-mode-for-typescript. It's unfortunate tsc doesn't have support for deleting unneeded js/jsmap files, but I'd rather keep the distinction between a build and a clean build. Personally I chain npm run build into other commands and end up running it fairly frequently, but only delete TypeScript files rarely.
To an extent, yes. All the PR checks that involve the runner continue to work, but the runner can no longer manage its own CodeQL bundle. |
There was a problem hiding this comment.
This would also be a good time to uninstall any unused dependencies.
Are these still being used?
import * as toolrunner from "@actions/exec/lib/toolrunner";
import * as io from "@actions/io";
import * as actionsToolcache from "@actions/tool-cache";
import * as safeWhich from "@chrisgavin/safe-which";
import del from "del";
import * as semver from "semver";
import { v4 as uuidV4 } from "uuid";
If not, then let's remove them from the node_modules. I guess it can be in a future PR, but let's not forget them.
Good idea. I checked and these dependencies are all still being used. |
| const finalHeaders = Object.assign( | ||
| { "User-Agent": "CodeQL Action" }, | ||
| headers | ||
| ); |
There was a problem hiding this comment.
Was this header not being set previously? Is there any reason why you are creating a new object here and not setting "User-Agent" when you initially create the headers object?
eg-
const headers: OutgoingHttpHeaders = {
accept: "application/octet-stream",
"User-Agent": "CodeQL Action"
};There was a problem hiding this comment.
This is just existing code being moved — we can take this as an opportunity to revisit it though. Since this PR has been open for a while, I'll merge without making the change since I'd like to get a confirmation that the toolcache isn't expecting this particular user agent.
This decorator enabled us to use the functionality of the Actions toolcache within the runner too. Now that we no longer release the runner we no longer need it.
Merge / deployment checklist