[GH-ISSUE #79] CI by appveyor

kerem commented

2026-02-26 11:56:36 +03:00

Owner

Originally created by @VShawn on GitHub (Feb 6, 2021).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/79

I‘ve set up CI by appveyor.

Now it will

auto build every commit
auto build/pack/publish tag to Github draft-release.

@majkinetor maybe you can try to set up a deployment for chocolatey?

Originally created by @VShawn on GitHub (Feb 6, 2021). Original GitHub issue: https://github.com/1Remote/1Remote/issues/79 I‘ve set up CI by appveyor. --- ![image](https://user-images.githubusercontent.com/10143738/107109133-86b05780-6878-11eb-8b1a-cc56964bf5f1.png) Now it will - auto build every commit - auto build/pack/publish tag to Github draft-release. ![image](https://user-images.githubusercontent.com/10143738/107109119-70a29700-6878-11eb-9097-beb17a2416a7.png) @majkinetor maybe you can try to set up a deployment for chocolatey?

kerem

2026-02-26 11:56:36 +03:00

closed this issue
added the
general-build/ci
label

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Feb 6, 2021):

@majkinetor maybe you can try to set up a deployment for chocolatey?

What do you mean ? You want those draft releases on chocolatey too along with regular releases? or chocolatey package build and release to happen on AV ? Or something else ? :)

I‘ve set up CI by appveyor.

Where is the appveryor.yaml ?

@majkinetor commented on GitHub (Feb 6, 2021): > @majkinetor maybe you can try to set up a deployment for chocolatey? What do you mean ? You want those draft releases on chocolatey too along with regular releases? or chocolatey package build and release to happen on AV ? Or something else ? :) > I‘ve set up CI by appveyor. Where is the appveryor.yaml ?

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 6, 2021):

just offering an option since i dont know hot to release to chocolatey. I thought if I build a release, you may need them to publish to chocolatey 😃

And I set up AV all by Web UI, no appveryor.yaml needed.

@VShawn commented on GitHub (Feb 6, 2021): just offering an option since i dont know hot to release to chocolatey. I thought if I build a release, you may need them to publish to chocolatey 😃 And I set up AV all by Web UI, no appveryor.yaml needed. ![image](https://user-images.githubusercontent.com/10143738/107116780-9055b180-68b0-11eb-985a-d17d50a35a2c.png)

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Feb 6, 2021):

I thought if I build a release, you may need them to publish to chocolatey

No, its already automated, it juts has a latency of several hours as my bot runs minimally once a day.

It looks at https://github.com/VShawn/PRemoteM/releases and finds first .7z file. It didn't pick up your draft release as it is zip file and even if I change it, it can't get a version from it.

I don't think having a release on EACH commit is valuable - having a build and artifacts is, and it should be enough - we can just put in a README.md location of last AV artifacts for those that want last commit build.

I think you should direct via commit message or push options that you want pre release. For example:

git commit -m 'fix this and that [release]`

You can parse this message on AV via env var $Env:APPVEYOR_REPO_COMMIT_MESSAGE and just do the release if the keyword is present, something like

switch -regex ($Env:APPVEYOR_REPO_COMMIT_MESSAGE)
{
            '\[release (.+)]'   { $release = $Matches[1] }
       #.... 
       # other instructions could be added here
}

# ...

if ($release -eq 'pre') { ... }
if ($release -eq 'prod') { ... }

