Publish Your Changes Through CI/CD Pipelines

Follow these steps when your extension's CI/CD Pipeline setting is enabled for the remote branch you're merging to. With this setting, your changes are deployed via CI/CD pipelines to your environment's Oracle Cloud Applications instance.

To successfully deploy your extension via a CI/CD pipeline:

• 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, use the Request Membership option in the project's Update project menu on the Organization 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 to deploy to the Oracle Cloud Applications instance in your environment.
  • If the deployment job is set up for OAuth (recommended), authorization must be provided for OAuth tokens to be created with the credentials of a user who has permissions to connect and deploy to the Oracle Cloud Applications instance. You won't be able to publish without this authorization. It is recommended that you authorize your connection during initial job configuration—though you'll be prompted to authorize missing or expired OAuth tokens when you click Publish.
  • If your deployment job uses Basic authentication, credentials of a user who has permissions to connect and deploy to the Oracle Cloud Applications instance must be provided. 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 when 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.

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

When you're ready to publish your extension:

1. Click Publish in the header:
   
   Description of the illustration designer-publish-changes-action.png
   

   Note:

   If Publish isn't enabled, you're likely using a scratch repository instead of a real Git repo. See Push a Scratch Repository to a Remote Repository to create a remote repo.

   The Publish operation combines Git operations (commit, push, merge) to merge the changes in your local repository branch into the target branch you select. Your screen should now look something like this:
   
   Description of the illustration publishchanges.png
   

2. If changes exist, enter a comment in the Commit Message area to describe your changes and commit them. A commit groups the changed files and provides a description to identify the group.
3. In the Target Branch field, select the branch in the remote repo to merge to.
   The first branch in this list is always the repository's default branch, main, conveniently followed by the last 10 branches you created merge requests for (if any). Any remaining branches follow in alphabetical order. This flexibility lets you more easily publish and test your new feature development work, if you're not yet ready to merge those changes into your repository's main branch.
4. If you land on the Merge Now tab, the New Working Branch Name field displays with an automatically populated new name for your working branch. You can accept the default, but it's recommended to change to a name that's more meaningful.
   Once you publish a branch, you can no longer use it (or your local copy of it). Instead, VB Studio automatically creates a new working branch using the value in this field, and switches your workspace to it for any future changes.
5. If you'd rather get someone to review your changes via a merge request, click the Merge After Review tab. After entering a comment summarizing your changes, you can then specify other details such as reviewers and linked issues as needed. You can also enter a description of all your changes (not just this commit) in the Merge Request Description field, using the convention established for the template (Markdown, Confluence, or Textile). If you need help, use the link to the associated reference.

   Note that the New Working Branch Name field doesn't display because, if a merge request is created, VB Studio won't automatically create a new working branch and switch your workspace to it. After the merge request is approved and your extension is published, however, you should manually switch the workspace to a new working branch.

   Note:

   If you see only the option to commit and merge your changes via a merge request (that is, there's no Merge Now tab), 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 target branch. In this case, summarize your changes in the Publish dialog, add at least one reviewer (if no one is specified), and specify the related issue 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.)

   If a merge request is required but a CI/CD pipeline hasn't yet been set up, the dialog will display a message indicating that the Publish action will only merge your changes; to fully deploy your extension, you'll need to first set up a pipeline for the remote branch. See Deploy Changes from a Different Branch in Administering Visual Builder Studio.

6. 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 selected target branch.
7. If the deployment job in your CI/CD pipeline is missing the credentials required to connect and deploy to your environment's Oracle Cloud Applications instance, you'll be prompted to complete some additional steps:
   • If you see a message that authorization is required, it means the deployment job is set up for OAuth and requires authentication for the OAuth connection to the target Oracle Cloud Applications instance:
     1. Click OK.

     2. If prompted, enter the credentials of a user who can access the target Oracle Cloud Applications instance.

        If you land on the Authorize Jobs page, your Deployment job may have missing or expired OAuth tokens. Click Authorize, enter the credentials of a user who can access the target Oracle Cloud Applications instance, and click Authorize.

     3. Once authorization is complete, click Publish again in your workspace's Publish dialog.
   • If you see a message about missing deployment credentials, it means the deployment job uses Basic authentication and requires the credentials of a user who has permissions to access the target Oracle Cloud Applications instance. Enter valid credentials and click Add Credentials and Continue.
   You'll now see the Git commands that are automatically performed for you as part of the publishing process:
   
   Description of the illustration designer-publish-changes-merge.png
   

You should then see notifications in the bottom right corner of your workspace, indicating that the publish process has started. (If you miss these notifications or want to track progress, look for them under Notifications in the header.) If a build job fails, you'll see something similar to this message and will need to take action to resolve the issue (click Open job to view the job's details and take action):

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. When ready, you can deploy your extension to other Oracle Cloud Applications instances as well, either by modifying your project's build pipeline or by using the Manage Extension Lifecycle page.

IMPORTANT: If your extension contains configurations for an Oracle Cloud Application, 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.