Skip to content

[RAPTOR-19939] fix(workload): report .env drift on up, and after an update - #882

Draft
wojtekwdr wants to merge 1 commit into
datarobot-oss:mainfrom
wojtekwdr:wojtekw/RAPTOR-19939-env-drift-on-up
Draft

[RAPTOR-19939] fix(workload): report .env drift on up, and after an update#882
wojtekwdr wants to merge 1 commit into
datarobot-oss:mainfrom
wojtekwdr:wojtekw/RAPTOR-19939-env-drift-on-up

Conversation

@wojtekwdr

Copy link
Copy Markdown
Contributor

RATIONALE

dr workload up never read .env unless you passed --import-env or --update-env, so a deploy whose .env had just been edited answered ✓ Already up to date. That is a claim about being in sync, made without looking at the file the reader had just edited, and the only command that would have told them is dr workload config, which nothing on the deploy path points at.

The rule the two flags were built around is not the problem and does not change here: a deploy stays a function of the committed repo. Reading the file to say the two have parted is not deploying from it, and nothing is applied without a flag that asks for it by name.

CHANGES

up reports the drift, through the comparison dr workload config already runs, so the two commands cannot reach different conclusions about the same pair of files. Names only, never values. The remedy is a flag on the command you are already running rather than a trip to another one, and it carries the --dir this run was given, because config looks only where it is pointed while up walks upward for the manifest.

Only what has moved. A credential's value, which nothing can compare; a name the classifier read as local-only, which no flag will ever add; an entry still naming the placeholder; a manifest whose shape no flag can edit, whose refusal counts the whole of .env as missing. None of those can be settled by anything the reader is about to run, so on a deploy each would print on every run for the life of the project, and a line that always prints is one you stop reading along with the drift beside it. dr workload config still says all of it.

--update-env owed a notice it was not giving. It named the variables the manifest does not declare only on the run that found nothing to do, so reconciling every value you could left the file reading as a clean bill of health while a variable it had never carried went on reaching nothing.

Two things fixed on the way, both pulled onto the common path by the above: manifest.DirFlag quotes a project path with a space in it, so the remedy survives being pasted into a shell, and dr workload config --dir <path> carries that --dir into its own remedies.

…pdate

up never read .env unless a flag asked it to, so a deploy whose .env had
just been edited answered "Already up to date" without having looked at
the file. Report what dr workload config already reports, naming the flag
that settles it on the command being run. Nothing is applied: a deploy
stays a function of the committed repo.

Only what has moved. A credential's value, a local-only verdict, a
placeholder and a manifest no flag can edit are true on every run, so on a
deploy they would print forever and take the drift beside them down too.

--update-env also named the variables the manifest does not declare only
on the run that found nothing to do, so reconciling every value you could
left the file reading as a clean bill of health.
@datarobot-pr-review-router

Copy link
Copy Markdown

🎫 Jira: RAPTOR-19939 — [dr wl up] a changed .env is invisible to up: "Already up to date" is printed without reading the file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant