What does "deploy" mean, for this Action?

[solvaholic]

In https://github.com/solvaholic/octodns-sync/issues/41#issuecomment-792223562 @xt0rted explained:

I'm doing branch deploys, so once the plan looks good in the PR I'm deploying the PR branch, verifying the changes, then merging the PR to main. If I need to revert my changes I can do another deploy of the main branch and hopefully get back to where I started before the PR was opened.

That approach makes a lot of sense to me when the repository is code for an application. Like for GitHub.com, or when the repo is a Docker Compose stack, or any cloud-hosted service, or DNS or other service configurations. You can deploy from any commit to different environments including production. It doesn't matter whether the commit is in main or another branch.

solvaholic/octodns-sync is a GitHub Action that will run octodns-sync from octodns/octodns to test and deploy DNS configuration stored in a repository on GitHub.com.

What does "deploy" mean, for this Action? Or, I think, for any GitHub Action?

[solvaholic]

Braindumping here as I consider the question. Please comment to share your thoughts as well :bow:

What does "deploy" mean, for this Action?

Just now I think these things are true related to that question:

• A GitHub Action is available to use like so, based on any Git ref or commit SHA:

  # Reference a specific commit
  - uses: actions/setup-node@c46424eee26de4078d34105d3de3cc4992202b1e
  # Reference the major version of a release
  - uses: actions/setup-node@v1
  # Reference a minor version of a release
  - uses: actions/setup-node@v1.2
  # Reference a branch
  - uses: actions/setup-node@main

• A release in the Action's repository can be published to the Marketplace

From there I think whereas an application may be deployed to, like, test and production environments, every commit pushed to an Action's repository is implicitly deployed, it's always available for use.

So maybe: An Action can be deployed to the Marketplace by ticking that box on a release and publishing it. It can be deployed to @main by merging the commit to the main branch. And its commits and refs are all implicitly deployed as, say, unreleased versions.

Then, I think, when deploying this Action to @main I'd want to ensure:

• Existing/previous usage still works as-expected (no breaking changes)
• Everything, including new features, works as-documented
• The changelog describes significant changes since the latest Marketplace release
• The readme is up-to-date and correct

In addition to those, when deploying to Marketplace I'd want to ensure:

• Release notes and changelog are in sync
• Major and minor version tags correctly point to their latest patch release

And: Since any GitHub user can deploy modifications by opening a pull request (which will be available at the PR head's commit SHA) I'm uninterested in maintaining criteria or requirements for that scenario. There's just "available", "ready for main", and "ready for Marketplace".

[xt0rted]

I have this action running on every PR and commenting on it with any detected changes. I was then triggering deployments using the slack integration, but the latest version removed support for this so yesterday I setup a new workflow that triggers deployments when an admin comments with /deploy on the PR. From there my existing workflow runs and applies the changes to my production environment.

Here's a copy of my current workflow https://gist.github.com/xt0rted/a0ef1d3739cc333f8e3461532697d2ba

For my own actions I treat anything in main as pending release, though this is partially due to using typescript and not committing the /dist folder. Then when I release a new version I merge main into releases/v1, run my build & package scripts, commit any changes, tag it with the v1.1.1 version, move the v1 tag to this sha, and then create a release for the full version tag and copy the changelog contents into it.

My process for releasing is manual right now, but I have a checklist I follow each time I do it so I don't miss something. At some point I'd like to automate some of this.

[solvaholic]

Thank you for explaining, and for sharing a copy of your workflow @xt0rted :bow:

In considering what "deploy" means for this Action I'd overlooked that for other Actions it likely takes more steps to get from "it's in the repository" to "it's available for use" or "it's a shipped release".