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

AppVeyor deployment enhancements #2185

Draft
wants to merge 3 commits into
base: dev
Choose a base branch
from

Conversation

JohnTheGr8
Copy link
Member

Starting a PR following the discussion in #2086

with this modified setup:

  1. on commit to master (ie when a release PR is merged), AppVeyor will:
    a. create a draft release on the main repository
    b. publish a release on the Prereleases repository (otherwise it falls behind when a stable version is published)
  2. the draft release gets reviewed & tested, release notes are written
  3. when the app is ready, the draft release can be published (manually). This should:
    a. trigger the WinGet release action
    b. create the git tag, which will trigger an AppVeyor build that will only deploy the Flow.Launcher.Plugin package to nuget (when it has been changed)

Some notes:

  • releases are only published once (manually), never force-updated from a CI job... should resolve BUG: WinGet release uploads with the wrong hash  #2086
  • during step 2, hot-fixes can be applied to the master branch, without bumping the app version.
  • the build-on-tag is still used for pushing to nuget, because:
    1. we don't really care if it takes a few minutes more to deploy to nuget
    2. we want deployment to nuget to be the final step in the release process
    3. nuget packages are immutable: if we published on commit to master, we wouldn't be able to support hot-fixes

sanity testing is still TODO but let me know what you think

* create draft release on commit (not tag) to master
* do not force_update existing releases
`prereleaseTag` was being defined as `APPVEYOR_BUILD_VERSION`
Add a new deploy target that is triggered when we merge to master and
creates a release on the `Prereleases` repository with the same artifacts
as the upcoming main release.
@JohnTheGr8 JohnTheGr8 self-assigned this Jun 12, 2023
@github-actions
Copy link

@check-spelling-bot Report

🔴 Please review

See the 📂 files view or the 📜action log for details.

Unrecognized words (2)

Prereleases
Veyor

To accept ✔️ these unrecognized words as correct and remove the previously acknowledged and now absent words, run the following commands

... in a clone of the git@github.com:JohnTheGr8/Flow.Launcher.git repository
on the appveyor_deployment_enhancements branch (ℹ️ how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/main/apply.pl' |
perl - 'https://github.com/Flow-Launcher/Flow.Launcher/actions/runs/5248266836/attempts/1'
If the flagged items are 🤯 false positives

If items relate to a ...

  • binary file (or some other file you wouldn't want to check at all).

    Please add a file path to the excludes.txt file matching the containing file.

    File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

    ^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

  • well-formed pattern.

    If you can write a pattern that would match it,
    try adding it to the patterns.txt file.

    Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

    Note that patterns can't match multiline strings.

@jjw24 jjw24 marked this pull request as ready for review June 26, 2023 12:40
@jjw24 jjw24 marked this pull request as draft June 26, 2023 12:41
@jjw24 jjw24 added the bug Something isn't working label Jun 26, 2023
Comment on lines -7 to -10
if ($env:APPVEYOR_REPO_BRANCH -eq "dev")
{
$env:prereleaseTag = "{0}.{1}.{2}.{3}" -f $version.Major, $version.Minor, $version.Build, $version.Revision
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this removed? We need to add the revision version for prereleases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not removed, just replaced with $APPVEYOR_BUILD_VERSION, they are exactly the same

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine make sure you test it, if I remember correctly when I updated this, that pipeline variable returned only the build number part of the version.

Copy link
Member

@jjw24 jjw24 Jun 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also we want revision number too not just the build number.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see line 5 above, $env:prereleaseTag was derived from $env:APPVEYOR_BUILD_VERSION

force_update: true
on:
branch: master
APPVEYOR_REPO_TAG: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this needed? Does this mean trigger on master or non-tagged builds?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I want is for it to trigger on master & tag, but I need to test to make sure that's how it behaves

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am not mistaking, I think you are trying to cover a scenario (doing a hot fix during a release) that has never happened. We have had several times where we needed to immediately rollout a hot fix after a release, but never during.

Assuming a tag is only created after setting the draft release to latest, you can just cater for:

  1. Merge to master -> draft release, so 'on master' condition
  2. Setting draft release to latest -> trigger 'on tag' -> publish NuGet and Prerelease

I think this is a simpler pipeline process. Any hot fixes we just do a new release. If we need to really hot fix during a release, I can just delete draft release, then merge hot fix in, which will kick off the above process again.

You will find testing this is a painful process because our build & test takes a while, recommend fork the project and the prerelease project, comment out the unit test code and test that way. Also I might be wrong but off the top of my head I think the 'on' condition you got is 'master' or 'tag is false'.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am not mistaking, I think you are trying to cover a scenario (doing a hot fix during a release) that has never happened. We have had several times where we needed to immediately rollout a hot fix after a release, but never during.

I am not trying to cover that scenario, really... it just happens to be possible with this setup, so I'm spelling it out.

Assuming a tag is only created after setting the draft release to latest, you can just cater for:

  1. Merge to master -> draft release, so 'on master' condition

  2. Setting draft release to latest -> trigger 'on tag' -> publish NuGet and Prerelease

so you suggest that we push to Prereleases when APPVEYOR_REPO_TAG: true right?

Also I might be wrong but off the top of my head I think the 'on' condition you got is 'master' or 'tag is false'.

yeah it could be so, I'll define a different env variable for this to be sure

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so you suggest that we push to Prereleases when APPVEYOR_REPO_TAG: true right?

Yeah. I don't think it matters if it's pushed on merge to master or when APPVEYOR_REPO_TAG: true. If on merge to master you can set force push to true so hot fix during a release will still update the prerelease artefacts.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

release artifacts wont be exactly the same but that's no big deal

on:
APPVEYOR_REPO_TAG: true
branch: master
APPVEYOR_REPO_TAG: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above comment

appveyor.yml Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working CI/CD no-pr-activity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG: WinGet release uploads with the wrong hash
2 participants