A Wiki page/Website page/Discussion topic for Early access builds/beta testing?

[pc223]

Should we do something similar like this? 🤔 (like a Wiki page, or Flow's website page or Discussion topic?)

https://github.com/goldendict/goldendict/wiki/Early-Access-Builds-for-Windows

We got automatic CI artifacts so it seems not too hard to do.

I think we only need a couple of main builds:

• A dev branch build
• A next release build (like 1.8.0)
• Some PR build (builds of a big PRs, e.g. PR Optimize Exception Handling and Log #470)

Why:

• For people want to test new improvements
• For testing new ideas
• Early feedback, early bug report

[jjw24]

i dont know if there are enough interests atm to test builds. the builds can always be accessed via the build results in each PR, perhaps when there are more requests we can put it in a discussion section or wire up the ci for it

[pc223]

i dont know if there are enough interests atm to test builds. the builds can always be accessed via the build results in each PR, perhaps when there are more requests we can put it in a discussion section or wire up the ci for it

I think people will try it out if we provide them the builds clearly (like what that build is for, and where to post testing-results), right now the builds are buried in PR which is not many people aware of and not sure what to do with it.

Early feedback is the whole point of CI/CD stuff, I think we need early feedback on big PRs like PR-#470 or big releases like 1.8.0, or feedback about style (PR-#495) (those tend to be fairly subjective)

And the last release of Flow is like 4 months now. Many users not able to try out all the improvement that exists for months seems a bit ...sad 😅

I think, for now, we can just keep it really simple, 1 topic (discussion) for it, listed 3 builds: a weekly-dev-builds, a 1.8.0 build, a big PR build. And we ask people to try them out.

In terms of maintenance, for now we can do manual, weekly edit that topic, later we can write some CI to automate if people like it.

[jjw24]

The release pr will constantly have changes merged in, which will be quite manual to keep up with the latest builds in discussion, (I'm afk) I wonder if there is something in AppVeyor to provide a constant link to the latest build of the pr.

Version from builds are still the production release version, for currently it is 1.7.2, I don't know if we need to mark them as pre-release and how.

[pc223]

Seems this will link get latest good artifacts of the dev branch (not check with official docs yet)

Web link:
https://ci.appveyor.com/project/JohnTheGr8/flow-launcher/branch/dev/artifacts

Download link:
https://ci.appveyor.com/api/projects/JohnTheGr8/flow-launcher/artifacts/Output%2FPackages%2FFlow-Launcher-v1.7.2.exe?branch=dev&pr=false

For Pull Requests, I can't find it yet, worst case, we make a branch on the main repo, and grant people commit rights to that branch, not perfect, but automatic => no maintenance cost.

Sources:
appveyor/ci#403 (comment)

https://help.appveyor.com/discussions/questions/4501-url-to-the-latest-build-in-the-master-branch

https://www.appveyor.com/docs/packaging-artifacts/#permalink-to-the-last-successful-build-artifact

[jjw24]

Also how is this discussion abt adding early access builds in Discussions not already in Discussions 😛

[pc223]

Also how is this discussion abt adding early access builds in Discussions not already in Discussions 😛

Haha hold up, lemme convert this real quick, kind of itchy to try it 😝

[jjw24]

manual one will be like this i suppose
#535

[pc223]

yeah that's what i mean, just one announcement, call it early access builds and can contain those build links

We have 12 pull requests now, assume we want users to try out those 12 builds, so that announcement will contains 12 builds?

Those 12 build links will have to update when have new commits tho. Ideally we can have a script auto-update those build links, I think appveyor api support this use case, but don't have time to research on it yet.

[pc223]

That's why I mentioned the PRmodel, build_list.md, because that oneway to manage all the build links.

[jjw24]

well we dont need to let users to test all 12, just the big ones. more importantly however how do we pull the links out and append it to the md?

[pc223]

well we dont need to let users to test all 12, just the big ones. more importantly however how do we pull the links out and append it to the md?

Yeah, I'm hoping that Appveyor support some kind of api to pull links out for PR, maybe have to write a script to do it instead of a simple one-liner URL, I'll research on this later.

[pc223]

Seems we have to use these API to automate this:

1. Get history, find the PR build, get the buid version (1.7.2.2000)
   https://ci.appveyor.com/api/projects/JohnTheGr8/flow-launcher/history?recordsNumber=3&branch=dev&startBuildId=39801085

2. Get the JobId (m9thia3t5p1kw8ab)
   https://ci.appveyor.com/api/projects/JohnTheGr8/flow-launcher/build/1.7.2.2000

3. All artifacts
   https://ci.appveyor.com/api/buildjobs/m9thia3t5p1kw8ab/artifacts

4. .exe file direct download link
   https://ci.appveyor.com/api/buildjobs/m9thia3t5p1kw8ab/artifacts/Output/Packages/Flow-Launcher-v1.7.2.exe

Ref:
https://kevinoid.github.io/appveyor-swagger/bootprint/