René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"🚀 [Feature]: Settings‑Driven Workflow","articleBody":"As a maintainer of the PSModule framework, I want all workflow configuration, settings, and conditions to be collected into a single Settings object that is passed through the workflow as one unit.\nEach workflow step should have access to the whole set of settings and additional data, so it can extract the data it needs from this shared context. This makes integrations cleaner, removes scattered configuration logic, and turns Settings into a versatile data store rather than a set of hardcoded checks and variables.\nThis change is internal and structural.\nIt does not alter user behavior, unless a user chooses to inspect or customize the workflow process itself.\n\n### What This Solves\n- Eliminates hardcoded values spread across workflow steps\n- Greatly reduces conditional if: logic\n- Makes workflows easier to reason about, extend, and debug\n- Creates a clear, explicit flow of data through the workflow\n\n### Design Summary\nA single configuration source is loaded at workflow start\nThat configuration becomes a Settings context object\nThe Settings object:\n- Is immutable after load\n- Is passed unchanged between workflow steps\n- Can contain settings, environment data, runtime conditions, and derived values\n\n### Workflow steps:\n\nRead what they need from Settings\nSimplify the interface between the master workflow and its child/internal workflows.\n\n### Expected Outcomes\n\nFewer conditionals and cleaner workflow files\nConfiguration changes require no workflow edits\nNew settings automatically flow through the workflow\nEnvironment differences are handled by data, not logic\n\n### Scope and Constraints\n\nWorks within GitHub Actions\nSupports existing configuration formats (YAML / JSON / PSData)\nAllows gradual migration from current workflows\nMaintains backward compatibility\n\n### Success Criteria\n\nWorkflow logic becomes data‑driven rather than conditional‑driven\nSettings is the single source of truth\nThe workflow reads as a pipeline of steps, not a decision tree.\n\n### Laying the groundwork\n\nFurther down the line we want to make GitHub Actions a way to run the jobs, but ultimately we want to be able to run the scripts in the PSModule framework locally, meaning that we need a way to remove logic from GitHub workflows, and into PowerShell scripts/modules so it can be run locally.","author":{"url":"https://github.com/MariusStorhaug","@type":"Person","name":"MariusStorhaug"},"datePublished":"2025-10-14T11:46:35.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/232/Process-PSModule/issues/232"}