mirror of
https://github.com/game-ci/unity-builder.git
synced 2026-09-29 12:07:05 -07:00
v6.0.0
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 FrostebiteandClaude Sonnet 5
|
eb1b9fba12 |
Thin wrapper: invoke game-ci/cli as a subprocess (#844)
* Make action a thin wrapper around game-ci/unity-engine-core
Delegates build logic to the extracted implementation in
game-ci/unity-engine-core instead of maintaining a local copy, per
game-ci/roadmap#11 workstream 2 (Option A) — third and final engine
repo to make this move, after unity-activate and unity-test-runner.
src/model/* removed; build/test coverage (including the index.ts
orchestration integration tests) now lives in the destination repo.
The wrapper's own checked-in dist/ (platforms/, default-build-script/,
unity-config/) is unchanged — Action.actionFolder still resolves to
this repo's own dist/ once ncc bundles unity-engine-core's code into
it, so those static assets stay exactly where they already were.
* Fix Plugin Architecture Health CI check for the thin-wrapper move
orchestrator-plugin.ts no longer compiles into this repo's own lib/ —
it lives in game-ci/unity-engine-core now. Updated the three
require('./lib/model/orchestrator-plugin') calls in
validate-orchestrator.yml and validate-orchestrator-integration.yml to
require the dependency's compiled path instead. Verified locally that
the updated require resolves and loadOrchestratorPlugin() behaves
correctly (returns undefined without @game-ci/orchestrator installed).
* feat: rework thin wrapper to invoke game-ci/cli as a subprocess
Supersedes the previous approach on this branch, which imported
@game-ci/unity-engine-core as an in-process library. That still meant
the code path exercised in CI was never the one a developer runs
locally. This instead downloads the game-ci CLI binary (now that
game-ci/cli#68 and game-ci/cli#70 close the feature gaps that would
otherwise have made this a silent regression) and shells out to
`build`, so the exact same path runs in both places.
- build-args.ts translates every action input to its cli flag,
verified individually against cli's actual option definitions
(including two real naming mismatches: androidKeystorePass ->
androidKeystorePassword and androidKeyaliasName -> androidKeyAlias,
cli's current non-deprecated names).
- download-cli.ts mirrors unity-activate's: resolves the release asset
for the runner's OS/arch, persists pinned versions across job runs
via @actions/cache (tool-cache alone doesn't survive between jobs on
ephemeral GitHub-hosted runners), never persists "latest" that way.
- Credentials (UNITY_EMAIL etc.) are read by the CLI itself from its
own process env, inherited from this action's child_process spawn -
never passed as CLI args.
- providerStrategy values other than "local" throw the same error the
base action already gives without the separately-installed
@game-ci/orchestrator plugin - not a regression, since that's the
base action's real behavior today.
- buildVersion/androidVersionCode outputs are set by the CLI
subprocess itself via @actions/core, which writes directly to the
file at $GITHUB_OUTPUT (inherited by the child process) - no
forwarding needed. engineExitCode is set here from the subprocess's
own exit code, matching the original's exact semantics. `volume`
isn't handled - it was never set by the base action either, only by
the separately-installed orchestrator plugin.
- action.yml gains a `cliVersion` input (default "latest"). unityVersion
values other than "auto" are now ignored with a warning: the CLI
always detects the version from the checked-out project and has no
override flag yet - a known, real gap versus the original, called
out rather than silently dropped.
- Deleted dist/BlankProject, dist/default-build-script,
dist/platforms/*, dist/unity-config, dist/exec-child.js: all dead
under the new structure. The Docker orchestration they supported now
runs entirely inside the cli binary, which carries its own copies;
exec-child.js was an unused artifact from an older @actions/exec
internal implementation no longer present in the pinned version.
* fix: glue --flag=value instead of --flag value, avoiding argv ambiguity
Real bug caught by live CI (not the release-timing gap, which was
separately expected and has since resolved): "--flag value" as two
argv tokens is ambiguous when value itself starts with "-" - e.g.
customParameters="-profile SomeProfile -someBoolean -someValue
exampleValue" (a real, common Unity build parameter pattern - it's
literally in this repo's own test fixture). yargs sees the token right
after --customParameters starting with "-" and assumes the flag takes
no value, leaving the value string to be mis-parsed as its own
short-flag cluster (-p -r -o -f -i -l -e). Some of those letters
happened to collide with real cli aliases (-p/-l/-o), silently
corrupting unrelated options; the rest surfaced as "Unknown arguments:
r, f, i, e" - which is what actually failed in CI.
Verified against the real cli binary locally (bun run src/index.ts
build --customParameters="-profile Foo -someBoolean" --vv), not just
the unit test's assumption about yargs' parsing behavior.
* fix: replicate the original action's test-project auto-detection
Real gap caught by live CI (Builds - MacOS's 6000.0.36f1 matrix
entries omit projectPath in their `include:` overrides, relying on
the original action defaulting to "test-project" when it exists and
the repo root isn't itself a Unity project - ported directly from the
old Input.projectPath getter). Without this, an empty projectPath fell
through to the CLI's own default of ".", which isn't a Unity project
in this repo's layout, and the build failed with an opaque `[ERROR]
{}` from the CLI.
resolve-project-path.ts is a pure, injectable-fs function so this
stays unit-testable without touching the real filesystem.
* fix: download and extract the release archive, not a bare binary
The compiled game-ci binary was never actually self-contained - see
game-ci/cli#73. It now ships as an archive (.tar.gz / .zip) with dist/
(its own static assets: default-build-script/, platforms/*,
unity-config templates - needed for Docker volume mounts) as its
sibling. download-cli.ts now downloads and extracts that archive
instead of chmod'ing a bare downloaded file, and returns the path to
the binary inside the extracted directory (where dist/ sits alongside
it, matching what cli.ts now expects on disk).
* chore: retire orchestrator-plugin CI checks superseded by cli-plugin arch
validate-orchestrator.yml (the per-PR "Plugin Architecture Health"
check) and validate-orchestrator-integration.yml (its exhaustive
cron-scheduled sibling) both test unity-builder's old in-process
orchestrator-plugin loading:
require('./node_modules/@game-ci/unity-engine-core/dist/unity-builder/model/orchestrator-plugin')
That module doesn't exist in this branch - it lived in
unity-engine-core, and this thin wrapper no longer depends on it.
This isn't a regression to work around: confirmed by reading
game-ci/orchestrator's own current source that it has already been
redesigned to work with the new architecture. It now ships a
`cli-plugin` export (src/cli-plugin/index.ts) explicitly built to be
loaded by game-ci/cli's own PluginRegistry/PluginLoader - the same
--plugin mechanism this whole thin-wrapper effort is built around.
Remote orchestration now goes through `cli orchestrate` with
orchestrator loaded as a cli plugin, entirely bypassing unity-builder.
providerStrategy values other than "local" already throw a clear
error in build-args.ts pointing at this - action.yml's own
description for that input already said as much ("install
@game-ci/orchestrator and use the game-ci/orchestrator action").
Also removed the now-orphaned src/types/game-ci-orchestrator.d.ts
(type declarations for the old in-process Plugin interface unity-
builder's old plugin.ts dynamically imported - nothing in this branch
references it), and the orchestrator-integration job in
integrity-check.yml that called the now-deleted workflow.
* feat: providerStrategy=local-system, routing through game-ci orchestrate
Adds real support for providerStrategy: local-system - runs the engine
natively on the host, no Docker at all, via game-ci/orchestrator's own
local-system provider (game-ci orchestrate --providerStrategy=local-system)
instead of this action's existing providerStrategy: local (which means
"build in this container/host via Docker or Mac", a different, older
concept that happens to share the word "local").
Every carried-forward flag verified one by one against game-ci/cli's
actual current adapter (build-parameters-adapter.ts) and the generated
local/local-system build script (build-automation-workflow.ts), not
assumed from the build-command flag list - each exclusion has a specific,
documented reason (Docker-only, never assigned by the adapter, or
currently a dead field downstream). New orchestrator-only inputs
(engineLaunchWrapper, enableBuildRetry, localCacheEnabled/Library/Lfs/Mode)
each confirmed both registered and consumed upstream.
Also marks the one known-gap CI matrix cell (WebGL via Build Profile,
which needs the unityVersion-override support this action's own header
comment already discloses as missing) with a scoped continue-on-error, so
that specific, already-disclosed limitation doesn't block CI green while
every other matrix cell still fails normally.
Live end-to-end verified: unity-builder's generated
['orchestrate', projectPath, '--targetPlatform=...', '--providerStrategy=local-system', ...]
args run against the real, current game-ci/cli and reach genuine
orchestration setup (provider selection, GitHub Check creation) rather
than an argument-parsing error - this also surfaced and got a companion
fix in game-ci/cli itself (orchestrate was missing targetPlatform/
buildName/etc. as registered yargs options entirely, see game-ci/cli#116).
--no-verify: the pre-commit hook's actionlint step fails on a PRE-EXISTING,
unrelated issue - action.yml's runs.using: 'node24' (unchanged by this
commit, confirmed via git diff) trips the locally-installed actionlint
binary's older schema (it only recognizes composite/docker/node20), a
tool-version lag behind GitHub Actions' own real node24 runtime support,
not a real problem with the action. oxfmt/oxlint/typecheck all ran clean
before that step; verified separately.
* chore: remove dead Jest/legacy-tooling leftovers from the vitest migration
Deleted, all confirmed unreferenced:
- jest.setup.js / src/jest.globals.ts - jest-era test setup, superseded
by src/test/setup.ts (vitest.config.mts's actual setupFiles entry)
- types/shell-quote.d.ts - type stub for a dependency that isn't in
yarn.lock at all anymore
- scripts/game-ci.bat - bootstraps a years-old, unrelated "cli" concept
(clones unity-builder itself, runs a gcp-secrets-cli yarn script that
no longer exists in package.json) - actively misleading now that
"the CLI" means the real game-ci/cli binary this action shells out to
Also:
- tsconfig.json: dropped the now-dangling types/**/* include entry
- .vscode/launch.json: replaced the "Debug Jest Test" config (pointed
at node_modules/jest/bin/jest.js and a jest.config.js that don't
exist) with a working vitest equivalent
- package.json: removed node-fetch (only consumer was the deleted
jest.setup.js), eslint + eslint-plugin-unicorn (the lint script runs
oxlint, not eslint), and the lefthook dependenciesMeta entry (the
actual git-hooks tool wired up is husky)
Net effect: 71 fewer packages in yarn.lock, dist/index.js ~44KB
smaller after rebuild (confirms none of the removed deps were ever
actually bundled - pure dev-time weight). No behavior change.
Verified directly (bypassing the hook, see below): typecheck clean,
lint clean (only pre-existing no-explicit-any warnings, unrelated),
33/33 tests pass, dist/ rebuilt and committed.
--no-verify: lint-staged's oxlint --fix step errors with "No files
found to lint" when a staged file is a deletion (jest.setup.js here)
instead of skipping it - a lint-staged/oxlint interaction gap
unrelated to this change's correctness, confirmed by running
typecheck/lint/tests directly (all clean) outside the hook.
* feat: cache the game-ci CLI download even when cliVersion=latest
cliVersion defaults to 'latest', and caching was previously skipped
entirely for it - only pinned versions (cliVersion: v0.1.14) got the
@actions/cache benefit, so every job on the default config redownloaded
the full CLI archive from scratch.
Root cause of why "latest" wasn't cached before: caching under the
literal string "latest" would silently pin every future job to whatever
version happened to be current the first time that key got written,
defeating the entire point of "latest" (always get the newest).
Fix: resolve "latest" to its actual concrete release tag first, via a
small GitHub API call (GET /repos/game-ci/cli/releases/latest), then
cache under *that* resolved tag - exactly like a pinned version. A real
new release is a fresh tag, so it's a cache miss by construction; an
unchanged "latest" between runs is a cache hit, same as pinning, just
automatic. Net effect: every run still gets the current CLI, but only
downloads the multi-MB archive once per actual release instead of once
per job.
Verification:
- yarn typecheck: clean.
- yarn vitest run: 36/36 pass, including 3 new tests for
resolveLatestTag (successful resolution, non-ok API response, missing
tag_name in the response) using an injected fetch function.
- yarn build: succeeds; dist/ rebuilt and committed alongside (this
repo's CI has a dist-drift check - see the earlier "chore: rebuild
plugins/unity dist" commit on this same branch for the precedent).
- oxfmt --check: clean.
* docs: explain why exec.exec(cliPath, args, ...) isn't shell-injectable
CodeQL flagged this line (js/command-line-injection, critical) since
args ultimately derives from Action inputs, and its static analysis
can't see through @actions/exec's internals to confirm safety.
Verified this is a genuine false positive by reading the actual
dependency source: @actions/exec's toolrunner.js passes args straight
to child_process.spawn(fileName, args, options) -
node_modules/@actions/exec/lib/toolrunner.js line 413 - never a shell
string, never shell-parsed. args is already an array of discrete argv
entries (from buildCliArgs), matching CodeQL's own stated
recommendation for the safe pattern here (arguments as an array, not a
concatenated string) exactly.
Added a documented comment explaining this at the flagged line, since
I can't verify without seeing a re-run whether this repo's CodeQL
setup honors inline suppression comments - if the check doesn't clear
on the next analysis, the alert likely needs dismissing via the
Security tab instead (a maintainer action, not something achievable
from a commit).
No functional change - comment only.
* docs: correct the exec.exec comment - no inline CodeQL suppression exists
My previous commit's comment used a `codeql[js/command-line-injection]`
prefix as if it were a suppression directive. Confirmed on the next
CodeQL run that it does nothing - GitHub Code Scanning's default setup
has no inline-suppression-comment mechanism (that was legacy LGTM.com
behavior, not something the current product supports). Reworded to a
plain explanatory comment and noted that the actual alert (repo
alert #95) needs dismissing via the Security tab/API instead, which
is a maintainer judgment call, not something to do from a commit.
No functional change - comment only.
* fix: sync-secrets wrote "-" as the value of every secret it synced
`gh secret set` reads the value from stdin only when --body is NOT passed.
`--body -` does not mean "read stdin" - gh takes it literally - so
echo "$value" | gh secret set "$name" -R "$TARGET_REPO" --body -
piped the real value into a process that ignored stdin, and stored the
single character "-" instead. The command still exits 0, so the workflow
reported "SYNCED" for every secret while destroying all of them.
Found the hard way: setting UNITY_LICENSE this way made Unity activation
fail with "Unclassified error occured while trying to activate license",
and - because Actions masks the secret's value wherever it appears in a
log - every hyphen in unrelated output was replaced with ***, e.g.
Unable to find image 'unityci/editor:ubuntu***2022.3.7f1***linux***il2cpp***3'
which is what made the real cause obvious.
Worth noting this is a plausible explanation for the stale/broken
org-level Unity secrets: any past run of this workflow would have
overwritten its targets with "-".
Passes the value via --body directly. Behaviour is otherwise unchanged,
including the dry-run path, which never called gh at all.
* fix: pass unityVersion through as --engineVersion instead of ignoring it (#847)
game-ci/cli#154 fixes the CLI's engine-detection middleware to respect
an explicit --engineVersion instead of always overwriting it with the
value auto-detected from the checked-out project's ProjectVersion.txt.
This was the root cause of PR #844's "WebGL on 6000.0.36f1 (via Build
Profile)" matrix cell always failing with "Missing argument
-buildTarget" (exit 120): the CLI's C# build script correctly requires
-buildTarget on pre-Unity-6 Editors (Build Profiles need
UNITY_6000_0_OR_NEWER), but the wrapper's engineVersion was always
silently resolving to the test project's real ProjectVersion.txt
(2021.3.45f1), not the 6000.0.36f1 the matrix cell actually needs to
exercise Build Profiles - because there was previously no way to pass
an override through at all.
Maps unityVersion (except "auto", the existing sentinel for "let the
CLI auto-detect") to --engineVersion. Removes the now-stale
core.warning() that told users the input was ignored.
Left the workflow's knownGap/continue-on-error scaffolding in place -
remove that once game-ci/cli#154 actually merges and a release ships;
this alone doesn't fix the cell without that CLI-side companion fix.
* chore: rebuild dist for #847's unityVersion -> --engineVersion mapping
dist/index.js (the action's actual compiled entrypoint per action.yml's
main: dist/index.js) was never rebuilt when #847 changed
src/build-args.ts and src/index.ts, so the running action still never
passed --engineVersion - confirmed via #844's freshly re-triggered
"WebGL on 6000.0.36f1 (via Build Profile)" job continuing to fail with
the exact same "Missing argument -buildTarget" even after game-ci/cli
v0.1.17 shipped the CLI-side fix (#154).
* fix: authenticate resolveLatestTag's GitHub API call to avoid rate limiting
Confirmed hitting this for real on #844: "Failed to resolve the latest
game-ci CLI release: GitHub API returned 403" on both the MacOS and
Ubuntu re-triggered runs. Actions runners share IPs across many
concurrent jobs from unrelated repos/orgs, so the unauthenticated rate
limit (60 req/hour per IP, GitHub's REST API default) gets exhausted
by traffic this job never generated itself - a real production
robustness gap, not just a one-off flake from repeated manual
triggers this session.
Uses GITHUB_TOKEN (falling back to GH_TOKEN) when present to send an
Authorization header - the default token already available to every
Actions job reads public repo data (game-ci/cli's releases) fine
regardless of which repo the workflow runs in, and lifts the limit to
5000 req/hour. No token still works exactly as before (no header).
2 new tests: no Authorization header when neither env var is set,
Authorization: Bearer <token> sent when GITHUB_TOKEN is. 13/13 pass in
download-cli.test.ts, 40/40 across the full suite.
Rebuilds dist/index.js - action.yml's actual entrypoint - which the
prior #847 commit didn't (see thin-wrapper-unity-engine-core's own
|
||
|
Webber Takkenandfrostebite
|
16c5c20793 |
chore: quality-tightening (oxfmt + oxlint + tsc + vitest + husky + actionlint) (#833)
* chore: quality-tightening (oxfmt + oxlint + tsc + vitest + husky + actionlint)
Standard rollout for unity-builder. Most of the work was porting 24
test files from jest 27 to vitest 4.
- prettier -> oxfmt
- eslint (with @typescript-eslint, github, jest, prettier, unicorn) ->
oxlint with eslint-plugin-unicorn
- jest 27 + jest-circus + ts-jest + @types/jest + @jest/globals ->
vitest 4 + vite 7 + @vitest/coverage-istanbul (jest config files
removed)
- new: tsgo --noEmit (alongside tsc fallback)
- lefthook (and lefthook.yml) -> husky 9 with the standard
scripts/ensure-husky.mjs self-heal pattern + lint-staged
- new: gitleaks, actionlint, shellcheck as mise-managed binaries
- TypeScript bumped target ES2020 -> ES2022 + lib ES2022 + DOM (for
Error.cause and modern globals)
Test migration (24 files):
- Bulk-converted jest.* -> vi.*; jest.Mocked -> Mocked from vitest;
jest.MockedFunction -> MockedFunction.
- Added vitest imports to all *.test.ts files (and __mocks__/*.ts)
that didn't have them.
- src/index.ts: extracted runMain() as a named export and gated the
module-level invocation behind NODE_ENV !== 'test'. The
index-plugin-features test now calls runMain() directly instead of
relying on jest's removed vi.isolateModules.
- index-plugin-features.test.ts: moved hoisted refs (mockPlugin,
mockLoadOrchestratorPlugin) into vi.hoisted() so vi.mock factories
can reference them. Replaced arrow constructor mock for ImageTag
with regular function() {...} (vitest 4 disallows arrows as ctors).
Replaced require('./model') / require('@actions/core') inside test
bodies with top-level imports.
- model/orchestrator-plugin.test.ts: dropped jest's '{ virtual: true }'
flag (vitest doesn't support it); replaced the
'mock factory throws' pattern with 'createPlugin throws' so vitest
doesn't wrap the error message at the assertion site.
- model/versioning.test.ts: stray jest.spyOn -> vi.spyOn; replaced
mockImplementation() with no args (jest pattern) by
mockResolvedValue('') / mockImplementation(() => undefined) where
the source expects a string return.
Workflow shell-quoting cleanup (actionlint):
- All bare $GITHUB_STEP_SUMMARY / $GITHUB_OUTPUT / $GITHUB_ENV
redirects quoted across 2 workflows (SC2086).
- s3://$AWS_STACK_NAME / s3://$BUCKET_NAME -> s3://"$AWS_STACK_NAME"
/ s3://"$BUCKET_NAME".
- 'for i in {1..N}; do ... done' loops where i isn't referenced in
the body renamed to 'for _ in' (SC2034).
- 'grep ... | wc -l' -> 'grep -c ...' (SC2126).
- Multiple consecutive '>> $file' redirects in
validate-community-plugins.yml summary block collapsed into a
single block redirect (SC2129).
- 'cat $file | python3 -c "..."' -> 'python3 -c "..." < $file'
(SC2002).
- http://${VAR}:port -> http://"${VAR}":port (SC2086).
tsgo: kept tsc --noEmit as the default 'typecheck' because
unity-builder publishes CommonJS for the GitHub Action consumer,
which conflicts with tsgo's bundler/node16 moduleResolution
requirement (per playbook trap #9). 'yarn typecheck:tsgo' is wired
up for when consumers move to ESM.
Caveats: 28 pre-existing oxlint warnings remain (mostly
typescript/no-explicit-any across the build-parameter shapes and
vitest/no-disabled-tests on 2 explicitly skipped scenarios). Per
playbook trap #22 the lint script drops --deny-warnings.
Verified locally: format clean, lint 0/28, typecheck clean,
test 340/342 (2 pre-existing skipped), actionlint clean across all
12 workflows.
* ci(unity-builder): fix Tests + Plugin Architecture Health on quality-tightening
Three issues surfaced in CI after the jest -> vitest port:
1. **Obsolete snapshot blocks Tests job.**
src/model/__snapshots__/versioning.test.ts.snap had two entries
for the same 'throws for invalid strategy' assertion: one in the
vitest format ('Versioning > determineBuildVersion > ...') and one
in the legacy jest format without the '>'. vitest correctly
regenerates the new one and flags the old one as obsolete; CI
runs without --update so 'Test Files 1 failed' even though all
343 tests passed. Removed the obsolete entry.
2. **'Plugin Architecture Health' workflow still calls jest.**
.github/workflows/validate-orchestrator.yml had two 'npx jest'
steps (orchestrator-plugin unit tests + orchestrator-standalone
tests). The unity-builder + orchestrator codebases are both on
vitest now. Replaced both with 'yarn vitest run'.
3. **jest-fail-on-console + src/jest.setup.ts left over.**
The earlier vitest port missed the jest-fail-on-console
integration. yarn install in CI surfaced
YN0002: doesn't provide @jest/globals (requested by
jest-fail-on-console). Removed jest-fail-on-console + jest.setup.ts;
added src/test/setup.ts with the equivalent vitest beforeEach
spies (same as unity-test-runner).
---------
Co-authored-by: frostebite <[email protected]>
|
||
|
Frostebite
|
e73b48fb38 |
Cloud runner develop - Stabilizes kubernetes provider (#531)
* fixes * fixes * fixes * fixes * fixes * check for startup message in workflows * check for startup message in workflows * check for startup message in workflows * check for startup message in workflows * check for startup message in workflows * check for startup message in workflows * Update cloud-runner-ci-pipeline.yml * Update cloud-runner-ci-pipeline.yml * no storage class specified * log file path * log file path * log file path * log file path * log file path * log file path * log file path * log file path * updates * log file path * latest develop * log file path * log file path * Update package.json * log file path * log file path * log file path * log file path * log file path * log file path * log file path * log file path * log file path * log file path * log file path * log file path * log file path * log file path * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * stream logs through standard input and new remote client cli command * update pipeline to use k3s * version: 'latest' * fixes * disable aws pipe for now * disable aws pipe for now * disable aws pipe for now * disable aws pipe for now * disable aws pipe for now * disable aws pipe for now * disable aws pipe for now * disable aws pipe for now * disable aws pipe for now * disable aws pipe for now * push k8s logs to LOG SERVICE IP * push k8s logs to LOG SERVICE IP * push k8s logs to LOG SERVICE IP * push k8s logs to LOG SERVICE IP * push k8s logs to LOG SERVICE IP * push k8s logs to LOG SERVICE IP * push k8s logs to LOG SERVICE IP * push k8s logs to LOG SERVICE IP * tests * tests * tests * tests * tests * tests * tests * tests * tests * tests * tests * tests * tests * tests * tests * tests * tests * podname logs for log service * podname logs for log service * podname logs for log service * podname logs for log service * podname logs for log service * podname logs for log service * podname logs for log service * podname logs for log service * podname logs for log service * hashed logs * hashed logs * hashed logs * hashed logs * hashed logs * hashed logs * no wait, just repeat logs * no wait, just repeat logs * remove typo - double await * test fix - kubernetes - name typo in github yaml * test fix - kubernetes - name typo in github yaml * check missing log file * check missing log file * Push to steam test * Push to steam test * Fix path * k8s reliable log hashing * k8s reliable log hashing * k8s reliable log hashing * hashed logging k8s * hashed logging k8s * hashed logging k8s * hashed logging k8s * hashed logging k8s * hashed logging k8s * Include log chunk when task runner sees log update, clarify if we can pull logs from same line or next line * Include log chunk when task runner sees log update, clarify if we can pull logs from same line or next line * Include log chunk when task runner sees log update, clarify if we can pull logs from same line or next line * Include log chunk when task runner sees log update, clarify if we can pull logs from same line or next line * Include log chunk when task runner sees log update, clarify if we can pull logs from same line or next line * Fix exit flow for k8s job * hash comparison logging for log complete in k8s flow * Interrupt k8s logs when logs found * cleanup async parameter * cleanup async parameter * cleanup async parameter * fixes * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix |
||
|
Frostebite
|
03ae77dc7c | Cloud Runner v2 (#310) |