Open claudiu-cristea opened 4 years ago
Proposal look good, only we need to make sure that whatever we do in 1.x does not require any manual fix on libraries that depends on it, such as the Toolkit, but I guess that's what you meant by:
Keep the drupal:settings-setup as default command, so that is guaranteed that Toolkit can override it as it does now but remove the command body and replace it with a call to the openeuropa/task-runner-drupal method.
About:
Are changelog:generate and release:create-archive Task Runner core commands or we should move them out, somewhere (where?)?
We could create two new repos:
openeuropa/task-runner-changelog
openeuropa/task-runner-artifact
(archive
actually refers to that, as in: to the possibility to create artifacts)we need to make sure that whatever we do in 1.x does not require any manual fix on libraries that depends on it, such as the Toolkit, but I guess that's what you meant by:
Yes, the Toolkit will not be affected.
We could create two new repos:
Great! This add more clarity to the whole ecosystem. I will create 2 new tickets.
@ademarco Could you, please, create the 3 new repos with the same perms as this one?
Yep, will do!
Problem
Task Runner provides default commands but some of them are Drupal-specific commands. In fact Task Runner it's not supposed to be a "Drupal tool" but a generic command runner. For this reason, the Drupal specific commands should be moved outside, in their own repo, i.e.
openeuropa/task-runner-drupal
.However, this might impact some projects that are using Task Runner, mainly the Toolkit project. Currently, Toolkit uses or overrides some of the Task Runner default commands as follows:
drupal:settings-setup
: Overridden,drupal:permissions-setup
: Used,drupal:site-install
: Used,The problem is with the current
drupal:settings-setup
command. This can be overridden by Toolkit because the Task Runner version is registered before the namespace discovered commands. If we move the Task Runner version in a 3rd party library, we cannot guarantee which version will be discovered first and the Toolkit override might not work. But we want to guarantee that Toolkit is able to override the Task Runner version.Proposal
For this reason, we propose the following strategy:
[ ] #131 in branch 1.x
Move all Drupal commands in a new project:
openeuropa/task-runner-drupal
.In
openeuropa/task-runner-drupal
, renamedrupal:settings-setup
asdrupal:setup-settings
(ordrupal:build-settings
,drupal:settings
?).Add
openeuropa/task-runner-drupal
as Composer dependency toopeneuropa/task-runner
, so that third-party that are updating their Task Runner version will continue to have available the Drupal commands.Keep the
drupal:settings-setup
as default command, so that is guaranteed that Toolkit can override it as it does now but remove the command body and replace it with a call to theopeneuropa/task-runner-drupal
method.Add a
[deprecated]
prefix to thedrupal:settings-setup
command description.Trigger a muted user deprecation error from the Task Runner's
drupal:settings-setup
command:Move all other default commands under a normal namespace, but inside
openeuropa/task-runner
.[x] #133 in branch 1.x
Move
changelog:generate
in a newopeneuropa/task-runner-changelog
repository.Depend on
openeuropa/task-runner-changelog
for BC reasons.[ ] #134 in branch 1.x
Move
release:create-archive
in a newopeneuropa/task-runner-artifact
repository.Depend on
openeuropa/task-runner-artifact
for BC reasons.[ ] #132 in branch 2.x
Remove the dependencies to
openeuropa/task-runner-drupal
,openeuropa/task-runner-changelog
andopeneuropa/task-runner-artifact
fromopeneuropa/task-runner
. Third party, such as Toolkit, will have to explicitly add these dependencies if they requires them.Remove the
drupal:settings-setup
command together with the concept of default commands.