Automate Tern's release process

[rnjudge]

Describe the Feature When a new or patched release is cut, the Tern maintainers follow the steps outlined here. This is time consuming and limits the frequency that releases can be made available. Ideally, we would automate this process.

Use Cases Anytime we want to cut a release, having at least a portion of this process automated will save time and reduce errors.

Implementation Changes Write a script that takes the release notes and other relevant files or information as inputs and cuts a release. It may not be possible to fully automate this, but we the script should at least prepare all the necessary material for the maintainers to cut a release faster than the fully manual process we have now.

[coderpatros]

Heya, looking at the different parts of the release process.

Could "Update direct dependencies and run tests" be replaced with dependabot?

[coderpatros]

Hi @rnjudge, @nishakm might of mentioned I have a software engineering student doing a uni placement at the moment.

He is starting to look at this issue. We spent a bit of time reviewing the release checklist and I would appreciate feedback on the following as an approach.

• manage direct dependency updates separately to releases, using dependabot (runs tests automatically when the PR is raised)
• prepare release PR
  • manually triggered GitHub workflow, which does the following steps
  • creates a release notes file, next.md with section headings and relevant git log output
  • copy requirements.txt to docs/releases/next-requirements.txt
  • creates next branch and PR
• preparation of release notes
  • maintainer 1 completes release notes in the next PR branch
  • maintainer 2 reviews release notes, merges PR
• create and publish release
  • manually trigger GitHub workflow, version specified when triggering release, which does the following steps
  • rename next.md and next-requirements.txt to include version, create release commit
  • build package
  • install locally built package and run smoke tests
  • build docker image
  • run locally built docker image and run smoke tests
  • create GitHub release (which also tags the commit)
  • create Tern vendor tar and upload to GitHub release
  • upload package to GitHub release
  • publish package to PyPI
  • publish docker image to Docker Hub

[coderpatros]

@ReconPangolin I'll try to review what you've done in your fork tomorrow to provide some feedback before raising a draft PR here.

Can you have a look at what I've put above? I put some more thought into the steps required across the whole process. You could start working on the create and publish release steps next.

[ReconPangolin]

Thanks, I'll finish up step 2 to copy requirements across and then get started on automatically building the release.

[nishakm]

@coderpatros and @ReconPangolin, Thanks for taking this issue on! We have a release checklist: https://github.com/tern-tools/tern/blob/main/docs/releases/release_checklist.md. We have started a list of functional tests here: https://github.com/tern-tools/tern/blob/main/ci/release_tests.py. It should be enough to get you started, but if not, feel free to comment on this issue!

One issue we've found with dependabot is that it flags dependencies in the release freeze files located in the docs/releases folder. I don't think dependabot has the ability to work on just the top level requirements.txt file.

We use pip-tools to manage our dependencies. It's worked out pretty well! Details are in the release checklist.

[coderpatros]

Hi @nishakm, how are you executing the tests in release_tests.py?

[rnjudge]

@coderpatros The tests will be run with:

for t in tests:
    subprocess.check_output(t, shell=True)  # nosec

A lingering PR was just opened to make this change. Currently tests are run this way in ci/test_files_touched.py