Make Angular’s source code available to Sentry with GitLab CI
By: Panagiotis Kapros
Tags: Sentry, Gitlab, Angular, Typescript, Debugging

Build Source Map Files

As you may know, Angular CLI uses webpack under the hoods for several tasks of our application build process, including building our TypeScript code. Webpack is able to generate the source map files which will allow us to reference the original TypeScript code with the generated JavaScript. But configuring webpack is not an easy task and the Angular team wants to keep this abstracted from the developers. The ng eject command of the Angular CLI would reveal us the underlying webpack configuration and allow us to configure the source map file generation, but now there is a better way!

Recently, thanks to @AlanAgius4 contribution 👏, we have better control over the source map files generation using Angular CLI angular.json file. The purpose of this file is to provide workspace-wide and project-specific configuration defaults for build and development tools. You can read more about it here:

We want to configure our angular.json file so that it generates the hidden source map files. They are called hidden, because the generated output files do not have references to them as opposed to the regular ones. This allows us to put them on Sentry without the need to host them on our web server. If you want to get deeper into source map files you can start here:

So let’s configure our angular.json file to generate the hidden source map files during the production build:

Now when we build our application with ng build --prod , the source map files will be available under dist folder:

Generate

Release Management

Sentry provides an abstraction called Releases which allow us to attach source artifacts to. The release API allows us to store source files (and source maps) within Sentry. In order to configure the release management, we need to do two things:

Configure the SDK with the release property during initialization e.g.:

Sentry.init({

release: "my-project-name@2.3.12"

})

2. Use the release API to create the release, upload our artifacts and finalize it. We will see how to do this in the next section.

Since we are aiming to build a continuous integration pipeline, that builds our application with every commit on GitLab, we want to name our releases with something unique. The commit SHA is a good candidate for our release name. In order to do that, we need to be able to provide it as environmental variable. So we will start with adding a variable into our environment.ts and environment.prod.ts files:

During our CI build process, we will replace the VERSION string with our Commit SHA, using the sed utility. To be honest, I wish there was a better way to pass environment variables at build time. This a highly requested feature:

Hopefully, this will be better in the future. For now, sed tool will do the work.

Create Gitlab CI

Thanks for being patient enough so far, and here is where everything falls into place. At the root of our angular application create our “.gitlab-ci.yml” file:

In this file, we define three jobs as part of our CI pipeline:

Stage build: Build our angular app, but first replace the VERSION variable (as we explained in the previous section) Stage sentry: Create our new release using the commit SHA and upload source map files. The $CI_COMMIT_SHA variable is pre-defined by GitLab. Stage deploy: Upload dist folder to GitLab pages, but remove the source maps files.