SAP / ui5-tooling

An open and modular toolchain to develop state of the art applications based on the UI5 framework
https://sap.github.io/ui5-tooling
Apache License 2.0
468 stars 71 forks source link

Feature Request: Provide hook for executing custom task after build has been completed #490

Open pwasem opened 3 years ago

pwasem commented 3 years ago

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 the dist folder has not been written yet. But a e.g. task for deployment requires the final dist 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 states afterTask: 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 the dist 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:

builder:
  customTasks:
  - name: deploy-to-abap
    afterTask: buildCompleted
    configuration:
      some: configurations 

or

tooling:
  lifecycleTasks:
  - name: deploy-to-abap
    after: buildCompleted
    configuration:
      some: configurations 

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.

module.exports = async ({ taskUtil, options }) => {
  const { configuration = {} } = options
  const { target, credentials, app } = configuration
  const { url, client } = target
  const { username, password } = credentials
  const { transport } = app
  // https://sap.github.io/ui5-tooling/api/module-@ui5_builder.tasks.TaskUtil.html
  taskUtil.registerCleanupTask(async () => {
    await abapDeploy({
      sourceFolder: path.join(process.cwd(), 'dist'),
      targetSystem: url,
      client,
      username,
      password,
      abapTransport: transport
    })
    await cleanup([
      '.ABAPDeployResources',
      'abap-deploy.log',
      'dist.zip'
    ])
  })
}

Additional context

This should be a feature that many projects should require when it comes to delivering for production using the UI5 Tooling.

RandomByte commented 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.

pwasem commented 3 years ago

@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.

RandomByte commented 3 years ago

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.

mauriciolauffer commented 1 year ago

@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!

RandomByte commented 1 year ago

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.

mauriciolauffer commented 1 year ago

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.

pwasem commented 1 year ago

@mauriciolauffer just as initially suggested "afterTask: buildCompleted".