Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: publish files for discussion #24

Draft
wants to merge 1 commit into
base: trunk
Choose a base branch
from

Conversation

reimic
Copy link
Collaborator

@reimic reimic commented Feb 22, 2024

🚧 Work in progress 🚧

uploaded for ease of discussion only, even if parts of this will become the basis for changes to the codebase it will be done in a separate PR

Issues to discuss:

  • runner validation policy, precision of exceptions, (kinda blocks adding tests !)
  • role of resource / file / context / runtime managers,
  • testing and documentation.

@reimic
Copy link
Collaborator Author

reimic commented Feb 22, 2024

runner validation policy

After the JSON was properly validated and parsed, the resource needs have been collected, the steps are run. So:

We have been discussing this on slack for a while now, pr #18 reflected that with a more offensive approach to exceptions. But while approaching other steps I begun to wonder:

  1. to what extent would you want things offensively breaking execution?
  2. how precise should the feedback be?
  3. how should the continue on error option actually benefit the end-user?
    a. not to cause a cascade of issues and obfuscate the root cause?
    b. which steps would actually benefit from this feature?
    c. this implies blueprints are a sort of execution tree - would there be a benefit to declaring it overtly?
  4. for a failing blueprint:
    a. what is the expected state?
    b. should all changes be reverted?
    c. if not should all procured resources be discarded?
    d. if not - how should steps know a step was run and did not fail?

As an idea:
I was wondering about the utility a blueprint running mode that fails fast when a particular step fails but instead of failing the whole blueprint, returns control to the user for troubleshooting (this could prove useful for blueprint designers), and after corrections - continues from the last point of failure. To get a mental image think - blueprint wizard. This could yield a running installation and a final, successful blueprint.

@@ -7,6 +7,7 @@

class DownloadWordPressStepRunner extends InstallAssetStepRunner {

//TODO why is this download and not install?
Copy link
Collaborator

@adamziel adamziel Feb 23, 2024

Choose a reason for hiding this comment

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

Installation is a separate step. The developer may not want to run the installation wizard automatically.

@@ -10,6 +10,8 @@


class InstallAssetStepRunner extends BaseStepRunner {
// TODO following the github API - this is not an exposed step - maybe it's internals should be used by other steps and not extended?
Copy link
Collaborator

Choose a reason for hiding this comment

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

I had the same thought, just couldn't think of the right names for things.

}
function run(MkdirStep $input) {
$path = $input->path;
$this->fileManager->assertNoFileExists($path);
Copy link
Collaborator

Choose a reason for hiding this comment

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

This line obscures that $path is relative to the document root and needs to be resolved.

@adamziel
Copy link
Collaborator

  1. to what extent would you want things offensively breaking execution?

As a rule of thumb, steps are atomic commands that should always fail when they can't accomplish the task. It's up to the runner to decide what to do with that failure.

  1. how precise should the feedback be?

Let's start with just enough feedback for the developer to debug their issue. Then we'll improve the error messages in any place that will confuse the API consumers.

  1. how should the continue on error option actually benefit the end-user?

Here's the entry to the rabbit hole:

WordPress/wordpress-playground#605

tl;dr – some failures may not be worth crashing the entire Blueprint execution pipeline. I may have an optional plugin or a content export file and I'm fine if they can't be set up.

a. not to cause a cascade of issues and obfuscate the root cause?

The runner could still produce warnings when a non-critical step fails.

b. which steps would actually benefit from this feature?

It's up to the developers to decide, they would explicitly mark specific steps in their Blueprints as "okay to fail".

c. this implies blueprints are a sort of execution tree - would there be a benefit to declaring it overtly?

What do you mean by a tree? I think of it as a linear flow like a Dockerfile.

  1. for a failing blueprint:
    a. what is the expected state?

For now, any state that was left on the disk after the last successful step.

b. should all changes be reverted?

Not in v1.

c. if not should all procured resources be discarded?

What do you mean? I don't understand this question.

d. if not - how should steps know a step was run and not fail?

The steps shouldn't be concerned with that at all. A step only has an input and an output, it doesn't care about the resolution logic or execution order.

As an idea -I was wondering about the utility a blueprint running mode that fails fast when a particular step fails but instead of failing the whole blueprint, returns control to the user for troubleshooting (this could prove useful for blueprint designers), and after corrections - continues from the last point of failure. To get a mental image think - blueprint wizard. This could yield a running installation and a final, successfull blueprint.

It will take some time to get there, but it would be a great developer tool!

@reimic
Copy link
Collaborator Author

reimic commented Feb 23, 2024

Ok. Thanks for the details answers and links. This allows me to continue adding tests. Huzzah! I now see the heuristic I should take.

b. should all changes be reverted?

Not in v1.

I see this an a issue that should be addressed rather quickly. Since, this means after a blueprint fails somewhere in the middle. It can't be rerun easily. I'd imagine achieving effective idempotency could be a goal here.

c. if not should all procured resources be discarded?

What do you mean? I don't understand this question.

I run a blueprint once. It gets me a bunch of resources. But fails at the very last moment. I run it the second time and the resources that were procured are already there. If not, we get the worst of both world - on one hand, the changes of steps are not reverted, and on the other - the resource streams have to be prepared anew.

@adamziel
Copy link
Collaborator

I see this an a issue that should be addressed rather quickly. Since, this means after a blueprint fails somewhere in the middle. It can't be rerun easily. I'd imagine achieving effective idempotency could be a goal here.

+1

I run it the second time and the resources that were procured are already ther

Aha! The runtime will be responsible for caching the downloads. Network transfer should only happen on cache miss.

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.

None yet

2 participants