@@ -6,7 +6,7 @@ description: "This handbook page will help you understand what CI jobs you need
Here is a complete list of all of our CI jobs at GitLab https://handbook.gitlab.com/handbook/enterprise-data/platform/ci-jobs/ . This section is a work in progress.
The two main jobs you will need to know when working in MRs is the Build Changes job, and the Grant Clones job. These will be used in almost every MR you submit!
The two main jobs you will need to know when working in MRs is the Build Changes job, and the Run Grants job. These will be used in almost every MR you submit!
### Build Changes
@@ -24,40 +24,21 @@ In order to trigger this "build" action, you can use the pipeline which is acces
Once you have built your changes, this means that there is a new database which you can access that contains the MR's data which you have just created. Any code changes you have made are reflected, and any table which you have made changes to are available to query!
In order to access this, however, you need to grant yourself clones. If the table already exists (it is not a new table), then you can do this in the MR. You will find your pipeline, and use the "Grant Clones" job in the first step.
Unlike when you "build changes", you cannot just press the play button to the right of the name of the job. Instead, click on the green check mark that is the first in the line, and it will open all of the available jobs at that step. Look for "Grant Clones" and click on the text (not the play button).
In order to access this, however, you need to grant yourself clones. If the table already exists (it is not a new table), then you can do this in the MR. You will find your pipeline, and use the "Run Grants" job in the first step.
Unlike when you "build changes", you cannot just press the play button to the right of the name of the job. Instead, click on the green check mark that is the first in the line, and it will open all of the available jobs at that step. Look for "Run Grants" and click on the text (not the play button).
This will bring you to a screen where you can easily add your key/value pair - which is how you tell the pipeline that you want it to grant _you_ access to the MR database. Here you use `GRANT_TO_ROLE` as the key. The value is your Snowflake role name, which is often your email. So if your name is John Smith, and your role is JSMITH, then you would put `JSMITH` as your value. You can grant access to yourself, or to others. You can only grant one clone at a time, even though there is the option to add more than one in the interface.
This will bring you to a screen where you can easily add your key/value pair - which is how you tell the pipeline that you want it to grant _you_ access to the MR database. Here you use `GRANT_TO_ROLES` as the key. The value is your Snowflake role name, which is often your email. So if your name is John Smith, and your role is JSMITH, then you would put `JSMITH` as your value. You can grant access to yourself, or to others. You can only grant one clone at a time, even though there is the option to add more than one in the interface.
Once this finishes running, you can find the name of the branch you created for your MR in the list of databases which you have access to in Snowflake, and Tableau! This lets you test the impacts of your code changes.
#### Granting Clones to Net New Tables
If you are creating a net new table which has not existed yet, you will need to ask the Data Engineers to grant you access to the database/table. You can ask for permission for yourself and others, and you can ask for access to more than one table at once.
You need to specify the branch name, database, schema, and table. Most of the time you will be asking for access to tables in the PROD schema, so the general syntax is: `“branch_name_prod”.schema.table`
Here is an example message that you could copy and paste in the #data-engineering Slack channel to ask for access to your table. If it is your first time and you are nervous to get it wrong, feel free to let them know in the message you are new and might make a mistake.
```text
Hello @data-engineers, could you grant JSMITH and JDOE access to:
_Note_: Before you ask the data engineers for access to your table, make sure you build the changes to your pipeline, and the build succeeds. If you have not yet built the changes (sucessfully), they will respond and tell you that they tried to grant you access, but that schema was empty. They won't be able to grant you access to the table until it exists (which happens when it builds successfully).
### Custom Build Changes
Sometimes you may want to test MR changes that are not included in the scope of what gets built when you "Build Changes". This is most common when you make an adjustment to columns in an upstream table (such as a mart or prep table), but you actually want to test the impacts to those changes on your downstream report table.
@@ -5,7 +5,7 @@ description: "GitLab Data Team CI Jobs"
---
This page documents the CI jobs used by the data team in Merge Requests in both the [Data Tests](https://gitlab.com/gitlab-data/data-tests) and [Analytics](https://gitlab.com/gitlab-data/analytics) projects.
This page documents the CI jobs used by the data team in Merge Requests in both the [Data Tests](https://gitlab.com/gitlab-data/data-tests) and [Analytics](https://gitlab.com/gitlab-data/analytics) projects. For a quickstart guide on how to get started doing Merge Requests and using CI jobs, see [this practical guide](/handbook/enterprise-data/how-we-work/practical-guide/) in How We Work.
