Skip to content
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.

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

Tag as parameter #10

Closed
victoraugustolls opened this issue Feb 7, 2020 · 1 comment · Fixed by #11
Closed

Tag as parameter #10

victoraugustolls opened this issue Feb 7, 2020 · 1 comment · Fixed by #11
Assignees
Labels
enhancement New feature or request v3 Release v3.x.x

Comments

@victoraugustolls
Copy link

victoraugustolls commented Feb 7, 2020

Description:

Would it be possible to pass the tag as a parameter? As github actions can't be chained. So if I have an action that create a tag, this tag could be used to read the changelog and create the release.

Also, giving the release name a prefix like: Release {tag} would be nice!

Reference:

Screenshots:

@anton-yurchenko
Copy link
Owner

Hello @victoraugustolls and thank you for that feature request!

There are multiple questions here, so lets split them:

Pass the tag as a parameter

Unfortunately, arguments are used for passing the release artifacts only.

GitHub actions can't be chained

This is true, though I do not think that each action should workaround that but the solution should come from GitHub itself.
There are multiple posts on GitHub Community about that and I believe it will be addressed. It is a common ability to trigger flow from another flow on any CI system.

"Provide string instead of Git Tag so" it could be used to read the changelog and create the Release

Git Tag is required by design as a part of the validation, building current commit and uploading the artifacts, SemVer matching,...

I believe if you'd be able to trigger another workflow it will solve all your problems here 😉

P.S: maybe this may help?

Although, Release Title manipulation is a good idea and will be implemented in a coming release 🎉

There will be 3 new env.vars to adjust default behavior:

  • RELEASE_NAME: Full release name. For example: First Release
  • RELEASE_NAME_PREFIX: Prefix which will be added before the version tag. For example: Release: 3.1.2.
  • RELEASE_NAME_POSTFIX: Postfix which will be added after the version tag. For example: 3.1.2-rc1 (auto-build).

Of course, you might provide both prefix and postfix (name may not be combined with them) to create something like Release: 3.1.2 (codename 'Cobra')

It is possible to pass data between steps inside a workflow using environmental variables inside a workflow.
Here is an example workflow (I used run, but it may also be another Action):

name: release

on:
  push:
    tags:
      - "*"

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v1

      - run: |
          export TEXT="Release: "
          echo "::set-env name=RELEASE_NAME_PREFIX::$TEXT"

      - name: Release
        uses: docker://antonyurchenko/git-release:latest
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          DRAFT_RELEASE: "false"
          PRE_RELEASE: "true"
          CHANGELOG_FILE: "CHANGELOG.md"
          ALLOW_EMPTY_CHANGELOG: "false"
          ALLOW_TAG_PREFIX: "true"
        with:
          args: |
            file1.zip
            file2.zip

@anton-yurchenko anton-yurchenko mentioned this issue Feb 17, 2020
@anton-yurchenko anton-yurchenko linked a pull request Feb 17, 2020 that will close this issue
@anton-yurchenko anton-yurchenko added the v3 Release v3.x.x label Mar 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request v3 Release v3.x.x
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants