Open pwasem opened 3 years ago
Related: https://github.com/SAP/ui5-tooling/issues/17
In the past I used to argue that ui5 build
should not do any deployment. Since UI5 Tooling is not a general task runner, our recommendation was to implement such deployment steps separately and execute them after ui5 build
has finished. For example Web IDE used to follow that concept or separating these steps.
I'm wondering, what's the motivation to integrate this into UI5 Tooling. Is there any API it can provide that would be beneficial? Your example seems to be pretty isolated and could also run in a separate script after ui5 build
.
Or is it more about the convenience of having all configurations in ui5.yaml
and the simplicity of having it integrated into a singe ui5 xyz
command?
Please note that cleanup tasks are also executed in case the build has failed or has been aborted. From the documentation:
It will also be executed in cases where the build has failed or has been aborted.
@RandomByte
True, build
and deploy
are two separate steps.
Regarding taskUtil.registerCleanupTask: yep that's why it is called a workaround :trollface:
The motivation is that e.g. there is an @sap/ux-ui5-tooling built on top of ui5 tooling
which has an deploy-to-abap
custom task which is subject to above restrictions.
There should also be many other use cases for an built completed
hook or event as the ui5 tooling evolves further.
I'm starting to think that the best approach to this would be to introduce a new extension type deployment-task
which is always executed after the build as finished.
This allows the tooling to execute all necessary finalization steps, like removing resources based on tags and to rewrite paths as done for application projects.
The deployment-task
can then work on exactly the same resources as dist
would contain. We could even skip writing to dist
(maybe based on a CLI parameter) since the deployment should be enough in most cases.
I guess this is a good candidate for writing an RFC. I'll try and ask around for thoughts on this idea.
@RandomByte I know this' an old issue, but it's still open and listed in the roadmap.
In case this' still planned to be implemented, pls don't.
Deployment shouldn't be coupled to build. Skipping build output creation is a terrible idea and goes against everything we see in other projects. Please, don't do that.
If you must do something for deployment, make it its own new module, eg, ui5-deployer
(or whatever). People could call ui5 build && ui5 deploy
. Happy days!
Hey @mauriciolauffer, thanks for providing your input!
From my understanding there is already a wide use for custom tasks implementing deployment functionality. Most prominently through the Fiori Tools deploy-to-abap
task mentioned by Pascal.
These tasks currently face quite some problems as outlined above. Therefore, I see this as a rather small implementation topic that would greatly improve the situation for the already established use of deployment tasks.
My proposal to eventually skip writing out the build result should of course be a configurable behavior.
Since this feature would be optional for any project, may I ask what your main concern relates to? I would expect no impact on projects that decide to use a dedicated tool for deployment purposes. Which is still my personal recommendation as mentioned above.
Separation of concerns. If you must create this task, call it something else rather than deploy, as it may be used for anything, not deployment only.
@mauriciolauffer just as initially suggested "afterTask: buildCompleted".
Is your feature request related to a problem? Please describe.
As of now (Specification Version 2.2) there is no proper way to execute a custom task after the build itself has succeeded. It is only possible to execute a custom task after other individual build tasks (latest possible point of time is
afterTask: generateVersionInfo
) At this point of time the build itself has not been completed, so thedist
folder has not been written yet. But a e.g. task for deployment requires the finaldist
folder for zipping and uploading.The @sap/ux-ui5-tooling custom task
deploy-to-abap
is an example for the lack of this feature.The custom task can only run
afterTask: generateVersionInfo
(documentation even statesafterTask: replaceVersion
, which is way to early btw).As a workaround the task only considers virtual build resources for deployment.
But only the
dist
folder contains the final physical resources and one should not rely on any virtual resources. Some custom tasks might even copy (physical) files from project shims to thedist
folder during the build process (e.g. ui5-task-copy-shim-resources).Describe the solution you'd like
An example config could look like this to register a custom task after the build has completed:
or
Describe alternatives you've considered
A workaround for now is to use taskUtil.registerCleanupTask, because this is the only point of time where one can be sure that the build has completed.
Additional context
This should be a feature that many projects should require when it comes to delivering for production using the UI5 Tooling.