From 2b75052eddeaeaa72a1f30fcfbd5e684f9107ab0 Mon Sep 17 00:00:00 2001 From: Tim Spencer Date: Tue, 27 Feb 2024 16:38:46 -0800 Subject: [PATCH 1/2] added repo syncing check, expand on how to make things come up faster --- _articles/platform-gitlab-prod-deploy.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/_articles/platform-gitlab-prod-deploy.md b/_articles/platform-gitlab-prod-deploy.md index 21c2a0f2..a918b286 100644 --- a/_articles/platform-gitlab-prod-deploy.md +++ b/_articles/platform-gitlab-prod-deploy.md @@ -36,6 +36,13 @@ we will have a manual deploy approval step so that we can control when they roll complete, or if they don't seem to be moving, [contact gitlab support](https://github.com/18F/identity-devops/wiki/GitLab-Ultimate-Licensing-and-Support) and ask for help in getting the migrations unstuck. +* Check that the repository mirroring for [identity-devops](https://gitlab.gitstaging.gitlab.login.gov/lg/identity-devops/-/settings/repository) + and [identity-devops-private](https://gitlab.gitstaging.gitlab.login.gov/lg/identity-devops-private/-/settings/repository) + on gitstaging is up to date and has no errors. Resolve the errors and get the repos up + to date before proceeding. Sometimes this gets jammed up for some reason. + Usually clicking on the button to tell it to resync is enough, but other causes + have been github having problems or the gitlab ultimate license not being applied + properly to gitstaging. * Notify people that you are going to do a deploy in `#login-team-mary`, `#login-team-radia`, `#login-devops`, and `#login-appdev`. I usually give 10-30 minutes warning and ask folks to ping me if this is a problem. Also, do it after 5pm eastern, and basically nobody ever @@ -56,7 +63,9 @@ we will have a manual deploy approval step so that we can control when they roll the deploy job will take >1h to run, which will cause it to fail. I usually check the build/test runner pool ASGs around the 20 minute marks, and add one to their `Maximum capacity` to cause them to start trying to launch instances again and thus - prevent the deploy job from timing out. + prevent the deploy job from timing out. If you want to make this most optimal, + do the `Maximum capacity` change just after the `production-gitlab` ASG has completed + recycling, so that they all can start up and register immediately. * The test job should indicate that everything went out OK, but it's never bad to check it out yourself and make sure that jobs are working and the UI is happy, etc. From 84bf082aac9654eb8e957b76a3716e5e0168b6e4 Mon Sep 17 00:00:00 2001 From: Tim Spencer Date: Tue, 27 Feb 2024 16:39:37 -0800 Subject: [PATCH 2/2] linkify pipeline url --- _articles/platform-gitlab-prod-deploy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/platform-gitlab-prod-deploy.md b/_articles/platform-gitlab-prod-deploy.md index a918b286..dfff94fe 100644 --- a/_articles/platform-gitlab-prod-deploy.md +++ b/_articles/platform-gitlab-prod-deploy.md @@ -51,7 +51,7 @@ we will have a manual deploy approval step so that we can control when they roll git SHA of the last successful push to gitstaging) and push it up. * Go to the pipeline that successfully deployed the code to gitstaging and click on the start button for the `gitlabproduction_deploy` job. -* Go to https://gitlab.gitstaging.gitlab.login.gov/lg/identity-devops/-/pipelines and find +* Go to and find the pipeline that was triggered. After the SAST jobs run, you should be able to click on the `deploy_production` job. It will say it needs approval, so go click on the link for that and approve it in the environments page under the `production` environment.