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

Allow for automatic nightly release #149

Open
Yamakaky opened this issue Aug 16, 2021 · 8 comments
Open

Allow for automatic nightly release #149

Yamakaky opened this issue Aug 16, 2021 · 8 comments

Comments

@Yamakaky
Copy link

It would be nice to have an auto-update nightly release that follows a branch, like master. I think it requires that a tag is created/updated at each push.

See https://github.com/eine/tip for a working example.

@movermeyer
Copy link

movermeyer commented Oct 22, 2021

@Yamakaky I'm not sure what the request is?


When a release is published, if the tag doesn't yet exist, it will create it.
You can parameterize tag_name using the current date (for example).

Combined with on.schedule.cron, this solves the problem?

Roughly....

name: Daily releases

on:
  schedule:
    - cron: '0 1 * * *'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Compute the release tag
        run: |
          echo "release_tag=v`date '+%Y-%m-%d'`" >> $GITHUB_ENV
      - name: Create the release
        uses: softprops/action-gh-release@v1
        with:
          tag_name: ${{ env.release_tag }}
          target_commitish: main

@Yamakaky
Copy link
Author

I assume that means a release per day? I would like to have a permanent Nightly release based on master that contains the latest binaries.

@movermeyer
Copy link

I see. Interesting. I don't think GitHub itself has support for that kind of thing, so it seems unlikely that would be built into this action.

Disclaimer: I'm not a maintainer, just a random person who happened to be wandering by.


One semi-hacky workaround I could imagine is adding a step to the build that looks up releases by name, deletes the "Nightly" release by ID, then does the workflow I mentioned in the previous commit.

Something like:

name: Daily releases

on:
  schedule:
    - cron: '0 1 * * *'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Compute the release tag
        run: |
          echo "release_tag=v`date '+%Y-%m-%d'`" >> $GITHUB_ENV
      - name: Find the previous nightly build's ID
        run:  # TODO Actually implement, https://docs.github.com/en/rest/reference/repos#list-releases
      - name: Delete the previous nightly
        run: # TODO Actually implement, https://docs.github.com/en/rest/reference/repos#delete-a-release
      - name: Create the release
        uses: softprops/action-gh-release@v1
        with:
          name: Nightly
          tag_name: ${{ env.release_tag }}
          target_commitish: main

This would still create a new tag each day, unless you set draft: true, in which case the nightly release is always a draft (might be good enough for you).

@movermeyer
Copy link

movermeyer commented Oct 22, 2021

Actually, if you are able to keep it as a Draft release, you don't have to do anything special?

- name: Release
  uses: softprops/action-gh-release@v1
  with:
    draft: true
    name: Nightly
    target_commitish: main
    files: |
      release.zip

Seems to work fine with my test repo (the files are updated each time I run it)

@Yamakaky
Copy link
Author

But then only you can see drafts I think?

@movermeyer
Copy link

movermeyer commented Oct 23, 2021

You're right. TIL.

(I had always assumed that Drafts were meant to be used as pre-releases, but of course pre-releases are a separate thing)

So the best I think you can do is delete the previous nightly release each time, and deal with the daily tags that it would create.
I suppose you could add a step that finds the latest release, checks if there has been a change since that commit, and only makes the release if there has been?

Sorry that I don't have a better solution, but I'm also not sure that GitHub offers one.

@Hu1buerger
Copy link

Kinda similar to #171

@maxisam
Copy link

maxisam commented Feb 6, 2022

But isn't delete tag and create tag causing issue with git? People might have a conflict if they pull down tag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants