Bundles on Servd track the contents of specific Git Commits to ensure you have a clear papertrail from commit to deployment on the Servd platform. By default this means that only files which are part of your commit will end up inside the subsequent bundle.

If your CSS, JS and static images are checked into your repo already then you shouldn't have any problems. Build a bundle and you're all set! If not, there are a few options you can choose from to get everything set up nicely:

Servd now has the ability to compile your static assets whenever a new bundle is being built. This allows you to keep your static files out of your git repo whilst also ensuring they're compiled via a repeatable, automated process.

There are a few prerequisites to using this functionality.

We've tried to ensure that all of the commonly used OS packages are available for your build process, but if you encounter errors due to missing packages, please let us know so we can consider adding them.

If your project meets all of the above criteria Servd will offer to build your assets during initial project setup. If not, you can add a build command later via the Project Settings > Build & Deploy page in the Servd dashboard.

We will run `npm install` for you before executing your build command - no need to add that in yourself.

You can only run a single command as part of your build process, but this command can be anything. You won't have access to any globally installed node modules (gulp, webpack etc) but these can still be executed by using `npx` to execute them directly from the `node_modules/.bin` folder.

You can also set up 'npm scripts' and execute those using `npm run my-script-name`.

Some examples of acceptable commands:

`npm run build`

`npm run bundle --production`

`npx gulp compile-css`

`npx webpack build`

`./build.sh` (If ./build.sh is set as executable in the git repo)

Once your build process is complete it should result in your compiled assets being placed in their final location within the repo. This will probably be inside the `web` or `public_html` folder.

You can perform other tasks as part of your build process if you wish. For instance you could create a script which downloads some externally hosted assets so that they'll be included in the built bundle, or call out to an external API to gather some information and then hard code that into a php file.

The easiest, if not the most popular, solution to this is to just add your compiled assets to your repo. This will ensure your files end up exactly where you expect inside your bundles and in the exact form that they take in the Git Commit.

The primary disadvantage of this approach is that you may subsequently experience merge conflicts on these files if you're using multiple Git branches in your repo. However there area couple of easy fixes:

a. Recompile

When git complains about merge conflict on these files, just re-run your buildchain to generate new compiled assets and then resolve the merge conflict. Easy.
​

b. Ignore the conflict

Alternatively you can create a `.gitattributes` file in the root of your repo which lists the compiled files with a simpler merge strategy:

With that file added to the repo git will simply accept the remote version of the file when it encounters a merge conflict. You can then re-run your buildchain and create a new commit with the updated files.

Any external CI provider, including but not limited to:

Can be used to build our assets before triggering a bundle build on Servd.

Under normal circumstances Servd will build a bundle directly from the contents of a commit. If you want to avoid committing these files you can also send an archive of files to use instead.

The steps for your CI platform look a little like this...

Servd Custom Webhook Script?
​

This script can automate the archive and upload of your a craft base directory and trigger a bundle build based on the contents of this archive.

You can run it using a single command in your CI script which looks like this:
​

The arguments are as follows:

A real world example from Gitlab CI which we use to deploy the servd.host website:

GitLab supplies the `$CI_*` variables and we have defined the others as 'secrets' in the GitLab dashboard. Your CI provider of choice should allow you to do something similar.