Refactor: implement tag-based deployment

[lalver1]

This PR implements the second step of code changes needed to transition the benefits repository to tag-based deployments as described in #1527.

The code changes are associated with:

• GitHub workflows
• Azure DevOps/Terraform pipeline
• Python package versioning using git metadata

The last step needed to close #1527, will be to remove the test and prod branches and remove references to them in all the GitHub workflows.

Acceptance Criteria

• Merging to main deploys to the dev environment
• Pushing a pre-release tag deploys to the test environment
• Pushing a release tag deploys to the prod environment and triggers the release job
• The conditional environment, dev and prod Azure jobs (terraform stage) run correctly
• Python package versioning uses git metadata
• There is a guarantee that the required checks have passed on the commit to be deployed

[github-actions]

Coverage report

This PR does not seem to contain any modification to coverable code.

[lalver1]

Now deploy and release are two sequential jobs in the Deploy workflow. I grouped the two release steps into the release job to set the if condition and the permissions just once at the job level instead of twice if they had been at the step level.

Unfortunately I couldn't set ${{ github.ref_type != 'tag' && github.ref_name || contains(github.ref, '-rc') && 'test' || 'prod' }} as an environment variable using env in the workflow and avoid duplicating writing it out since the env context is not available at the job level, only at the step level.

With this implementation we'll have the following behavior in main:

• push a commit:
  • set environment = main
  • push image to GHCR
  • deploy to https://dev-benefits.calitp.org/
• push an rc tag:
  • set environment = test
  • push image to GHCR
  • deploy to https://test-benefits.calitp.org/
• push a tag:
  • set environment = prod
  • push image to GHCR
  • deploy to https://benefits.calitp.org/
  • if deploy succeeded and deployment environment == prod , make a GitHub release

[thekaveman]

This is looking really good so far! I think the workflow updates all look correct.

But we still need the updates to the Azure DevOps/Terraform pipeline, which is looking at the old test and prod branches etc.

Take a look at Server for how those pipelines work with tag-based.

[thekaveman]

Also, don't forget that tag-based deployment means we get the version number from the tag instead of hardcoding it in the source.

That means changes at least to pyproject.toml and probably the Docker build process.

See these PRs for how it was done elsewhere:

• Feat: automate GitHub releases littlepay#11
• Feat: version from git metadata eligibility-server#382

Accidental approval

[thekaveman]

@lalver1 you should be able to rebase on main now to get the Cypress tests passing.

Fixed by #2214

[lalver1]

Thanks @thekaveman, trying it now!

[lalver1]

Thanks for the review, I had overlooked the Azure DevOps/Terraform pipeline and the dynamic versioning part. I think we should now have all the parts ready for tag-based deployment.

The only thing I don't feel very confident about is if we need COPY .git .gitin the dev container's Dockerfile since we already have this line in the app container's Dockerfile. If indeed we don't need it, I guess including it has no impact in how it works, it would just make the code cleaner.

[thekaveman]

Getting really close @lalver1, this is looking great.

Just a few more small notes and I think it's ready.

[thekaveman]

The only thing I don't feel very confident about is if we need COPY .git .gitin the dev container's Dockerfile since we already have this line in the app container's Dockerfile. If indeed we don't need it, I guess including it has no impact in how it works, it would just make the code cleaner.

I was wondering the same thing. I see we do it this way in Server, so there must have been a reason. No worries, it is copied over immediately once we launch the devcontainer, so I think you can just leave it as-is.

[thekaveman]

These lines could be normalized to move the TAG_TYPE and echo in tag.py similar to how it works in workspace.py, but not a priority for this PR.

[lalver1]

I agree. Great, I'll create an issue to come back to this later.

[lalver1]

Thanks @angela-tran, that's a good point about the tests! I'm thinking about reusing these workflows:

• tests-ui
• tests-pytest
• tests-cypress
• check-migrations-and-messages

I don't think we need to run codeql and check-api 🤔. If this makes sense, I'll add on: workflow_call to those workflows that don't already have it, and will call them from deploy.yml using uses: before the deploy job.

Oh and one more question, I'm thinking about setting if: github.ref_type == 'tag' when calling these tests, since we already run them as part of the branch protection status checks when ref_type is branch and we probably don't want to run them again?

[angela-tran]

Thanks @angela-tran, that's a good point about the tests! I'm thinking about reusing these workflows:

• tests-ui
• tests-pytest
• tests-cypress
• check-migrations-and-messages

I don't think we need to run codeql and check-api 🤔. If this makes sense, I'll add on: workflow_call to those workflows that don't already have it, and will call them from deploy.yml using uses: before the deploy job.

That list looks good to me. And we'll want deploy to depend on the tests succeeding.

Oh and one more question, I'm thinking about setting if: github.ref_type == 'tag' when calling these tests, since we already run them as part of the branch protection status checks when ref_type is branch and we probably don't want to run them again?

Yep, that's definitely needed. eligibility-server does it too in its GitHub workflow.

[lalver1]

@angela-tran @thekaveman I added the tests to the deploy workflow and required them to successfully complete before the deploy job starts.

I did notice that eligibility-server has these lines in its docker-publish workflow

deploy:
    needs: test
    # !cancelled() is needed because if the whole workflow was cancelled, we don't want this job to run.
    # (github.ref_type != 'tag' || needs.test.result == 'success') is needed because if `test` did run, we only want this to run if `test` succeeded.
    if: (!cancelled() && (github.ref_type != 'tag' || needs.test.result == 'success'))

and I'm wondering if I should add if: (!cancelled() to the benefits deploy job since I guess we could manually want to cancel a deploy before it finishes running. I think the second part && (github.ref_type != 'tag' || needs.test.result == 'success') may not be needed because

needs:
      [tests-ui, tests-pytest, tests-cypress, check-migrations-and-messages]

covers this case?

[angela-tran]

I'm wondering if I should add if: (!cancelled() to the benefits deploy job since I guess we could manually want to cancel a deploy before it finishes running. I think the second part && (github.ref_type != 'tag' || needs.test.result == 'success') may not be needed because

needs:
      [tests-ui, tests-pytest, tests-cypress, check-migrations-and-messages]

covers this case?

Great catch @lalver1 -- yes, I think we should add if: (!cancelled()).

I took a closer look at that second part from eligibility-server, and I think you're right that it's not needed. GitHub docs on needs confirms that the jobs listed must complete successfully before the dependent job will run, so it would be redundant to include this condition. I think it's a remnant from an older version of the expression.

Long story short 😄, we don't need the second part here, and it could also be removed in eligibility-server.

[lalver1]

Thanks @angela-tran! I added if: (!cancelled()) to the deploy job and will make a ticket to remove the second part of the expression in eligibility-server; I think this one is ready for a review 🙂

[thekaveman]

I think this is ready to go 🎉