vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Create a build configuration that pulls source from a local directory 

If your source is on your local workstation, create a build configuration with settings that include information about where to pull source from the local directory. For the build output, you can choose to specify registry details, or you can choose to let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry.

You can create a build configuration that pulls source from a local directory by using only the Code Engine CLI.

When you submit a build that pulls code from a local directory, your source code is packed into an archive file and uploaded to your IBM Cloud Container Registry instance. Note that you can only target IBM Cloud Container Registry for your local builds. The source image is created in the same namespace as your build image.

You can choose to ignore certain file patterns from within your source code by using the .ceignore file, which behaves similarly to a .gitignore file. For example, entries for a .ceignore file for a node.js application might include node_modules and .npm. For more sample file patterns to ignore, see the [GitHub .gitignore repository](https://github.com/github/gitignore).

Creating a build configuration does not create an image, but creates the configuration to build an image. You must then run a build that references the build configuration to create an image. The build configuration is not validated or used to create an image until the build is run. The build configuration enables multiple subsequent builds of an image, such as when changes are applied to the source repository.



 Creating a build configuration with the CLI (local source) 

To create a build configuration that pulls code from a local directory with the CLI, use the build create command and specify the build-type as local. For a complete listing of options, see the [ibmcloud ce build create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-create) command.

With the build create command, you can choose to let Code Engine take care of building the image from your source for you and storing the image in IBM Cloud Container Registry.
To create a build configuration that pulls code from a local directory with the CLI, use the build create command and specify the build-type as local. For a complete listing of options, see the [ibmcloud ce build create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-create) command.

With the build create command, you can choose to let Code Engine take care of building the image from your source for you and storing the image in IBM Cloud Container Registry. For this automatic access case, you do not need to specify a registry secret or the location of the image registry. Or, you can specify the location for your build image output and provide a registry secret so that Code Engine can access and push the build result to your registry.



 Creating a build configuration with the CLI (with local source and automatic access to registry) 

In this scenario, Code Engine builds an image from your local source, and automatically uploads the image to IBM Cloud Container Registry. See [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry) for more information about setting required permissions for Code Engine to automatically access these images in Container Registry.

Before you begin



* [Set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).





1. Create a build configuration to build an image from source on your local workstation and let Code Engine automatically store and access the image. When you specify local as the value for -build-type, you can only target IBM Cloud Container Registry for the output of your local build. In this example, the command uses the default dockerfile strategy, and the default medium build size. By not specifying the location of the image registry or a registry secret, Code Engine pushes the build output to IBM Cloud Container Registry with automatic access.
If your source is on your local workstation, and you want to use a single command to build and output a container image, then use the buildrun submit command to create the container image without creating a reusable build configuration.

For the build output, you can choose automatic access and let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry. For this case, you do not need to specify a registry secret or the location of the image registry. Or, you can choose user-provided access and specify registry details along with a registry secret to access your built image in the registry.

When you submit a build that pulls code from a local directory, your source code is packed into an archive file and uploaded to your IBM Cloud Container Registry instance. Note that you can only target IBM Cloud Container Registry for your local builds. The source image is created in the same namespace as your build image.

You can choose to ignore certain file patterns from within your source code by using the .ceignore file, which behaves similarly to a .gitignore file. For example, entries for a .ceignore file for a node.js application might include node_modules and .npm. For more sample file patterns to ignore, see the [GitHub .gitignore repository](https://github.com/github/gitignore).

For a complete listing of options for running a single build, see the [ibmcloud ce buildrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-buildrun-submit) command.



 Running a single build with the CLI (with local source and automatic access to registry) 

In this automatic access scenario, Code Engine builds an image from your local source, and automatically uploads the image to IBM Cloud Container Registry with automatic access by using build options with the buildrun submit command.

See [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry) for more information about setting required permissions for Code Engine to automatically access these images in Container Registry.
For example, the following build create command creates a build configuration that is called helloworld-build-private that builds from the private Git repo https://github.com/myprivaterepo/builds, and uses the buildpacks strategy and medium build size. Code Engine automatically uploads the image to IBM Cloud Container Registry. Also, because the branch name of the repository is not specified with the --commit option, Code Engine automatically uses the default branch of the specified repository, which is main for this Git repo. By not specifying the location of the image registry or a registry secret, Code Engine pushes the build output to IBM Cloud Container Registry with automatic access.

Because the Git repo provided is private, access requires a Git repo secret. As a result, the --source that you specify must use the SSH protocol, such as git@github.com:myprivaterepo/builds.git. The value for --source must not use the http or https format.

ibmcloud ce build create --name helloworld-build-private --source git@github.com:myprivaterepo/builds.git --context-dir /hello --strategy buildpacks --git-repo-secret myrepo
2. After you create the build, you must [run the build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-imagebuild-run).







 Creating a build configuration with the CLI (with private repo source and user-provided access to registry) 

In this scenario, Code Engine builds an image from your private repository source with a Git repository secret that you provide, and then uploads the image to your container registry with the registry access that you provide.

Before you begin



* [Set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).
See [Getting system event information for applications](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-appsts-app-gettingevent).

For more information about logging, see [Viewing logs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-view-logs).





 Running applications 

Whether your code exists as source in a local file or in a Git repository, or your code is a container image that exists in a public or private registry, Code Engine provides you a streamlined way to run your code as an app.

You can deploy and run applications in Code Engine in the following ways:



* Run from an existing container image. Create an application and provide a reference to your image to use when you deploy your app with Code Engine.
* Run from existing source code without any container image. If you are starting with source code that is located in a Git repository or on your local workstation, you can point to the location of your source and Code Engine takes care of building the image for you. Code Engine supports building from a Dockerfile and Cloud Native Buildpacks, which inspects your source code to determine how it must be built and packaged as a container image.



For more information about deploying and running applications, see [Working with apps in Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloads).





 Scaling 

Code Engine applications scale up or down depending on the incoming requests. Applications follow the scale-to-zero model, where no instances are created in the absence of traffic, leading to cost optimization. When there is an incoming request, an app automatically scales up from zero to accommodate the workload.

With Code Engine, you can control autoscaling by setting the minimum and maximum number of instances. You can also specify the concurrency of the application by specifying the number of requests to run in parallel for a specific application instance, to help determine when a new instance is provisioned.
When your code exists as source in a local file or in a Git repository, Code Engine provides options for you to build your code as a container images. Code Engine gives you the flexibility to build your container image by using one of the following options:



* Use a single CLI command, buildrun submit, to run one build run. The benefit of this option is that you can obtain your build with a single CLI command; however, the configuration for the build is not preserved. See [Building a container image with stand-alone build commands (CLI)](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-standalone).
* Define a build configuration from which you can run multiple build runs. See [Building a container image by using a build configuration](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image).



Both of these options apply for cases where you have [repositories for your source](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories) and [registries for your container image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry) that are public or private. Also, these options apply for cases where you choose to specify registry details with a registry secret for your build output, or you choose to let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry with automatic access.





 Choose your container image registry 

Code Engine pulls source code from a Git repository or a local directory, builds it, and then pushes (uploads) the image to a container image registry.

You can use [repositories for your source](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories) and [registries for your container image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry) that are public or private.
source local.env
3. Create the resources:

terraform init
terraform apply
4. Test the curl commands







 Step 9: Remove resources 



1. Destroy the resources. You can change (cd) to the team directories in order, and execute source local.env; terraform destroy. The order is application2, application1, shared, network, admin. There is also a script that will do this for you:

cd ..
./bin/destroy.sh







 Expand the tutorial 



 Other Considerations 



* The Application team is providing access to the application via a floating IP address. Consider connecting this to IBM Cloud Internet Services. It can manage the public DNS and provide security. [Deploy isolated workloads across multiple locations and zones](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-multi-region) has an example.
* The Application team can scale horizontally using a load balancer like the shared team.
* The shared team can add additional instances to the load balancer by adding instances to the shared/main.tf.
* The shared team could switch their implementation platform to Kubernetes.







 Continuous Delivery 



* Installation of software is currently done when the VPC instance is created. The delivery of new versions of software to production has not been considered. [Application Deployment to a Virtual Private Cloud with a DevOps Toolchain](https://www.ibm.com/cloud/blog/application-deployment-to-a-virtual-private-cloud-with-a-devops-toolchain) demonstrates one solution.
* For shared microservices, a new VSI could be created with a new version and after verification DNS could be adjusted or the shared load balancer could be used to switch to the new version.







 Automation, Staging, and Development 



* For production the teams can each have their own [Schematics](https://cloud.ibm.com/schematics/overview) workspace. With Schematics, Terraform configurations can be executed directly in the cloud where state and output can be shared.
When your build run is based on build configuration, this build run is deleted after 3 hours if the build run is successful. If the build run is not successful, this build run is deleted after 48 hours.

Now that you have deployed your application, you can view information about application revisions and any running instances, and configuration details.





 Deploying your app from repository source code with the CLI 

You can deploy your application directly from repository source code with the CLI. Use the app create command to both build an image from your Git repository source, and deploy your application to reference this built image.

Before you begin



* Set up your [Code Engine CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli) environment.
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



In this scenario, Code Engine builds an image from your Git repository source, automatically uploads the image to your container registry, and then creates and deploys your app to reference this built image. You need to provide only a name for the app and the URL to the Git repository if the image is to be located in an IBM Cloud® Container Registry account. In this case, Code Engine manages the namespace for you. However, if you want to use a different container registry, then you must specify the image and a registry secret for that container registry. For a complete listing of options, see the [ibmcloud ce app create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-create) command.

For information about required permissions for accessing image registries, see [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).

The following example application create command creates and deploys the myapp app, which references an image that is built from the https://github.com/IBM/CodeEngine build source.
If workloads in different projects want to communicate with each other, then the communication must either use the internet or an internal IBM private network. For more information, see [Options for visibility for a Code Engine application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsoptionsvisibility).

Create a project in Code Engine called sample-proj.

ibmcloud ce project create --name sample-proj

Example output

Creating project 'sample-proj'...
ID for project 'sample-proj' is 'abcdabcd-abcd-abcd-abcd-abcd12e3456f7'.
Waiting for project 'sample-proj' to be active...
Now selecting project 'sample-proj'.
OK

Notice that your project is also selected for context, so all subsequent application-related commands are within the scope of this new sample-proj project.





 Step 3: Deploying your application 

This sample application pulls code from the [sample GitHub repository](https://github.com/IBM/heroku-to-code-engine). This code is a simple Push your code to Code Engine by using the application create command. You must provide a name for your application and the location of the source code. The following example creates an application called myapp that uses the buildpack strategy and provides the location for the source code in the current directory (.).

ibmcloud ce app create --name myapp --build-source https://github.com/IBM/heroku-to-code-engine

Example output

Creating application 'myapp'...
Packaging files to upload from source path '.'...
Submitting build run 'myapp-run-220999-210706331'...
Creating image 'private.us.icr.io/ce--6ef04-khxrbwa0lci/app-myapp:220418-0207-askql'...
Waiting for build run to complete...
Creating a build configuration from the console (private repo) 



1. Go to the [Code Engine dashboard](https://cloud.ibm.com/codeengine/overview).
2. Select the project where you added your container registry.
3. From the project page, click Image builds.
4. Click Create. The Specify build details side panel opens where you enter the details of your build.
5. In the Source section, enter a name for your build, the URL of your source repository, and your code repo access. If your code is in a private repo, use an SSH URL for the code repository URL and either select the name of an existing code repo access or [create a code repo access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories). An example of an SSH URL is git@github.com:IBM/CodeEngine.git. Optionally, select a source branch name. If you do not provide a branch name and you leave the field empty, Code Engine automatically uses the default branch of the specified repository. You can enter any other branch name, tag, or commit ID. Click Next to continue.
6. In the Strategy section, select the [strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy) that you want to use. If you select Dockerfile, you can also specify an alternative path for your Dockerfile. Select the size of your build under Build resources. Click Next to advance to the last section.
7. In the Output section, enter the details of your container image. Select an existing registry access secret, or click Create registry access secret to add a new one. If you are building your image to a Container Registry instance that is in your account, you can select Code Engine managed secret and let Code Engine create and manage the secret for you. Then, select the namespace, repository, and tag of the image you want to build.
* If you have a container image, per the [Open Container Initiative (OCI) standard](https://opencontainers.org/), then you need to provide only a reference to the image, which points to the location of your container registry when you deploy your app. You can deploy your app with an image in a [public registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app) or [private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-private).

If you created your app by using the app create command and you specified the --build-source option to build the container image from local or repository source, and you want to change your app to point to a different container image, you must first remove the association of the build from your app. For example, run ibmcloud ce application update -n APP_NAME --build-clear. After you remove the association of the build from your app, you can update the app to reference a different image.
* If you are starting with source code that resides in a Git repository, you can choose to let Code Engine take care of building the image from your source and deploying the app with a single operation. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry. To learn more, see [Deploying your app from repository source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-source-code). If you want more control over the build of your image, then you can choose to [build the image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image) with Code Engine before you deploy your app.
* If you are starting with source code that resides on a local workstation, you can choose to let Code Engine take care of building the image from your source and deploying the app with a single CLI command. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry.
For example, the following command creates a build configuration that is called helloworld-build-private that builds from the private Git repo https://github.com/myprivaterepo/builds, uses the buildpacks strategy and medium build size, and stores the image to us.icr.io/mynamespace/codeengine-helloworld by using the registry secret that is defined in myregistry.

Because the Git repo provided is private, access requires a Git repo secret. As a result, the --source that you specify must use the SSH protocol, such as git@github.com:myprivaterepo/builds.git. The value for --source must not use the http or https format.

In this example, the command uses the default medium build size. Because the branch name of the repository is not specified with the --commit option, Code Engine automatically uses the default branch of the specified repository.

ibmcloud ce build create --name helloworld-build-private --image us.icr.io/mynamespace/codeengine-helloworld --registry-secret myregistry --source git@github.com:myprivaterepo/builds.git --context-dir /hello --strategy buildpacks --git-repo-secret myrepo
2. After you create the build, you must [run the build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-imagebuild-run).











 Create a build configuration that pulls source from a local directory 

If your source is on your local workstation, create a build configuration with settings that include information about where to pull source from the local directory. For the build output, you can choose to specify registry details, or you can choose to let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry.

You can create a build configuration that pulls source from a local directory by using only the Code Engine CLI.