feat: automated releases via github action

[psychedelicious]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update
• Community Node Submission

Have you discussed this change with the InvokeAI team?

• Yes
• No, because:

Have you updated all relevant documentation?

• Yes
• No

Description

This PR introduces a new, hands-off release process, which is handled almost entirely by GitHub actions. The only part that is not yet in an action is creating the GitHub release itself, but there are some notes suggesting a path to that (shouldn't be too hard).

This PR was motivated by some hiccups we've seen during releases:

• Missing frontend builds
• Complicated build process, run locally and subject to platform-specific quirks
• PyPI release action that could result in a different wheel being published to PyPI than what is released in the installer

See docs/RELEASE.md for documentation.

---

feat: automated releases via github action

• Restructure & update code check workflows
• Add release workflow to handle checks/tests, build and publish to PyPI
• Add docs/RELEASE.md explaining the workflow & process
• create_installer.sh: Update to work with the release workflow
• create_installer.sh & tag_release.sh: Fix the ANSI escape codes for macOS
• tag_release.sh: Add check for python binary name
• tag_release.sh: Print git remote -v output
• tag_release.sh: Fix error when deleting nonexistant tags

QA Instructions, Screenshots, Recordings

This has been extensively tested on my fork and works great. Because the sensitive publish steps are protected in multiple ways, I think it's safe to merge and test on origin.

Merge Plan

This PR needs review from @lstein. I'd also like to get reviews from @ebr and @brandonrising .

I'll defer to @lstein for whether or not to try this new process out for 3.5.0 or wait for the next release.

We can add up to 6 contributors to the list of approvers for the pypi and testpypi environments. Probably:

• @lstein
• @Millu
• @hipsterusername
• @blessedcoolant
• little ol' me?

Added/updated tests?

• Yes
• No : No code changes here

[hipsterusername]

Awesome - 👏

[ebr]

Fantastic! 👏 This has been long overdue.
Left a few comments that are mostly nitpicks. There will probably be more kinks to work out in github actions once this is merged, but we won't know until the process gets some exercise.

[lstein]

Sorry, I've been working on the model installer pretty intensively over the past few days. Will give this a review on Thursday.

[lstein]

Looks like this has been picked over very carefully already. I scanned through and couldn't find anything that looked suspicious, so I'm giving it my go ahead. Impressive work!

[psychedelicious]

@lstein @hipsterusername I think this will need to be merged with the big red button bc it changes workflows.

And then the repo settings will need to be updated so that PRs require these three workflows to succeed:

• On change: run check-frontend
• On change: run check-python
• On change: run pytest

Otherwise this is good to go, and we can test it with a dev/alpha release (that we don't publish)

[hipsterusername]

this is great. going to say we hold off on this until after 3.6 is out

[hipsterusername]

Want to merge this but going to wait until we have a few folks ready to coordinate the other changes needed for this to succeed

[psychedelicious]

Yeah we should coordinate. I'd like to find a half hour to merge this and do a dev release to pypi on a call with @lstein. Just in case we need to do pypi surgery.

Just had a thought - does the updater only offer to update to RC versions? If we release a dev/nightly version to pypi will users be prompted to update?

Oooh. Nightlies :) that sounds cool.

[Millu]

Just had a thought - does the updater only offer to update to RC versions? If we release a dev/nightly version to pypi will users be prompted to update?

The updater right now only looks for RCs and the latest release, but could be easily updated for nightlies

[psychedelicious]

The updater logic currently only differentiates between RC and non-RC.

This means alpha, dev, and post releases are all considered non-RC releases, and if we do an alpha or dev release, a users running the updater at the right moment will see it as a stable release and download it.

We'll need to do something like this to split up the PyPI versions: https://gist.github.com/psychedelicious/d589c53284f88cad3ea57f320b21687c

[psychedelicious]

I've updated this branch.

Post-merge testing:
Testing:

• Manually dispatch the Release workflow. Confirm it builds a working wheel.
• Create a PR that changes frontend files and should fail a lint check.
• Create a PR that changes frontend files and should pass a lint check.
• Create a PR that changes python files and should fail a lint check.
  • It should also trigger the pytest workflow
• Create a PR that changes python files and should pass a lint check.
  • It should also trigger the pytest workflow
• Create a branch that tags a new release. Use the make tag-release command to tag the release accordingly. This should kick off the Release workflow, running all checks. It will pause before anything is published.
  • If all goes well, we can authorize only the testpypi publish step to publish the release to testpypi.
  • Test the testpypi release (instructions in RELEASE.md)

If all of these steps work correctly, theoretically we should be ready for a real release when the time comes.

[psychedelicious]

I've updated this PR to work with the recent changes to the install process.

[psychedelicious]

Superseded by #5839