Task #50847

get rid of before and after stage step foo

Added by Felix Oertel about 8 years ago. Updated almost 6 years ago.

Status:
Rejected
Priority:
Won't have this time
Assignee:
Target version:
-
Start date:
2013-08-06
Due date:
% Done:

0%

Estimated time:

Description

hey,

after the recent changes, introducing packaged deployment (which i love!), we ended up with some new, kind of weird don't-know-really-what-they-are-kind-of-substages.

foreach (array('before', 'tasks', 'after') as $stageStep) {

i don't really get that. i loved how the tasks are fully configurable in the workflow. now i have this three substages, which are pretty much hard-wired.

if you want to run one task after another, why not just introduce an additional stage, instead of introducing much more if() and foreach()?

please enlighten me ... ;)

regards, foertel

#1

Updated by Tobias Liebig about 8 years ago

  • Assignee set to Christopher Hlubek
#2

Updated by Christopher Hlubek about 8 years ago

  • Status changed from New to Needs Feedback
  • Assignee changed from Christopher Hlubek to Felix Oertel

We discussed some different approaches to integrate the new tasks into the workflow (Rens, some others and me).

One was indeed a solution where we needed a lot of new stages to get tasks in between which would bloat the list of stages. So we decided to add a (pretty simple) built-in stage hook for before and after a stage which is consistent with the way you can add tasks before or after another task.

In the end this really is the same as having an explicit "before-transfer", "transfer" and "after-transfer" stage (repeated for every stage).

The idea is, that default application templates should try to add tasks before or after a named stage and the user is then in full control of the tasks inside a stage. Before that change mostly everything depended on a GitCheckoutTask which was problematic since it could not be replaced easily. And we needed a way to execute some tasks before or after the transfer is complete.

Do you have a use case which is not supported or which results in a bad solution (code-wise) after the change?

#3

Updated by Felix Oertel about 8 years ago

Hey Christopher,

i think in most cases you will only need one or two dependant tasks and i think it's much nicer (code-wise), to just add one or two additional stages, instead of having iterations for each and every task.

from the code, i get a strong feeling, that there is something wrong. ;)

if (isset($this->tasks['stage'])) {
            foreach ($this->tasks['stage'] as $applicationName => $steps) {
                foreach ($steps as $step => $tasksByStageStep) {
                    foreach ($tasksByStageStep as $stageName => $tasks) {
                        $this->tasks['stage'][$applicationName][$stageName][$step] = array_filter($tasks, function($task) use ($removeTask) { return $task !== $removeTask; });
                    }
                }
            }
        }
        if (isset($this->tasks['after'])) {
            foreach ($this->tasks['after'] as $applicationName => $tasksByTask) {
                foreach ($tasksByTask as $taskName => $tasks) {
                    $this->tasks['after'][$applicationName][$taskName] = array_filter($tasks, function($task) use ($removeTask) { return $task !== $removeTask; });
                }
            }
        }
        if (isset($this->tasks['before'])) {
            foreach ($this->tasks['before'] as $applicationName => $tasksByTask) {
                foreach ($tasksByTask as $taskName => $tasks) {
                    $this->tasks['before'][$applicationName][$taskName] = array_filter($tasks, function($task) use ($removeTask) { return $task !== $removeTask; });
                }
            }
        }
#4

Updated by Rens Admiraal about 8 years ago

hey Felix, can you enlighten what you think is wrong codewise? Is it just the duplication, the nesting, or? Would be nice if you could make your point a bit more explicit.

Regarding the dependant tasks: it's not just that tasks can be dependant. You could have a task that should just be done after a local packaging, and before uploading. But adding the extra dependency on execution after a specific task would be too much. Like (just an example) when you would like to send a notification that the actual upload is starting after a local packaging. Would I care that this happens after a specific task in the packaging stage, or do I just want to say "when the packaging is done, I want.... "

Besides that it's harder to maintain your list of tasks if you for example append a task to the packaging stage if you only have those tasks dependencies.

#5

Updated by Helmut Hummel almost 6 years ago

  • Status changed from Needs Feedback to Rejected
  • Priority changed from Could have to Won't have this time

Development of TYPO3 Surf now moved to Github. If you think this is still relevant, please open a bug report or feature request here:

https://github.com/TYPO3/Surf

Also available in: Atom PDF