GitHub Releases vs. Deployment: Clarifying `softprops/action-gh-release` for Better Workflow Practices

In the fast-paced world of software development, efficient and well-documented deployment processes are crucial for team productivity and successful rollbacks. A recent discussion in the GitHub Community highlighted a common point of confusion: the role of softprops/action-gh-release in a deployment workflow and its interaction with server directories. This insight clarifies the distinction between creating a GitHub Release and deploying an application, offering a path to more robust practices that can directly support your development OKR examples focused on release quality and deployment efficiency.

The Challenge: Old Habits Die Hard

Rod-at-DOH initiated the discussion, describing an entrenched, manual deployment habit within his team. Their process involved creating dated backup folders, moving existing code, and then publishing new code into a "current" folder using Visual Studio. This led to a proliferation of ambiguously named folders (e.g., "2026-427 rf"), making rollbacks a nightmare, often requiring developers to sift through dozens of iterations to find a working version.

Rod recognized the superior documentation capabilities of GitHub's Release functionality, where releases can be clearly described, and sought to integrate softprops/action-gh-release into their GitHub Workflow. His primary concern was whether this action would inadvertently delete the existing "current" folder and the numerous backup directories on their self-hosted Windows runner.

Rod-at-DOH's Workflow Snippet:

- name: Run Action-GH-Release
  uses: softprops/action-gh-release@v2
  with:
    tag_name: v${{ steps.tagger.outputs.version }}
    name: Release v${{ steps.tagger.outputs.version }}
    body: ${{ github.event.pull_request.body }}

Clarifying `softprops/action-gh-release`: Release vs. Deployment

The short answer, provided by community member Gitious, was a resounding no. The softprops/action-gh-release action does not deploy to a directory on your runner or wipe out any folders. This is a critical distinction often missed by developers transitioning to GitHub Actions for deployments.

Gitious explained that the action's sole purpose is to:

• Create a GitHub Release on github.com under your repository's "Releases" tab.
• Use the provided tag_name, name, and body for documentation.
• Optionally, upload specified files (e.g., compiled binaries, zip archives) from your workflow workspace as release assets.
• Create the corresponding Git tag if it doesn't already exist.

Crucially, this action operates entirely within the GitHub ecosystem and the workflow's temporary workspace. It has no concept of, nor does it interact with, your server's "current" folder or any other directories outside its immediate operational scope.

Adopting a Superior Deployment Pattern

The confusion often stems from conflating "GitHub Release" with "web app deployment." They are distinct steps in a modern CI/CD pipeline. A superior pattern, which can significantly improve your development OKR examples related to deployment reliability and rollback speed, involves:

1. Build the Application: Compile and package your application (e.g., dotnet publish) into a dedicated publish folder within your workflow workspace.
2. Create a GitHub Release: Use softprops/action-gh-release to create a documented release, attaching the packaged application (often zipped) as a downloadable asset. This step is for documentation and artifact storage.
3. Deploy the Application: Implement a separate deployment step (e.g., using robocopy, msdeploy, or an IIS-specific action) to copy the packaged application from the workflow workspace to your server's target directory (e.g., the "current" folder). This is the step that actually touches your server's filesystem.

This pattern vastly improves the rollback story. Instead of guessing which dated folder is correct, developers can simply browse GitHub Releases, identify the desired version by its clear name and description, download the associated artifact, and use the deployment step to push that specific version to "current."

Practical Considerations:

• Ensure your workflow has permissions: contents: write on the job so the action can create releases and push tags.
• To make your releases useful for rollback, always include a files: input in softprops/action-gh-release, pointing to your build artifact. Otherwise, the release will be created without any downloadable assets.

By clearly separating release creation from actual deployment, teams can achieve greater clarity, enable faster and more reliable rollbacks, and foster better documentation—all vital components for hitting ambitious development OKR examples and enhancing overall developer productivity.