Skip to content

Add commit hash output to GitHub Action #717

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
michael-pisman opened this issue Sep 21, 2023 · 9 comments
Open

Add commit hash output to GitHub Action #717

michael-pisman opened this issue Sep 21, 2023 · 9 comments
Labels
confirmed Prevent from becoming stale feature A new feature or a feature request good first issue a good start point for new contributors needs-update Needs status update from maintainers
Milestone
Improve GitHub Ac...

Comments

@michael-pisman
Copy link

michael-pisman commented Sep 21, 2023 •
edited
Loading

Description

Hi,

The issue is related to another popular GitHub Action actions/checkout which allows to checkout the repository. Unfortunately, when checking out the repository that triggered a workflow, this defaults to the reference or SHA for that event. This means, that the subsequent jobs in the workflow will not include the updates made with PSR action.

For example if we have a workflow with 3 jobs, the first to run PSR and release package to GitHub, the second job to build and release image to Docker Hub(the image should include updated package with changelog changes, new version file, etc from the job 1), and the third job to build and release package to PyPI(the built package should also include all of the updates from the job 1).
Here is an example of this workflow(with some non-important steps amended):

jobs:
  release:
    name: Release Package to GitHub
    outputs:
      released: ${{ steps.release.outputs.released }}
      version: ${{ steps.release.outputs.version }}
      tag: ${{ steps.release.outputs.tag }}
    steps:
      - id: release
        name: Python Semantic Release
        uses: python-semantic-release/python-semantic-release@master
  docker:
    name: Build and push Docker image
    needs: release
    steps:
    - name: Build and push
      uses: docker/build-push-action@v5
      with:
        push: true
        tags: username/image:${{ needs.release.outputs.version }}, username/image:latest
  pypi:
    name: Publish to PyPI
    needs: release
    steps:
    - name: Install dependencies
    - name: Download source code
      uses: actions/checkout@v3
    - name: Build package distributions
    - name: Publish package distributions to PyPI

The way GitHub actions works, the pypi and docker jobs will not include the commits made by release job. A simple git pull to HEAD reference, will pull those commits; However, such solution can also introduce a race condition, in case there were other commits made while the release job was running. More Info about this issue.

The correct solution would be for PSR GitHub Action to output the hash of the commit that has been made, which can be used in other jobs to pull the updates.

Use cases

Using separate jobs for updating version/releasing packages.

Possible implementation

Well, adding outputs would be easy(I assume), but I'm not sure how to get the commit hash after push, if someone can explain which function pushes the committed changes, I can try to work on the pull request.

Thank you
@michael-pisman michael-pisman added the feature A new feature or a feature request label Sep 21, 2023
@github-actions github-actions bot added the stale label Mar 25, 2024
@codejedi365 codejedi365 added confirmed Prevent from becoming stale and removed stale labels Mar 28, 2024
@codejedi365 codejedi365 mentioned this issue Mar 29, 2024
Open
@codejedi365 codejedi365 added this to the Improve GitHub Actions milestone Mar 30, 2024
@codejedi365 codejedi365 removed the confirmed Prevent from becoming stale label Mar 30, 2024
@codejedi365 codejedi365 added the good first issue a good start point for new contributors label May 23, 2024
@github-actions github-actions bot added the stale label Aug 22, 2024
@codejedi365 codejedi365 added confirmed Prevent from becoming stale and removed stale labels Aug 22, 2024
@wyardley
Copy link
Contributor

I can try and take a look at this. This should be done in https://github.com/python-semantic-release/python-semantic-release/blob/master/semantic_release/cli/github_actions_output.py vs. the shell entrypoint, right? @codejedi365 do you have a preference for the name the hash shows up as? commit_sha, and then use git.repo.head.object.hexsha to get the value?
FWIW, this seems like a useful thing to do, but I also think having subsequent workflows run off the tag thatpython-semantic-releasecuts should be relatively reliable and resistant to the issue mentioned? Similarly, since there is already atag` output, this could probably also be used (explicitly check out the tag from the output in the downstream workflows), even if you don't want to run the workflow separately off the cut tag.

(side note: one quirk I've found recently is that while the node semantic-release cuts releases with [skip ci] by default, and that works fine with CircleCI (doesn't prevent the jobs off the cut tag from running), Google Cloud Build and GitHub Actions won't run the job for the tag when the last commit in the tag has [skip ci] in it. This is kind of a weird corner case, since tags aren't associated with commits.)

@codejedi365
Copy link
Contributor

codejedi365 commented Aug 30, 2024 •
edited
Loading

I can try and take a look at this. This should be done in https://github.com/python-semantic-release/python-semantic-release/blob/master/semantic_release/cli/github_actions_output.py vs. the shell entrypoint, right?

Great! Yes, I think you can just extend the code that auto writes the variable file. That file is the object class where it is defined and modified (unfortunately not in the most standard way) inside of cli/commands/version.py. You could change it over to using property setters with validation to be more official.

@codejedi365 do you have a preference for the name the hash shows up as? commit_sha, and then use git.repo.head.object.hexsha to get the value?

That is a way to get the value but be aware it does perform git actions under the hood, no real preference on the name. You will need to consider probably a tag sha as well, as we do support --no-commit. We might already have the sha in one of our data objects that would not require git requests.

(side note: one quirk I've found recently is that while the node semantic-release cuts releases with [skip ci] by default, and that works fine with CircleCI (doesn't prevent the jobs off the cut tag from running), Google Cloud Build and GitHub Actions won't run the job for the tag when the last commit in the tag has [skip ci] in it. This is kind of a weird corner case, since tags aren't associated with commits.)

The default [skip ci] is discussed and confirmed as desired enhancement in another issue (#153, #973)

@github-actions GitHub Actions
Copy link

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

@github-actions github-actions bot added the needs-update Needs status update from maintainers label Oct 30, 2024
@codejedi365
Copy link
Contributor

Still in backlog

@github-actions github-actions bot removed the needs-update Needs status update from maintainers label Nov 15, 2024
@github-actions GitHub Actions
Copy link

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

@github-actions github-actions bot added the needs-update Needs status update from maintainers label Jan 15, 2025
@codejedi365
Copy link
Contributor

Still in backlog

@github-actions github-actions bot removed the needs-update Needs status update from maintainers label Jan 16, 2025
@github-actions GitHub Actions
Copy link

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

@github-actions github-actions bot added the needs-update Needs status update from maintainers label Mar 17, 2025
@codejedi365
Copy link
Contributor

Still in backlog

@github-actions github-actions bot removed the needs-update Needs status update from maintainers label Mar 18, 2025
@github-actions GitHub Actions
Copy link

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

@github-actions github-actions bot added the needs-update Needs status update from maintainers label May 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
confirmed Prevent from becoming stale feature A new feature or a feature request good first issue a good start point for new contributors needs-update Needs status update from maintainers
Projects
None yet
Milestone
Improve GitHub Actions
Development

No branches or pull requests
3 participants
@wyardley @codejedi365 @michael-pisman