Release should be done on master only (or dev as it currently stands). Build with artifacts should work on any branch (so we can test PR's of others too). Your flow is then

Commit and push normally
When you want pre release, commit with [release pre] somewhere. It should mark it on GH as pre-release (not draft). Pre release versions usually have -xyz suffix in their version e.g. 1.2.3-r1.
When you want official release, go with [release prod] which will mark it as non pre release.

By doing that, all your releases are read only after published - there are no extra changes you do later (which is not OK, releases must be immutable).

I can furthermore modify auto update routine for chocolatey package to release all to choco so then we will have:

cinst premotem --pre - go for last pre release
cinst premtem - go for last official release

For latest commit build you need to go to the the artifact page but I guess nobody will nit those once pre release is set and easily avaialable.

Pre releases do not need to have any other info in them, official releases will have a changelog and other things.

You should IMO remove build number from version i.e. 0.5.8.2101192131 should be 0.5.8. It doesn't provide any meaning and locks us from using it for other meaningful purposes.

We can also add automatic changelog creation - on full release on AV create a new milestone, move closed NEXT issues to it, and provide a relevant link in release markdown. Then your can only do programming and nothing else, everything will just flow if we follow the conventions.

And I set up AV all by Web UI, no appveryor.yaml needed.

You know the drill - not on a repository, it doesn't exist :)

You should really make it via file not only for versioning but for transparency and collaboration.

@majkinetor commented on GitHub (Feb 6, 2021): > I thought if I build a release, you may need them to publish to chocolatey No, its already automated, it juts has a latency of several hours as my bot runs minimally once a day. It looks at https://github.com/VShawn/PRemoteM/releases and finds first .7z file. It didn't pick up your draft release as it is zip file and even if I change it, it can't get a version from it. I don't think having a release on EACH commit is valuable - having a build and artifacts is, and it should be enough - we can just put in a README.md location of last AV artifacts for those that want last commit build. I think you should direct via commit message or push options that you want pre release. For example: ``` git commit -m 'fix this and that [release]` ``` You can parse this message on AV via env var `$Env:APPVEYOR_REPO_COMMIT_MESSAGE` and just do the release if the keyword is present, something like ```ps1 switch -regex ($Env:APPVEYOR_REPO_COMMIT_MESSAGE) { '\[release (.+)]' { $release = $Matches[1] } #.... # other instructions could be added here } # ... if ($release -eq 'pre') { ... } if ($release -eq 'prod') { ... } ``` Release should be done on `master` only (or dev as it currently stands). Build with artifacts should work on any branch (so we can test PR's of others too). Your flow is then 1. Commit and push normally 2. When you want pre release, commit with `[release pre]` somewhere. It should mark it on GH as pre-release (not draft). Pre release versions usually have `-xyz` suffix in their version e.g. `1.2.3-r1`. 3. When you want official release, go with `[release prod]` which will mark it as non pre release. By doing that, all your releases are read only after published - there are no extra changes you do later (which is not OK, releases must be immutable). I can furthermore modify auto update routine for chocolatey package to release all to choco so then we will have: `cinst premotem --pre` - go for last pre release `cinst premtem` - go for last official release For latest commit build you need to go to the the artifact page but I guess nobody will nit those once pre release is set and easily avaialable. Pre releases do not need to have any other info in them, official releases will have a changelog and other things. You should IMO remove build number from version i.e. 0.5.8.2101192131 should be 0.5.8. It doesn't provide any meaning and locks us from using it for other meaningful purposes. We can also add automatic changelog creation - on full release on AV create a new milestone, move closed NEXT issues to it, and provide a relevant link in release markdown. Then your can only do programming and nothing else, everything will just flow if we follow the conventions. > And I set up AV all by Web UI, no appveryor.yaml needed. You know the drill - not on a repository, it doesn't exist :) You should really make it via file not only for versioning but for transparency and collaboration.

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 8, 2021):

I don't think having a release on EACH commit is valuable

the current draft-release by commit was just for test. It was tiggered manually. The true release will be definitely build by tag.

git commit -m 'fix this and that [release]`

good idea, I will try this. just feeling commands may be easily forgotten if not used it for a long time.

i.e. 0.5.8.2101192131 should be 0.5.8

build number IMO is for hot-fix, if I fix some bug on 0.5.8 and latest release is 0.6.0.XXXX, then I can release two fix package 0.5.8.210208 and 0.6.0.210208. it can at least tell me witch is the latest version of 0.5.8;

