Example .sra file structure for CI/CD automation
When you build your customizations, it is useful to package them in a consistent archival structure. To do this with HCL Commerce Search, a file called a Search Resource Archive (.sra) is proposed.
Designing a repository structure
When your customizations are complete, you can package the resources in a standard
compressed file format such as .zip or .tar. This archive can be picked up by
processes in subsequent stages of the CI/CD pipeline. It is logical if the file
structure of the archive follows that of the working repository you used to develop
the code, insofar as that is possible. The structure that is useful for building and
testing is not necessarily useful for packaging and transmitting the changes,
however. For example, to archive a new connector in such a way that the changed code
can be consistently picked up and used by the CI/CD build/deploy sequence, you could
use a repository file structure such as the
following,
pipes
│
├───new
│ auth.xfields.json
│
└───updates
1_auth.xfields
2_auth.xfields
and archive it in a similar but specialized way. For example, you could
include a separate directory for a manifest of the
archive.Ingest-pipeline.sra
├───META-INF
├───pipes
├───new
│ auth.xfield.json
└───updates
1_auth.xfield.json
2_auth.xfield.json
The logical structure of the archive is designed for portability. The
archive contains all the resources that could be needed to deploy the code. It could
directly mirror the original repository structure, or it could have an entirely
different hierarchy depending on your development and deployment needs. The aim is
to package all of your changes in such a way that they can be automatically found,
integrated, built and deployed by the CI/CD scripts.One useful approach is to change the archive extension so that (particularly on Windows) the scripts pick up those files for processing, and no others by mistake. Change your .tar or .zip to an .sra file, for example, where SRA stands for Search Resource Archive.