Existing releases are no longer updated

[debdutdeb]

I currently use a matrix to generate jobs, each has the same payload just different file when creating a release.

https://github.com/debdutdeb/novm/blob/cf13d8741fee6959d72dd8bae05cdb5750ca30e9/.github/workflows/release.yaml#L20-L44

This used to just update the existing release with the new files (adding one by one as they are built), noticed recently, that isn't the case anymore. I've been getting Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"}

Looking at the changes, I think the problem lies in https://github.com/softprops/action-gh-release/pull/386 although don't know exactly what, likely octokit is adding something more to the request causing this to fail. Or more likely doing some pre-flight checks like "does the tag exist?".

Trying the commit right before this one, seems to have helped my workflow to work again.

commit your commit workflow result

[brandongottesman-taulia]

We're also running into this issue after upgrading to v2.

[manuelkienlein]

We have the same issue. Both v1 and v2 do not work anymore.

[lpil]

We are having this problem now, so with each release I have to manually download all the assets from 5 releases, delete them, and upload them all to a 6th, which is quite annoying.

[andrew121410]

Yeah same issue, surprised this still has yet to be fixed.

[lpil]

Does anyone know another action which can replace this one? Now that this one no longer works and seems to be unmaintained or slowly maintained.

[manuelkienlein]

I found a solution that worked for me. While I’m not entirely sure if it's directly related to this issue, it might be helpful.

The action was functioning well before, but after an update, I encountered the error: "Pattern * does not match any files," similar to the issue in #414. As a result, no files were uploaded.

After extensive searching, I discovered that the paths I had specified in the action were directories instead of files. (I used ls -l for debugging, as in #79)

Now, I use the following step to upload all files from my build folder, and it works perfectly:

      - name: "Upload Release"
        uses: softprops/action-gh-release@v2
        if: startsWith(github.ref, 'refs/tags/')
        with:
          files: |
            build/*

I hope this helps you as well.

[smallprogram]

When used in a matrix, uploading files with different names to the same tag will only work properly in a few cases, and most of the time it will report an error.

⚠️ Unexpected error fetching GitHub release for tag refs/heads/test: HttpError: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} - https://docs.github.com/rest/releases/releases#update-a-release
Error: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} - https://docs.github.com/rest/releases/releases#update-a-release

[lincolnthalles]

When used in a matrix, uploading files with different names to the same tag will only work properly in a few cases, and most of the time it will report an error.

⚠️ Unexpected error fetching GitHub release for tag refs/heads/test: HttpError: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} - https://docs.github.com/rest/releases/releases#update-a-release
Error: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} - https://docs.github.com/rest/releases/releases#update-a-release

Setting the job strategy.max-parallel to 1 prevents this issue, at the expense of longer build times.

It looks like a race condition on the GitHub side if the same release is being created at the same time by different jobs.

The action should wait a little and retry in this specific error.

[smallprogram]

When used in a matrix, uploading files with different names to the same tag will only work properly in a few cases, and most of the time it will report an error.

⚠️ Unexpected error fetching GitHub release for tag refs/heads/test: HttpError: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} - https://docs.github.com/rest/releases/releases#update-a-release
Error: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} - https://docs.github.com/rest/releases/releases#update-a-release

Setting the job strategy.max-parallel to 1 prevents this issue, at the expense of longer build times.

It looks like a race condition on the GitHub side if the same release is being created at the same time by different jobs.

The action should wait a little and retry in this specific error.

The purpose of using matrix is ​​to make the job run concurrently. Your solution of strategy.max-parallel to 1 has lost the meaning of matrix, which is not a fundamental solution to the problem. I currently have more than 40 matrix parallels. If I set parallel to 1, it will be a disaster and the github action will time out. But thank you for your reply.

However, I thought, if I upload the matrix compilation result to Artifacts, and then create a new matrix, each matrix downloads the compilation result from Artifacts and uploads it to the release of the same tag, I wonder if this problem can be solved temporarily by setting strategy.max-parallel to 1. Have you tried it?

I will test whether it is feasible https://github.com/smallprogram/OpenWrtAction/commit/e8e76814055916c4b5c4dd89021e23e57b79477b

Is it possible that before uploading the result of matrix compilation, I can create an empty tag using softprops/action-gh-release, and then perform the upload operation concurrently in the subsequent matrix, will this solve the problem?

[lincolnthalles]

When used in a matrix, uploading files with different names to the same tag will only work properly in a few cases, and most of the time it will report an error.

⚠️ Unexpected error fetching GitHub release for tag refs/heads/test: HttpError: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} - https://docs.github.com/rest/releases/releases#update-a-release
Error: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} - https://docs.github.com/rest/releases/releases#update-a-release

Setting the job strategy.max-parallel to 1 prevents this issue, at the expense of longer build times. It looks like a race condition on the GitHub side if the same release is being created at the same time by different jobs. The action should wait a little and retry in this specific error.

The purpose of using matrix is ​​to make the job run concurrently. Your solution of strategy.max-parallel to 1 has lost the meaning of matrix, which is not a fundamental solution to the problem. I currently have more than 40 matrix parallels. If I set parallel to 1, it will be a disaster and the github action will time out. But thank you for your reply.

However, I thought, if I upload the matrix compilation result to Artifacts, and then create a new matrix, each matrix downloads the compilation result from Artifacts and uploads it to the release of the same tag, I wonder if this problem can be solved temporarily by setting strategy.max-parallel to 1. Have you tried it?

I will test whether it is feasible smallprogram/OpenWrtAction@e8e7681

Is it possible that before uploading the result of matrix compilation, I can create an empty tag using softprops/action-gh-release, and then perform the upload operation concurrently in the subsequent matrix, will this solve the problem?

Each matrix job is a separate job running in parallel, meaning each job will try to create or modify the related tagged release. It's possible to upload the artifacts and then create the release at once on another independent job, but this can be painful on some workflows.

To change the tag name you'll need to source a different action that can do this.

I also tried ncipollo/release-action@v1 and it produced the same tag_name already_exists error.

I suggest you try to create an empty release beforehand with the same tag and release type in a step allowed to fail, like this:

      - name: Prepare Release
        uses: softprops/action-gh-release@v2
        continue-on-error: true
        with:
          tag_name: mytag
          make_latest: true

      - name: Publish Release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: mytag
          make_latest: true
          files: ....
          body_path: ....

Looks like this worked out in my case. It's not an actual fix, but it will give some headroom to the GitHub API.

[smallprogram]

Regarding the problem of uploading files to the same tag name using matrix, I found the ultimate solution and shared it with those who need it.

Solution 1

with performance loss Can avoid "already_exists","field":"tag_name"

Although this method can avoid the problem, it will lose the advantage of matrix parallelism.

Solution 2

This method requires an extra step to create a tag name without files, and then upload the required matrix in parallel to the previously created tag name. This method has better performance and does not lose the advantage of parallel execution of the matrix.

I hope these two solutions can help those in need.

@lpil @lincolnthalles @andrew121410 @manuelkienlein @debdutdeb