Publish Your Extension

The Publish operation combines Git operations (commit, push, merge) to merge the changes in your local repository branch into the main branch.

Note:

If you need to review the relationship between your workspace, your project, and the Oracle Cloud Applications development environment, you may want to watch this video:

There are a few important details to attend to before you publish your extension:

If you used an Oracle Cloud Application sandbox in this extension, publish it first. Publishing the sandbox before merging your extension changes can help avoid potential problems resulting from using two different data models. For more about using and publishing sandboxes, see Sandboxes in Configuring and Extending Applications.
It's also a good idea to check and verify your extension's code before you publish. See Debug and Audit Your Code for more.
Make sure your extension has a suitable name and description. This helps users who may want to configure something in your extension later on, as both the extension name and description appear in the Dependencies list. To check what's currently set for your extension, click Menu in the upper right corner, then click Settings:

Description of the illustration extensionsettingoption.png
The Publish action packages and deploys whatever is in the remote repo's default branch (main). Under the covers, Publish does a commit of your current branch to your local main branch, then pushes it to the remote main branch before kicking off the package and deploy jobs.
If you want to deploy everything in your extension and you've been working in several different branches, make sure you commit and push the changes from all branches before clicking Publish. For example, suppose you're working on MyNewAppUI in branch A. You then get word that you need to quickly fix something in ProdAppUI. You create a new branch in your repo (or switch to the branch devoted to ProdAppUI), make the change, then click Publish. Only the changes in that branch are deployed; your changes to MyNewAppUI aren't deployed, unless you explicitly committed them to main, then pushed them to the remote repo before clicking Publish.

Tip:
The default package and deploy jobs typically publish your changes as part of a CI/CD pipeline, which gives you the flexibility of attaching additional jobs to the out-of-the-box configuration. If you don't need this option, you can opt to disable the pipeline to simplify your publishing process.
To ensure your changes will load successfully, the target instance must be running the same Oracle Cloud Application release version as your development instance. If you develop an extension on, say, 23D in your Test environment, then want to deploy the extension to your 23C Prod environment, you should wait until your Prod instance has been upgraded to 23D before you deploy the extension. In most cases there shouldn't be more than a two week gap between pod upgrades. See Oracle Applications Cloud – Fusion Applications Update Policy (Oracle account sign in required).

Note:

To successfully deploy your extension:

You must be authorized to run the build job (if the job is private).
Project owners can configure protection settings for build jobs so that only authorized project members can run the jobs. If you can't run a build job, ask the project owner or an administrator to add you to the build job's list of authorized users. If you're the project owner, check the job's protection settings. See Configure Job Protection Settings in Administering Visual Builder Studio.

If you can't access a project, you can use the Request Membership option in the project's Action menu on the Project Home page to request access. A project owner can approve your membership so that you can access the project, and authorize you to run build jobs. For more, see Request Membership in a Project You Can't Access in Using Visual Builder Studio.
The pipeline's deployment job (gitRepoName-Deploy) must be configured with the credentials of a user who has permissions to connect and deploy to the Oracle Cloud Applications instance in your environment. You won't be able to publish without these credentials.
The credentials must be Oracle Cloud Application credentials, as opposed to Visual Builder Studio or SSO credentials. If the project owner hasn't provided this information, you'll be prompted to provide it each time you click Publish. If your credentials don't allow you to deploy to the Oracle Cloud Applications instance, talk to the project owner or an administrator to get credentials that you can use. The credentials that you enter when prompted, if valid, will be permanently saved in the deployment job.

See Advanced Administrator Tasks in Administering Visual Builder Studio for more about setting up projects to publish extensions.

When you're ready to publish your extension:

Click Publish in the Designer's header:

Description of the illustration designer-publish-changes-action.png

Note:
If the Publish button is not enabled, it's likely because you're using a scratch repository instead of a real Git repo. If that's the case, and you do want to publish your work, click Scratch Repository next to your workspace name in the header and select Push. You'll get a dialog asking you to provide a name for your new repo.

The Publish operation combines Git operations (commit, push, merge) to merge the changes in your local repository branch into the main branch. Your screen should now look something like this:

Description of the illustration publishchanges.png
If you land on the Merge Now tab, that means you can go ahead and commit your changes after entering a comment in the Commit Message area. The comment should describe the changes you've made.
Optionally, you can switch to the Merge After Review tab to get someone to review your changes via a Merge Request. To create a Merge Request, enter a comment summarizing your changes, then specify other details such as reviewers and linked issues as needed.

Note:
If you don't see the Merge Now or the Merge After Review options, that means the project owner or an administrator has set things up so that all changes must always be reviewed and approved via a Merge Request before they are merged to the main branch. Additionally, the CI/CD pipeline may also be disabled. In this case, summarize your changes, add at least one reviewer (if no one is specified), and specify the related issue in the Publish dialog in order to create a merge request. (Once the request is created, you can look for it on the Merge Requests page. For details on how to work with merge requests, see Review Source Code with Merge Requests in Using Visual Builder Studio.)
Click Publish.

Tip:
Use the details in the Publish dialog to take note of the environment that your changes will be published to, which is typically the deployment target specified in the pipeline that's enabled for the main branch.

You'll see the Git commands that are automatically performed for you:

Description of the illustration designer-publish-changes-merge.png

Once you merge a branch into the main branch, you can no longer use it (or your local copy of it). A new branch is created automatically for you when you publish your changes, which you can use to make additional changes. Or you can create your own branch, if you prefer.

You should now see notifications like this in your workspace, which indicate when the package and deploy jobs have started, finished, or if one of them fails:

Description of the illustration notification-build.png

Your project is probably set up so that each time changes are merged into the main branch, the extension artifacts are built from the repository and automatically deployed to the Oracle Cloud Application's development environment, or to a test environment for further tests.

IMPORTANT: If your extension contains configurations for an Oracle Cloud Application, end-users of that application will have to sign out of the app, then sign back in again to be certain they're seeing the latest.