is this related to the Publish to Winget action firing twice per release?

Yes.

We probably can remove the first upload and keep the upload from tagging.

We probably can remove the first upload and keep the upload from tagging.

hmm, but the first upload should be marked as draft, which shouldn't trigger the winget workflow... right?

the workflow defines the condition:

on:
  release:
    types: [released]

I agree though, we can try that, see how it works.

How about we modify the appveyor deployment config so that commits to master create a RC release on the Prereleases repo, instead of a draft release on the main repo?

We probably can remove the first upload and keep the upload from tagging.

hmm, but the first upload should be marked as draft, which shouldn't trigger the winget workflow... right?

the workflow defines the condition:

on:

  release:

    types: [released]

The documentation doesn't clearly say as far as I can tell. 🤔

The documentation doesn't clearly say as far as I can tell. 🤔

yup, I find it vague as well...

How about we modify the appveyor deployment config so that commits to master create a RC release on the Prereleases repo, instead of a draft release on the main repo?

I mean something like:

   - provider: GitHub
+    repository: Flow-Launcher/Prereleases
     release: v$(flowVersion)
+    description: 'This is a release candidate.'
     auth_token:
       secure: ij4UeXUYQBDJxn2YRAAhUOjklOGVKDB87Hn5J8tKIzj13yatoI7sLM666QDQFEgv
     artifact: Squirrel Installer, Portable Version, Squirrel nupkg, Squirrel RELEASES
-    draft: true
     force_update: true
     on:
       branch: master

   - provider: GitHub
      release: v$(flowVersion)
      auth_token:
         secure: ij4UeXUYQBDJxn2YRAAhUOjklOGVKDB87Hn5J8tKIzj13yatoI7sLM666QDQFEgv
      artifact: Squirrel Installer, Portable Version, Squirrel nupkg, Squirrel RELEASES
-    force_update: true
     on:
        APPVEYOR_REPO_TAG: true

I am not sure what is defined as 'released' for the action without investigating.

How about we modify the appveyor deployment config so that commits to master create a RC release on the Prereleases repo, instead of a draft release on the main repo?

I dont think this is a necessary step.

If you have a look, whenever we merge to main, it runs two build process, once on merge and another on tag, and this takes a tremendous longer time to finish the whole release process. I want to see if it's possible to simplify, on merge -> build -> upload -> create release note draft (assuming this creates a tag as well). Hence I suggested maybe there is a step we can remove there which will also be able to help with WinGet action firing twice.

I think this step is not necessary, we don't ever manually tag for release:

I think this step is not necessary, we don't ever manually tag for release:

Flow.Launcher/appveyor.yml

Lines 79 to 86 in fa2c894

	- provider: GitHub
	release: v$(flowVersion)
	auth_token:
	secure: ij4UeXUYQBDJxn2YRAAhUOjklOGVKDB87Hn5J8tKIzj13yatoI7sLM666QDQFEgv
	artifact: Squirrel Installer, Portable Version, Squirrel nupkg, Squirrel RELEASES
	force_update: true
	on:
	APPVEYOR_REPO_TAG: true

This deployment should also fire when you publish a release, if the associated tag does not already exist...

Maybe this explains why winget action runs twice: once when the draft release is manually promoted to published, and once more when AppVeyor finishes building that tag and force_updates the release. It isn't clear from their documentation, though...

Anyways, I think we can simplify the deployment setup by only creating a draft release on branch: master and APPVEYOR_REPO_TAG: false.

I think that would satisfy your requirements @jjw24 :

• the release is only published when manually promoted from draft, which should ensure the winget action fires only once.
• the tag build job does not affect the release process and therefore you don't need to wait for it to finish.

sounds good?

the release is only published when manually promoted from draft, which should ensure the winget action fires only once.

Yes this would be the goal.

the tag build job does not affect the release process and therefore you don't need to wait for it to finish.

I suppose setting it to APPVEYOR_REPO_TAG: false makes sense if the previous steps do not create a tag, but if a tag is created when a draft release is created, I do not think this entire step is necessary. I do not know if this is the case that the tag is created before this step, so please test when working on this issue.

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.

This issue was closed because it has been stale for 7 days with no activity. If you feel this issue still needs attention please feel free to reopen.

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.