@VShawn commented on GitHub (Feb 8, 2021): > I don't think having a release on EACH commit is valuable the current draft-release by commit was just for test. It was tiggered manually. The true release will be definitely build by tag. > git commit -m 'fix this and that [release]` good idea, I will try this. just feeling commands may be easily forgotten if not used it for a long time. > i.e. 0.5.8.2101192131 should be 0.5.8 build number IMO is for hot-fix, if I fix some bug on 0.5.8 and latest release is 0.6.0.XXXX, then I can release two fix package 0.5.8.210208 and 0.6.0.210208. it can at least tell me witch is the latest version of 0.5.8;

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Feb 19, 2021):

just feeling commands may be easily forgotten if not used it for a long time.

Not if they are documented :) It can be done within build or in readme. Here is screenshot of my GitLab build of one project that uses it with 20+ operations that team uses without any problems

build screenshot

build number IMO is for hot-fix, if I fix some bug on 0.5.8 and latest release is 0.6.0.XXXX, then I can release two fix package 0.5.8.210208 and 0.6.0.210208. it can at least tell me witch is the latest version of 0.5.8;

Or you can use 0.6.1 and 0.5.9 ? :)

@majkinetor commented on GitHub (Feb 19, 2021): > just feeling commands may be easily forgotten if not used it for a long time. Not if they are documented :) It can be done within build or in readme. Here is screenshot of my GitLab build of one project that uses it with 20+ operations that team uses without any problems<details><summary>build screenshot</summary> ![image](https://user-images.githubusercontent.com/85767/108491480-430c1380-72a4-11eb-83f1-122b7abd5333.png) </details> > build number IMO is for hot-fix, if I fix some bug on 0.5.8 and latest release is 0.6.0.XXXX, then I can release two fix package 0.5.8.210208 and 0.6.0.210208. it can at least tell me witch is the latest version of 0.5.8; Or you can use 0.6.1 and 0.5.9 ? :)

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 19, 2021):

refer from the instruction of semantic versioning:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

In our case

https://github.com/VShawn/PRemoteM/blob/dev/PRM.Core/PRMVersion.cs#L3-L9

Major is for incompatible design change. now 0 stands for PRM is still in beta test.

Minor is for milestone achieve

Build is for add functionality

ReleaseDate is for bug fix

Their role is slightly deviated from their name, I will fit it when we migrate to .NET5.

I can change the version format when we migrate to .NET5, but still I can not tell how it locks us from using it for other meaningful purposes, or the benefit of this change

BTW here is the mRemotNG versioning:

@VShawn commented on GitHub (Feb 19, 2021): refer from the instruction of semantic versioning: ``` MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. ``` In our case https://github.com/VShawn/PRemoteM/blob/dev/PRM.Core/PRMVersion.cs#L3-L9 **Major** is for incompatible design change. now 0 stands for PRM is still in beta test. **Minor** is for `milestone achieve` **Build** is for `add functionality ` **ReleaseDate** is for `bug fix` Their role is slightly deviated from their name, I will fit it when we migrate to .NET5. I can change the version format when we migrate to .NET5, but still I can not tell how it ` locks us from using it for other meaningful purposes`, or the benefit of this change BTW here is the mRemotNG versioning: ![image](https://user-images.githubusercontent.com/10143738/108507125-cce3cd00-72f4-11eb-9aee-502c904f710a.png)

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Feb 19, 2021):

One example of lock is that chocolatey uses build to mark changes in package itself. For example 1.2.3 is a software version but 1.2.3.20120102 means its the same version but package is updated/fixed.

It also looks ugly, but it might be just me :)

Its also not by the semantic version standard as you already mentioned.

@majkinetor commented on GitHub (Feb 19, 2021): One example of lock is that chocolatey uses build to mark changes in package itself. For example 1.2.3 is a software version but 1.2.3.20120102 means its the same version but package is updated/fixed. It also looks ugly, but it might be just me :) Its also not by the semantic version standard as you already mentioned.

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Feb 19, 2021):

One of the major things that is problematic is that its not easy to see that you need new version or what is latest when you release a fix. I had to scan digit to digit to be sure ones.

0.5.8.2101192131
0.5.8.2101282043

Keep in mind that my automatic choco updater wont pick this up as nobody does that. Normal releases are handled very quickly

@majkinetor commented on GitHub (Feb 19, 2021): One of the major things that is problematic is that its not easy to see that you need new version or what is latest when you release a fix. I had to scan digit to digit to be sure ones. - 0.5.8.2101192131 - 0.5.8.2101282043 Keep in mind that my automatic choco updater wont pick this up as nobody does that. Normal releases are handled [very quickly](https://chocolatey.org/packages/premotem/0.5.9.2102191952)

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 20, 2021):

okey You Convinced Me, next version will be 0.5.10 : )

@VShawn commented on GitHub (Feb 20, 2021): okey You Convinced Me, next version will be 0.5.10 : )

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Feb 20, 2021):

Hahaha, nice :-)

@majkinetor commented on GitHub (Feb 20, 2021): Hahaha, nice :-)

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Feb 20, 2021):

Can you add me to AV to mess around with build when I have time? I can implement some speedups and see how to do basic tests so that thing that happened on last publish is less probable.

@majkinetor commented on GitHub (Feb 20, 2021): Can you add me to AV to mess around with build when I have time? I can implement some speedups and see how to do basic tests so that thing that happened on last publish is less probable.

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 20, 2021):

sure thing. I invited your gmail as administrator

@VShawn commented on GitHub (Feb 20, 2021): sure thing. I invited your gmail as administrator

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@VShawn commented on GitHub (May 20, 2021):

this CI is not as useful as I imagined

@VShawn commented on GitHub (May 20, 2021): this CI is not as useful as I imagined

kerem commented

2026-02-26 11:56:36 +03:00

Author

Owner

@majkinetor commented on GitHub (May 20, 2021):

Yeah, I didn't find time to do it so far. Covid introduced a lot of work here. I go on vacation in a month or so so I will see to make it able to do GitHub releases and maybe some basic run test (like screenshot of running app. It is hard to test this app by simulating user input since it doesn't use standard UI controls.

@majkinetor commented on GitHub (May 20, 2021): Yeah, I didn't find time to do it so far. Covid introduced a lot of work here. I go on vacation in a month or so so I will see to make it able to do GitHub releases and maybe some basic run test (like screenshot of running app. It is hard to test this app by simulating user input since it doesn't use standard UI controls.

kerem referenced this issue

2026-02-28 12:00:36 +03:00

[GH-ISSUE #26] Feature planning and discussion #976

kerem referenced this issue

2026-02-28 12:00:37 +03:00

[GH-ISSUE #26] Feature planning and discussion #976

kerem referenced this issue

2026-02-28 12:00:46 +03:00

[GH-ISSUE #61] Configuration options for external programs (protocols and tools) #1006

kerem referenced this issue

2026-02-28 12:00:48 +03:00

[GH-ISSUE #68] Connection option to specify kitty profile #1013