actions/forgejo-release
2
1
Fork 4
Code Issues 4 Pull requests Actions Packages Projects Releases Wiki Activity

Release override results in jobs being created over and over again #9

New issue
Open
opened 2024-02-20 20:03:25 +00:00 by douglasparker · 12 comments
douglasparker commented 2024-02-20 20:03:25 +00:00
Copy link

PR #7 seems to result in jobs being created over and over again.

image

Example Workflow:

name: Release

on: [release]

env:
  RELEASE_PATH: /release
  WINDOWS_PATH: /discord-media-scrobbler_win-x64
  WINDOWS_ZIP: discord-media-scrobbler_win-x64.zip
jobs:
  upload-release:
    runs-on: debian-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup .NET Core
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Build Windows x64
        run: |
          apt-get update
          apt-get install zip -y
          dotnet publish -r win-x64
          mkdir -p "$WINDOWS_PATH" "$RELEASE_PATH"
          mv bin/Release/net8.0/win-x64/publish/* "$WINDOWS_PATH"
          cp lib/DiscordGameSDK/dll/x86_64/discord_game_sdk.dll "$WINDOWS_PATH"/discord_game_sdk.dll
          cp settings.template.json "$WINDOWS_PATH"/settings.json
          zip -r "$WINDOWS_ZIP" "$WINDOWS_PATH"
          mv "$WINDOWS_ZIP" "$RELEASE_PATH/$WINDOWS_ZIP"          

      - name: Release
        uses: actions/forgejo-release@v2
        with:
          direction: upload
          url: https://code.douglasparker.dev
          release-dir: "$RELEASE_PATH"
          override: true
          token: ${{ secrets.TOKEN }}
PR #7 seems to result in jobs being created over and over again. ![image](/attachments/0977efe4-349f-42a1-a916-506b1527e01b) Example Workflow: ```yaml name: Release on: [release] env: RELEASE_PATH: /release WINDOWS_PATH: /discord-media-scrobbler_win-x64 WINDOWS_ZIP: discord-media-scrobbler_win-x64.zip jobs: upload-release: runs-on: debian-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Setup .NET Core uses: actions/setup-dotnet@v4 with: dotnet-version: '8.0.x' - name: Build Windows x64 run: | apt-get update apt-get install zip -y dotnet publish -r win-x64 mkdir -p "$WINDOWS_PATH" "$RELEASE_PATH" mv bin/Release/net8.0/win-x64/publish/* "$WINDOWS_PATH" cp lib/DiscordGameSDK/dll/x86_64/discord_game_sdk.dll "$WINDOWS_PATH"/discord_game_sdk.dll cp settings.template.json "$WINDOWS_PATH"/settings.json zip -r "$WINDOWS_ZIP" "$WINDOWS_PATH" mv "$WINDOWS_ZIP" "$RELEASE_PATH/$WINDOWS_ZIP" - name: Release uses: actions/forgejo-release@v2 with: direction: upload url: https://code.douglasparker.dev release-dir: "$RELEASE_PATH" override: true token: ${{ secrets.TOKEN }} ```
image.png
4.1 KiB
douglasparker commented 2024-02-20 20:08:46 +00:00
Author
Copy link

Is there an easy way to clear the job queue until this is fixed?

Is there an easy way to clear the job queue until this is fixed?
earl-warren commented 2024-02-20 20:29:52 +00:00
Owner
Copy link

I would recommend stopping the runner. And then either manually cancel each of them. Or do that with a SQL update. There is no API yet to do the same.

I would recommend stopping the runner. And then either manually cancel each of them. Or do that with a SQL update. There is no API yet to do the same.
douglasparker commented 2024-02-20 20:30:45 +00:00
Author
Copy link

I would recommend stopping the runner. And then either manually cancel each of them. Or do that with a SQL update. There is no API yet to do the same.

Okay, sounds good!

> I would recommend stopping the runner. And then either manually cancel each of them. Or do that with a SQL update. There is no API yet to do the same. Okay, sounds good!
earl-warren commented 2024-02-20 20:32:32 +00:00
Owner
Copy link

It is very difficult (if at all possible?) to prevent infinite loops. In this case you seem to have a workflow triggered by the creation of a release and that workflow creates a release, which leads to an infinite loop. Or am I reading this incorrectly?

It is very difficult (if at all possible?) to prevent infinite loops. In this case you seem to have a workflow triggered by the creation of a release and that workflow creates a release, which leads to an infinite loop. Or am I reading this incorrectly?
douglasparker commented 2024-02-20 20:46:30 +00:00
Author
Copy link

It is very difficult (if at all possible?) to prevent infinite loops. In this case you seem to have a workflow triggered by the creation of a release and that workflow creates a release, which leads to an infinite loop. Or am I reading this incorrectly?

That is correct. I create a release and the idea was that this workflow would overwrite the release with release artifacts. Which is why I opened issue #8 to make this experience a little better.

Is there another workflow that I can run that only uploads release artifacts to forgejo releases?

> It is very difficult (if at all possible?) to prevent infinite loops. In this case you seem to have a workflow triggered by the creation of a release and that workflow creates a release, which leads to an infinite loop. Or am I reading this incorrectly? That is correct. I create a release and the idea was that this workflow would overwrite the release with release artifacts. Which is why I opened issue #8 to make this experience a little better. Is there another workflow that I can run that only uploads release artifacts to forgejo releases?
earl-warren commented 2024-02-20 21:00:50 +00:00
Owner
Copy link

What about using the workflow you have with

on:
  push:
    tags: 'v*'

instead? forgejo-release will create the release for this tag but will not recreate the tag. You don't need to override then.

What about using the workflow you have with ```yaml on: push: tags: 'v*' ``` instead? `forgejo-release` will create the release for this tag but will **not** recreate the tag. You don't need to override then.
douglasparker commented 2024-02-20 21:20:55 +00:00
Author
Copy link

What about using the workflow you have with

on:
  push:
    tags: 'v*'

instead? forgejo-release will create the release for this tag but will not recreate the tag. You don't need to override then.

That should work for now. It just means that I have to create a tag and edit releases after for manual release notes.

> What about using the workflow you have with > > ```yaml > on: > push: > tags: 'v*' > ``` > > instead? `forgejo-release` will create the release for this tag but will **not** recreate the tag. You don't need to override then. That should work for now. It just means that I have to create a tag and edit releases after for manual release notes.
earl-warren commented 2024-02-20 21:48:01 +00:00
Owner
Copy link

Creating a tag is a good way to say: "I want a release on that commit". You could also have a step before forgejo-release that extracts the release notes from a file in the repo if that's easier than doing it manually afterwards.

Creating a tag is a good way to say: "I want a release on that commit". You could also have a step before `forgejo-release` that extracts the release notes from a file in the repo if that's easier than doing it manually afterwards.
❤️ 1
douglasparker commented 2024-02-20 21:50:25 +00:00
Author
Copy link

Creating a tag is a good way to say: "I want a release on that commit". You could also have a step before forgejo-release that extracts the release notes from a file in the repo if that's easier than doing it manually afterwards.

That’s actually a great compromise. A changelog.md will ensure I have a portable version of release notes!

> Creating a tag is a good way to say: "I want a release on that commit". You could also have a step before `forgejo-release` that extracts the release notes from a file in the repo if that's easier than doing it manually afterwards. That’s actually a great compromise. A changelog.md will ensure I have a portable version of release notes!
douglasparker commented 2024-02-21 01:05:35 +00:00
Author
Copy link

I'm not sure why, but it turns out it's been creating a new release over and over again for a while now after I cleaned it up the first time.

Is actions/forgejo-release@v2 bugged?

name: Release

on:
  push:
    tags: ["*"]

env:
  RELEASE_PATH: /release
  WINDOWS_PATH: /discord-media-scrobbler_win-x64
  WINDOWS_ZIP: discord-media-scrobbler_win-x64.zip

jobs:
  upload-release:
    runs-on: debian-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup .NET Core
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Build Windows x64
        run: |
          apt-get update
          apt-get install zip -y
          dotnet publish -r win-x64
          mkdir -p "$WINDOWS_PATH" "$RELEASE_PATH"
          mv bin/Release/net8.0/win-x64/publish/* "$WINDOWS_PATH"
          cp lib/DiscordGameSDK/dll/x86_64/discord_game_sdk.dll "$WINDOWS_PATH"/discord_game_sdk.dll
          cp settings.template.json "$WINDOWS_PATH"/settings.json
          zip -r "$WINDOWS_ZIP" "$WINDOWS_PATH"
          mv "$WINDOWS_ZIP" "$RELEASE_PATH/$WINDOWS_ZIP"                    

      - name: Release
        uses: actions/forgejo-release@v2
        with:
          direction: upload
          url: https://code.douglasparker.dev
          release-dir: "$RELEASE_PATH"
          token: ${{ secrets.TOKEN }}
          prerelease: ${{ contains(github.ref, '-') }}
I'm not sure why, but it turns out it's been creating a new release over and over again for a while now after I cleaned it up the first time. Is `actions/forgejo-release@v2` bugged? ```yaml name: Release on: push: tags: ["*"] env: RELEASE_PATH: /release WINDOWS_PATH: /discord-media-scrobbler_win-x64 WINDOWS_ZIP: discord-media-scrobbler_win-x64.zip jobs: upload-release: runs-on: debian-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Setup .NET Core uses: actions/setup-dotnet@v4 with: dotnet-version: '8.0.x' - name: Build Windows x64 run: | apt-get update apt-get install zip -y dotnet publish -r win-x64 mkdir -p "$WINDOWS_PATH" "$RELEASE_PATH" mv bin/Release/net8.0/win-x64/publish/* "$WINDOWS_PATH" cp lib/DiscordGameSDK/dll/x86_64/discord_game_sdk.dll "$WINDOWS_PATH"/discord_game_sdk.dll cp settings.template.json "$WINDOWS_PATH"/settings.json zip -r "$WINDOWS_ZIP" "$WINDOWS_PATH" mv "$WINDOWS_ZIP" "$RELEASE_PATH/$WINDOWS_ZIP" - name: Release uses: actions/forgejo-release@v2 with: direction: upload url: https://code.douglasparker.dev release-dir: "$RELEASE_PATH" token: ${{ secrets.TOKEN }} prerelease: ${{ contains(github.ref, '-') }} ```
douglasparker commented 2024-02-21 01:15:42 +00:00
Author
Copy link

Turns out it's from the older commits? I stopped the runner and migrated to a new repo, so not sure how they picked up these jobs again. Was it maybe from migrating releases? Ugh... lol.

Turns out it's from the older commits? I stopped the runner and migrated to a new repo, so not sure how they picked up these jobs again. Was it maybe from migrating releases? Ugh... lol.
douglasparker commented 2024-02-21 02:35:29 +00:00
Author
Copy link

Okay, so I guess after making a new repository, deleting the old, and then renaming the new one to the old one; the runner had a bunch of jobs queued up again after starting it back up.

I wrote a quick and dirty tamper monkey script to click cancel on the several hundred pending jobs in queue.

This seems to have cleared it all up!

However, there has got to be a way to prevent a loop like this- and if it's not possible a clear all jobs button would be incredibly useful.

Okay, so I guess after making a new repository, deleting the old, and then renaming the new one to the old one; the runner had a bunch of jobs queued up again after starting it back up. I wrote a quick and dirty tamper monkey script to click cancel on the several hundred pending jobs in queue. This seems to have cleared it all up! However, there has got to be a way to prevent a loop like this- and if it's not possible a clear all jobs button would be incredibly useful.
👍 1
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v2
v1
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: actions/forgejo-release#9
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?