Tag and release on a specific commitish #32

fleskesvor · 2019-12-29T08:23:41Z

Solves #31

fleskesvor · 2019-12-29T08:42:08Z

I didn't realize there's already #19, which also fixes this issue, though that hasn't been updated in well over a month. Additionally, I think it's a more sane default to use context.sha for the target_commitish, as my PR does.

Alternatively, one could set commitish: ${{ github.sha }} in an actions workflow, but I think it's more intuitive that the tag+release is created on the currently checked out commit.

davelosert · 2020-01-11T09:48:09Z

I agree with @fleskesvor that this PR should be merged over #19 . Using the current branch / sha as the default commitish is more intuitive and what I'd expect.

hiranya911 · 2020-01-17T22:29:19Z

Much needed feature.

matklad · 2020-01-29T12:40:46Z

Just so that folks can copy-paste this without going through the docs:

replace:

        uses: actions/create-release@v1

with

        # https://github.com/actions/create-release/pull/32
        uses: fleskesvor/create-release@1a72e235c178bf2ae6c51a8ae36febc24568c5fe

if you want to use this fixed version of the action.

fleskesvor · 2020-01-29T13:54:56Z

        # https://github.com/actions/create-release/pull/32
        uses: fleskesvor/create-release@1a72e235c178bf2ae6c51a8ae36febc24568c5fe

if you want to use this fixed version of the action.

Thanks. 🙂 Alternatively, fleskesvor/create-release@feature/support-target-commitish is also a valid reference, which will keep pointing to the head of my branch if any changes are added.

I'm a bit surprised (and slightly disappointed) that this PR hasn't received any feedback from the maintainers after a whole month.

eine · 2020-01-29T14:14:49Z

@fleskesvor, I'm afraid that there is no maintainer for this repo in GitHub's internal structure. As commented in #6 (comment), this was a side project that was released in this organisation (because GitHub didn't manage to provide an oficial solution on time for the release of the product last Nov).

Fortunately, they seem to be working hard in the (non open-source) background, to extend GitHub's API so that, hopefully, better Actions can be written in the future. They are also improving the visualisation of e.g. Artifacts, which might be a valid alternative for users willing to use this action to release nightly builds.

Unfortunately, it might take long until some manager finds out that giving write access to a bunch of employees without assigning any responsability is not going to work. We need someone to take the lead. That might well be an external contributor.

fleskesvor · 2020-01-29T14:25:47Z

@eine Oh, I see. That's unfortunate for the time being, but hopefully a better solution will come along soon. It might be difficult to get external contributors to take on that responsibility too, since a small Javascript application for a proprietary service might not be the most exciting thing to be spending time on.

eine · 2020-01-29T14:32:13Z

@fleskesvor, I agree. Ideally GitHub would make it explicit that this is still a beta de facto and it is going to be pretty limited feature-wise and in regard to human resources for a few months yet. That would make it much easier for us users not to feel continuously disappointed and frustrated. However, I'm neither a manager nor a marketing guy...

fleskesvor · 2020-03-06T07:01:37Z

@IAmHughes Any input in this? It's a tiny change, but one we need in an increasing number of repos in my organization. Even Firebase uses my fork in several of their repos.

DocX · 2020-04-29T08:23:38Z

src/create-release.js

@@ -18,6 +18,7 @@ async function run() {
    const body = core.getInput('body', { required: false });
    const draft = core.getInput('draft', { required: false }) === 'true';
    const prerelease = core.getInput('prerelease', { required: false }) === 'true';
+    const commitish = core.getInput('commitish', { required: false }) || context.sha;


To make it behave same without the input value as it behaved before this change - i.e. just let the git API use it's default:

Suggested change

const commitish = core.getInput('commitish', { required: false }) || context.sha;

const commitish = core.getInput('commitish', { required: false });

Yes, that is an option, but I don't think it's what most users of this action would expect. My suggested change doesn't inconvenience hobbyists who only commit and build on master, since context.sha will still resolve to head of master in those cases, but it also doesn't confuse more advanced users who build on multiple branches, since it will release on the head of those actual branches, and not a totally different branch.

As I wrote on #31:

After looking into the code, I realized that the issue is that this action calls octokit.repos.createRelease() without a target_commitish, which makes the API default to the repository's default branch (usually master). I created #32 to set target_commitish with what I think is a more reasonable default in the context of a CI workflow.

So yeah, I'm a bit reluctant to make that change, but still, being able to actually set a commitish is better than the current situation.

@fleskesvor, you are 100% correct.

Correct me if I'm wrong, context.sha is the same as repository's github.sha? If so, I don't see any problem with that since github.sha uses long commit-sha afaik.

sebastian-toepfer · 2020-04-30T19:06:34Z

unsure, but this function doesn't work for us and we are not understand why.
this is how we try it:

        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ env.version }}
          release_name: Release ${{ env.version }}
          commitish: ${{ env.commitish }}
          draft: false
          prerelease: false

in env.commitish we wrote the current sha after change the version number. release-action runs shortly after we push this change back to github.
with this configuration we get allways:
##[error]Validation Failed

enable debug for action doesn't showes more.

fleskesvor · 2020-05-08T14:23:35Z

@sebastian-toepfer That looks like it should work. If debug doesn't turn up any clues, you could try to print those variables in a throwaway step to see if they are what you except them to be, eg.:

- run: |
    echo "version: ${VERSION}"
    echo "commitish: ${COMMITISH}"
  env:
    VERSION: ${{ env.version }}
    COMMITISH: ${{ env.commitish }}

kvmw · 2020-05-08T14:28:26Z

@sebastian-toepfer That looks like it should work. If debug doesn't turn up any clues, you could try to print those variables in a throwaway step to see if they are what you except them to be, eg.:
- run: |
    echo "version: ${VERSION}"
    echo "commitish: ${COMMITISH}"
  env:
    VERSION: ${{ env.version }}
    COMMITISH: ${{ env.commitish }}

@sebastian-toepfer @fleskesvor, I just had a similar issue. using the long commit-sha worked for me. but using the short hash ( 7 chars) results to same error: ##[error]Validation Faile

sebastian-toepfer · 2020-05-08T14:31:57Z

@fleskesvor: have replace sha with branch name it works like a charm now.
Output of a failed run with sha:

Run fleskesvor/create-release@feature/support-target-commitish
  with:
    tag_name: 2020.6
    release_name: Release 2020.6
    commitish: 7251f69f
    draft: false
    prerelease: false
  env:
    version: 2020.6
    commitish: 7251f69f
    default_branch: develop
    GITHUB_TOKEN: ***
##[error]Validation Failed

see no issue :(
sha exists in repo

RadWolfie · 2020-05-14T23:19:24Z

I just had a similar issue. using the long commit-sha worked for me. but using the short hash ( 7 chars) results to same error: ##[error]Validation Failed

@pivotal-kaveh @sebastian-toepfer, perhaps GitHub's releases API doesn't support shorter commit-sha.

hiranya911 · 2020-05-20T19:06:55Z

Any plans on getting this merged? I noticed that a v1.1.0 of this Action was release a few days ago. Would be great if we can get this included for the next release.

ambvdijk · 2020-06-10T10:07:30Z

Would really like this pull-request to be merged!

mscoutermarsh

Thank you @fleskesvor!

And thank you everyone for your patience here. Was recently made aware of this PR. Sorry for the long delay.

mscoutermarsh · 2020-06-16T19:42:34Z

This is now included in v1.1.1 https://github.com/actions/create-release/releases.

If you all could use it and share if you have any issues. We can point v1 to the new tag after we gain some confidence and there are no issues.

aviflax · 2020-06-17T02:03:43Z

I was able to use this new feature successfully via v1.1.1 in a PR I opened today. I found it a little fiddly, but I think that’s actually mostly due to how many different ways there are to access commit-ish things in the context of a workflow/job execution. At one point I think I may have given it a bare branch name and seen it fail, but I’m not 100% sure.

One tricky thing that we might want to document is that if one uses this action in a job that’s triggered by a pull_request event and does not specify a value for commitish then the tag that’s created will be for a merge commit that’s related to the PR somehow but isn’t actually in the PR… I don’t fully understand what I was seeing but it was pretty weird.

Regardless of that all, this is now working for me and I’m relieved. Thank you @fleskesvor and @mscoutermarsh!

RadWolfie · 2020-06-18T10:37:29Z

One tricky thing that we might want to document is that if one uses this action in a job that’s triggered by a pull_request event and does not specify a value for commitish then the tag that’s created will be for a merge commit that’s related to the PR somehow but isn’t actually in the PR… I don’t fully understand what I was seeing but it was pretty weird.

Every pull request build is base on last known of "latest HEAD" branch with a "merge" commit. This is how continuous integration handle to verify if the pull request is able to build. You will be able to copy exact commit into your repository's url link after commit/commits path. Then see which commit was used from the branch's commits was built from. However, it's not relative to this pull request. P.S. Creating a release shouldn't happen during active pull request, only on merged, aka pushed. 😉 Cheers!

fleskesvor added 2 commits December 29, 2019 09:06

Tag and release on a specific commitish

2b67105

Add target_commitish to tests

1a72e23

fleskesvor mentioned this pull request Dec 29, 2019

Tags point at wrong commit #31

Closed

davelosert mentioned this pull request Jan 11, 2020

Target commitish #19

Closed

mjansrud mentioned this pull request Feb 19, 2020

IV-518: Release checkout branch i stedet for master navikt/nav-enonicxp#254

Merged

eneskaya previously approved these changes Apr 2, 2020

View reviewed changes

aldenquimby mentioned this pull request Apr 27, 2020

Add support for target_commitish input field #59

Closed

DocX reviewed Apr 29, 2020

View reviewed changes

Merge branch 'master' into feature/support-target-commitish

62b2b83

mscoutermarsh dismissed eneskaya’s stale review via 62b2b83 June 16, 2020 19:22

mscoutermarsh approved these changes Jun 16, 2020

View reviewed changes

mscoutermarsh merged commit e9dc4ac into actions:master Jun 16, 2020

eine mentioned this pull request Aug 15, 2020

Who are the maintainer of this Action and is this Action still maintained? actions/upload-release-asset#58

Open

dependabot bot mentioned this pull request Mar 12, 2021

Bump actions/create-release from v1.0.0 to v1.1.4 dataswift/gha-trivy#3

Merged

gnoeou mentioned this pull request Apr 7, 2021

Add support for commitish to target specific commit zendesk/action-create-release#10

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tag and release on a specific commitish #32

Tag and release on a specific commitish #32

fleskesvor commented Dec 29, 2019

fleskesvor commented Dec 29, 2019

davelosert commented Jan 11, 2020

hiranya911 commented Jan 17, 2020

matklad commented Jan 29, 2020

fleskesvor commented Jan 29, 2020

eine commented Jan 29, 2020

fleskesvor commented Jan 29, 2020

eine commented Jan 29, 2020 •

edited

Loading

fleskesvor commented Mar 6, 2020

DocX Apr 29, 2020

fleskesvor Apr 30, 2020

RadWolfie May 14, 2020

sebastian-toepfer commented Apr 30, 2020

fleskesvor commented May 8, 2020

kvmw commented May 8, 2020 •

edited

Loading

sebastian-toepfer commented May 8, 2020 •

edited

Loading

RadWolfie commented May 14, 2020 •

edited

Loading

hiranya911 commented May 20, 2020

ambvdijk commented Jun 10, 2020

mscoutermarsh left a comment

mscoutermarsh commented Jun 16, 2020 •

edited

Loading

aviflax commented Jun 17, 2020

RadWolfie commented Jun 18, 2020 •

edited

Loading

	const commitish = core.getInput('commitish', { required: false }) \|\| context.sha;
	const commitish = core.getInput('commitish', { required: false });

Tag and release on a specific commitish #32

Tag and release on a specific commitish #32

Conversation

fleskesvor commented Dec 29, 2019

fleskesvor commented Dec 29, 2019

davelosert commented Jan 11, 2020

hiranya911 commented Jan 17, 2020

matklad commented Jan 29, 2020

fleskesvor commented Jan 29, 2020

eine commented Jan 29, 2020

fleskesvor commented Jan 29, 2020

eine commented Jan 29, 2020 • edited Loading

fleskesvor commented Mar 6, 2020

DocX Apr 29, 2020

Choose a reason for hiding this comment

fleskesvor Apr 30, 2020

Choose a reason for hiding this comment

RadWolfie May 14, 2020

Choose a reason for hiding this comment

sebastian-toepfer commented Apr 30, 2020

fleskesvor commented May 8, 2020

kvmw commented May 8, 2020 • edited Loading

sebastian-toepfer commented May 8, 2020 • edited Loading

RadWolfie commented May 14, 2020 • edited Loading

hiranya911 commented May 20, 2020

ambvdijk commented Jun 10, 2020

mscoutermarsh left a comment

Choose a reason for hiding this comment

mscoutermarsh commented Jun 16, 2020 • edited Loading

aviflax commented Jun 17, 2020

RadWolfie commented Jun 18, 2020 • edited Loading

eine commented Jan 29, 2020 •

edited

Loading

kvmw commented May 8, 2020 •

edited

Loading

sebastian-toepfer commented May 8, 2020 •

edited

Loading

RadWolfie commented May 14, 2020 •

edited

Loading

mscoutermarsh commented Jun 16, 2020 •

edited

Loading

RadWolfie commented Jun 18, 2020 •

edited

Loading