Skip to main content

Merge Requests

Once you've made your changes on a feature branch (we like to use the branch naming convention of your-initials/feature-name, but there's no hard rule around it), stage and commit your changes, push your branch up to GitLab, and create your merge request.

When you create a merge request, a unique “deploy preview” environment is deployed for your branch so that you can view your changes in a production environment. The URL follows the structure https://docs-v2-$CI_PIPELINE_ID-test.kube.qa.internal.mx.

After the pipeline passes and your MR has been approved, do NOT hit the merge button to merge your MR into main. The “Shipit Deploy Bot” should comment on your MR outlining next steps for getting your changes merged and deployed. All you need to do is post a comment on your MR with the content “shipit” and the deploy process will kick off (sometimes the Shipit Deploy Bot doesn't comment, but adding your “shipit” comment will still kick off the process).

Shipit Deploy Bot​

The Shipit Deploy Bot follows a few steps:

  • Adds your MR to the deployment release queue
  • Runs some pre-check verifications
    • Verifies that the MR has all necessary approvals
    • Verifies that the MR is open and has no conflicts or merge errors
    • Verifies that the MR pipeline has passed
  • Starts a deployment pipeline

The Shipit Deploy Bot will auto rebase your MR and build the code as if it was merged, and deploy that code. If the deployment pipeline is successful, the bot will automatically merge your MR for you. If the deployment fails, the bot will automatically roll back to the previous version and your code will not be merged into main and your MR will remain open so that you can address the errors.

Deploy Previews​

As a default, deploy previews only last for 1 hour. If you want to extend that, follow the instructions on the Preview Deployments Confluence page for how to properly extend them from the Platform Tools.

Pipeline​

When a pipeline is triggered, the following jobs are kicked off:

  • OAS validation job - if an OAS file has been changed, we check to make sure the changed OAS file is still valid using Redocly's CLI

  • Build -

    • For main branch pipelines - we parse the markdown content into search records and send them to Algolia
    • Generate code snippets from the OAS and then run the docusaurus build command
    • As part of the docusaurus build command, Docusaurus runs a broken link checker against all of the markdown/mdx files and fails the pipeline if it finds any. Check the pipeline logs for the output of which links are broken.

  • Unit tests - Unit tests, built with Vitest, are run. The pipeline fails if any tests fail.

  • Deploy preview deploy (for MR pipelines) - A production environment build is deployed to QA in k8s to a URL that follows the structure https://docs-v2-$CI_PIPELINE_ID-test.kube.qa.internal.mx

  • End-to-end tests - e2e tests, built with Cypress, are run against the deploy preview URL (for MR pipelines) or http://docs.mx.com/ for prod. The pipeline fails if any tests fail.

  • Shipit Bot - This stage runs the jobs defined in some MX CI templates (see the top include in the .gitlab-ci.yml file). These templates are located in the ci-templates GitLab repo.

    • This handles all of the actual deploying to different environments in k8s (qa, sand, prod). If there are any issues with these jobs, reach out to #developer-productivity channel
On this page