Skip to content

Conversation

@godobyte
Copy link
Contributor

@godobyte godobyte commented Nov 5, 2025

What was the problem/requirement? (What/Why)

The Session class needed a new method to run tasks with more granular control over environment variable handling. The existing run_task method always applies all entered environment variables, but there was a requirement to optionally exclude session environment variables while still allowing custom OS environment variables to be passed in.

What was the solution? (How)

Added a new _run_task_without_session_env method to the Session class that provides:

  • The same core functionality as run_task but with different environment variable control
  • Not applying environment variables from session

The implementation follows the same pattern as the existing run_task method but not applying env var from env enter.

What is the impact of this change?

This change provides support for tasks need custom environment variables without session-level environment.

How was this change tested?

See DEVELOPMENT.md for information on running tests.

  • Have you run the unit tests? Yes
  • Added unit tests
    • Same tests as run_task to maintain the same functionality
    • Additional tests for not forwarding session env vars

Was this change documented?

  • Are relevant docstrings in the code base updated? [Yes]

Is this a breaking change?

No

Does this change impact security?

No


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Comment on lines 1142 to 1145
if apply_existing_env:
for identifier in self._environments_entered:
if identifier in self._created_env_vars:
self._created_env_vars[identifier].apply_to_environment(result)
Copy link
Contributor Author

@godobyte godobyte Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, which is hack-y, but can potentially unblock.

Suggested change
if apply_existing_env:
for identifier in self._environments_entered:
if identifier in self._created_env_vars:
self._created_env_vars[identifier].apply_to_environment(result)
if extra_env_vars.get("APPLY_EXISTING_ENV", "true").lower() != "false":
for identifier in self._environments_entered:
if identifier in self._created_env_vars:
self._created_env_vars[identifier].apply_to_environment(result)

Signed-off-by: Godot Bian <13778003+godobyte@users.noreply.github.com>
@godobyte godobyte marked this pull request as ready for review November 6, 2025 00:55
@godobyte godobyte requested a review from a team as a code owner November 6, 2025 00:55
godobyte and others added 2 commits November 5, 2025 16:55
Signed-off-by: Godot Bian <13778003+godobyte@users.noreply.github.com>
@godobyte godobyte changed the title feat: optionally apply existing env from session context for run_task feat: add _run_task_with_optional_session_env function to the Session class Nov 6, 2025
step_script: StepScriptModel,
task_parameter_values: TaskParameterSet,
os_env_vars: Optional[dict[str, str]] = None,
use_session_env_vars: Optional[bool] = True,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Can we not have this variable and always have the code be true?

We don't want anyone else to consume this for any other reason. We want to directly jump to the better API and migrate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, updated in a new commit.

use_session_env_vars: Optional[bool] = True,
log_task_banner: bool = True,
) -> None:
"""Run a Task within the Session.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit - maybe just say private API since it is private and very short lived.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

if use_session_env_vars:
action_env_vars = self._evaluate_current_session_env_vars(os_env_vars)
else:
action_env_vars = dict[str, Optional[str]](self._process_env) # Make a copy
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take away the if-else and always use line 898?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You meant only after L899?

# than after -- run() itself may end up setting the action state to FAILED.
self._runner.run()

def _run_task_with_optional_session_env(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@godobyte godobyte changed the title feat: add _run_task_with_optional_session_env function to the Session class feat: add private _run_task_without_session_env function to the Session class Nov 6, 2025
Signed-off-by: Godot Bian <13778003+godobyte@users.noreply.github.com>
@sonarqubecloud
Copy link

sonarqubecloud bot commented Nov 6, 2025

Quality Gate Failed Quality Gate failed

Failed conditions
40.3% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

@godobyte godobyte changed the title feat: add private _run_task_without_session_env function to the Session class chore: add private _run_task_without_session_env function to the Session class Nov 6, 2025
@godobyte godobyte merged commit bc7ac1a into OpenJobDescription:mainline Nov 6, 2025
57 of 61 checks passed
@godobyte godobyte deleted the exclude_os branch November 6, 2025 03:29
lucaseck added a commit to lucaseck/openjd-sessions-for-python that referenced this pull request Nov 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants