Leverage local packages when possible
While working with Nuve's personal development environments and installing a repository using abapGit, the best practice is to opt for local packages (starting with a $). This approach eliminates the need for transports.
However, in certain cases - like when using a custom namespace with sub-packages, creating a transport may be inevitable. Here's how you can tackle it:
Use an existing open transport
If there's an open transport within your backup that fits your needs, it's as simple as passing it as a parameter during the pull operation. The command would look something like this:
${SAPCLI_CONFIG} startrfc -c bapi ZABAPGIT_API_RFC_PULL -S=ABAP_PACKAGE:${ABAP_PACKAGE} -S=GIT_USER:${GH_USERNAME} -S=GIT_PASSWORD:${GH_TOKEN} -S=CORRNR:SIDK900001
Remember to replace the placeholder transport with the actual transport number you're using.
Creating a new transport
If you don't have an open transport readily available, you'll need to create a new one. For this, Nuve offers a convenient function module:
${SAPCLI_CONFIG} startrfc -c bapi ZNUVE_CREATE_TR -S=IM_REQUEST_TYPE_V:'K' -S=IM_AUTHOR_V:${SAP_USER} -S=IM_TEXT_V:${REPO_NAME}
The request type parameter, IM_REQUEST_TYPE_V
, is optional. By default, a workbench ('K') transport is assumed, but you can customize it to create a configuration ('W') or a transport of copies ('T').
Ensure the transport is created before calling ZABAPGIT_API_RFC_PULL
so that it can be passed as a parameter.
Tailoring these commands to your specific use case is critical to maintaining a fluid development environment with Nuve. Remember flexibility and customization are key to maximizing efficiency.