[GH-ISSUE #308] Turn off Redundant CI systems

gitea-mirror commented

2026-05-05 05:50:22 -06:00

Owner

Originally created by @AdrianKoshka on GitHub (May 16, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/308

Originally assigned to: @walker0643, @AdrianKoshka on GitHub.

Now that Azure Pipelines has finally been integrated (#303), Travis and Appveyor will need to be sunset eventually. (pinging @nelsonjchen)

Originally created by @AdrianKoshka on GitHub (May 16, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/308 Originally assigned to: @walker0643, @AdrianKoshka on GitHub. Now that Azure Pipelines has finally been integrated (#303), Travis and Appveyor will need to be sunset eventually. (pinging @nelsonjchen)

gitea-mirror

2026-05-05 05:50:22 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 05:50:27 -06:00

Author

Owner

@nelsonjchen commented on GitHub (May 17, 2019):

I don't think @TafThorne got an answer from @walker0643 on what was needed to be protected in the AppVeyor config.

https://github.com/debauchee/barrier/pull/250#issuecomment-461734948

Is it like credentials to upload to a server, an S3 bucket, downloading a private mirror of QT, or ??? I can investigate what needs to be done to emulate whatever that activity or protect the secrets of that activity.

@nelsonjchen commented on GitHub (May 17, 2019): I don't think @TafThorne got an answer from @walker0643 on what was needed to be protected in the AppVeyor config. https://github.com/debauchee/barrier/pull/250#issuecomment-461734948 Is it like credentials to upload to a server, an S3 bucket, downloading a private mirror of QT, or ??? I can investigate what needs to be done to emulate whatever that activity or protect the secrets of that activity.

gitea-mirror commented

2026-05-05 05:50:29 -06:00

Author

Owner

@nelsonjchen commented on GitHub (May 17, 2019):

I think I know what was protected. It's just a guess, but I think @walker0643 was thinking of protecting the secure variable that was supposed to be the RDP password for logging in and debugging stuff. It was probably setup according to these instructions:

https://www.appveyor.com/docs/how-to/rdp-to-build-worker/

If you don't set that environment variable, the RDP enabling script will randomly generate a password and print that out to the STDOUT and to the Appveyor log.

We're already moving to Azure Pipelines but if that environment variable was removed and it printed out the temporary password, it wouldn't have been a big deal:

The machines last for 60 minutes tops anyway and get blown away afterwards.
The RDP port is on a non-standard port
RDP is single user. Anything actively screwing with you will have to actively watch the logs and scrape a username and password. It would also make it extremely graphically obvious to log in when someone is logged in. There's no passive screwing around.
Generally you try to keep those debug RDP enabling scripts away from production branches or even repos.

This was from the junk PR that was created when we asked @walker0643 to install Azure Pipelines in the repo/organization. I noticed it was ✔️ ! What?! I didn't think much of it but then I took a look at the log:

https://ci.appveyor.com/project/walker0643/barrier/builds/24565416

Another thing protected was probably whatever the URL was for hosting that Bonjour SDK. If that was leaked, that would be dirty, but it wouldn't be bad.

Since Appveyor blocked builds for PRs, I could never guess what were the actual directives configured in Appveyor until that mysterious ✔️ showed up. But from the PR, I can see the build fails anyway so it still needed some TLC.

That said, I don't think we're missing anything from the Appveyor build. RDP isn't available on Azure Pipelines (though I haven't tried reverse tunneling in for giggles yet), the Bonjour SDK has been replaced with a free software build, and the build works.

@nelsonjchen commented on GitHub (May 17, 2019): I *think* I know what was protected. It's just a guess, but I think @walker0643 was thinking of protecting the secure variable that was supposed to be the RDP password for logging in and debugging stuff. It was probably setup according to these instructions: https://www.appveyor.com/docs/how-to/rdp-to-build-worker/ If you don't set that environment variable, the RDP enabling script will randomly generate a password and print that out to the STDOUT and to the Appveyor log. We're already moving to Azure Pipelines but if that environment variable was removed and it printed out the temporary password, it wouldn't have been a big deal: 1) The machines last for 60 minutes tops anyway and get blown away afterwards. 2) The RDP port is on a non-standard port 3) RDP is single user. Anything actively screwing with you will have to actively watch the logs and scrape a username and password. It would also make it extremely graphically obvious to log in when someone is logged in. There's no passive screwing around. 4) Generally you try to keep those debug RDP enabling scripts away from production branches or even repos. This was from the junk PR that was created when we asked @walker0643 to install Azure Pipelines in the repo/organization. I noticed it was ✔️ ! What?! I didn't think much of it but then I took a look at the log: https://ci.appveyor.com/project/walker0643/barrier/builds/24565416 Another thing protected was probably whatever the URL was for hosting that Bonjour SDK. If that was leaked, that would be dirty, but it wouldn't be bad. Since Appveyor blocked builds for PRs, I could never guess what were the actual directives configured in Appveyor until that mysterious ✔️ showed up. But from the PR, I can see the build fails anyway so it still needed some TLC. That said, I don't think we're missing anything from the Appveyor build. RDP isn't available on Azure Pipelines (though I haven't tried reverse tunneling in for giggles yet), the Bonjour SDK has been replaced with a free software build, and the build works.

gitea-mirror commented

2026-05-05 05:50:31 -06:00

Author

Owner

@TafThorne commented on GitHub (May 17, 2019):

Do we get a usable installer at the end of the pipeline now? I have not looked which is a bit lazey of me.

@TafThorne commented on GitHub (May 17, 2019): Do we get a usable installer at the end of the pipeline now? I have not looked which is a bit lazey of me.

gitea-mirror commented

2026-05-05 05:50:33 -06:00

Author

Owner

@nelsonjchen commented on GitHub (May 17, 2019):

I haven't tried the Windows installer yet too. I'm lazy too.

Oh, I also discovered that artifacts are not downloadable by users in the Azure Pipelines organization. I thought that blue button I mentioned in #303 would appear publicly but I guess not:

https://dev.azure.com/debauchee/Barrier/_build/results?buildId=3

@nelsonjchen commented on GitHub (May 17, 2019): I haven't tried the Windows installer yet too. I'm lazy too. Oh, I also discovered that artifacts are not downloadable by users in the Azure Pipelines organization. I thought that blue button I mentioned in #303 would appear publicly but I guess not: ![](https://user-images.githubusercontent.com/5363/57508307-03825c00-72b6-11e9-9deb-bcb4e8f0121a.jpg) https://dev.azure.com/debauchee/Barrier/_build/results?buildId=3

gitea-mirror commented

2026-05-05 05:50:35 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 17, 2019):

I can download the artifacts (Tested this by downloading the release installer).

@AdrianKoshka commented on GitHub (May 17, 2019): I can download the artifacts (Tested this by downloading the release installer).

gitea-mirror commented

2026-05-05 05:50:36 -06:00

Author

Owner

@nelsonjchen commented on GitHub (May 17, 2019):

Weird! The button appears for me now!

@nelsonjchen commented on GitHub (May 17, 2019): Weird! The button appears for me now!

gitea-mirror commented

2026-05-05 05:50:38 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 17, 2019):

new PRs will be built with AP, correct? So hypothetically someone could make a PR, and then we could link a release-installer in a comment on the PR? (Possibly automate that with a github action). I know it's unrelated, but I thought I'd ask while this issue is open.

@AdrianKoshka commented on GitHub (May 17, 2019): new PRs will be built with AP, correct? So hypothetically someone could make a PR, and then we could link a release-installer in a comment on the PR? (Possibly automate that with a github action). I know it's unrelated, but I thought I'd ask while this issue is open.

gitea-mirror commented

2026-05-05 05:50:41 -06:00

Author

Owner

@nelsonjchen commented on GitHub (May 17, 2019):

New PRs would be build with AP. You can link the artifact download in comments though it appears to be one of those onClick() links so you'll have to download and then go into your browser's history to get the URL.

I'll have to investigate what other projects do. I haven't really seen linking. I think people just go into the build check details and download the artifacts. That said, there is a "Deployed" event that can be put onto a PR. Heroku uses it to great effect for pull-request deploys but I have never seen it used outside of that or for desktop software yet.

@nelsonjchen commented on GitHub (May 17, 2019): New PRs would be build with AP. You can link the artifact download in comments though it appears to be one of those `onClick()` links so you'll have to download and then go into your browser's history to get the URL. I'll have to investigate what other projects do. I haven't really seen linking. I think people just go into the build check details and download the artifacts. That said, there is a "Deployed" event that can be put onto a PR. Heroku uses it to great effect for pull-request deploys but I have never seen it used outside of that or for desktop software yet.

gitea-mirror commented

2026-05-05 05:50:44 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 17, 2019):

Right, fair enough.

@AdrianKoshka commented on GitHub (May 17, 2019): Right, fair enough.

gitea-mirror commented

2026-05-05 05:50:46 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 17, 2019):

I know there's a windows release installer created, but is there also a macOS release installer created?

@AdrianKoshka commented on GitHub (May 17, 2019): I know there's a windows release installer created, but is there also a macOS release installer created?

gitea-mirror commented

2026-05-05 05:50:47 -06:00

Author

Owner

@nelsonjchen commented on GitHub (May 17, 2019):

I haven't looked into that hard yet. It's built, but I'm not sure what the generated artifacts are or if there is a script making a DMG or ZIP like Window's build_installer.bat.

@nelsonjchen commented on GitHub (May 17, 2019): I haven't looked into that hard yet. It's built, but I'm not sure what the generated artifacts are or if there is a script making a DMG or ZIP like Window's `build_installer.bat`.

gitea-mirror commented

2026-05-05 05:50:48 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 17, 2019):

Understandable, and I don't think there is. @p12tic might be able to help with that.

@AdrianKoshka commented on GitHub (May 17, 2019): Understandable, and I don't think there is. @p12tic might be able to help with that.

gitea-mirror commented

2026-05-05 05:50:50 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 17, 2019):

I think there also might be an issue that detailed how to build on macOS and get a .dmg, could be wrong.

@AdrianKoshka commented on GitHub (May 17, 2019): I think there also might be an issue that detailed how to build on macOS and get a `.dmg`, could be wrong.

gitea-mirror commented

2026-05-05 05:50:52 -06:00

Author

Owner

@noisyshape commented on GitHub (May 18, 2019):

I don't know about AP, but building on Mac is simple once you have dependencies set up:

export B_BUILD_TYPE=Release and BARRIER_VERSION_STAGE=Release
Run ./clean_build.sh

build/bundle should then have Barrier.app which can be opened without installing and Barrier-2.2.0-Release.dmg.

@noisyshape commented on GitHub (May 18, 2019): I don't know about AP, but building on Mac is simple once you have dependencies set up: 1. export B_BUILD_TYPE=Release and BARRIER_VERSION_STAGE=Release 2. Run ./clean_build.sh build/bundle should then have Barrier.app which can be opened without installing and Barrier-2.2.0-Release.dmg.

gitea-mirror commented

2026-05-05 05:50:53 -06:00

Author

Owner

@nelsonjchen commented on GitHub (May 18, 2019):

Cool, thanks for sharing. We'll also need to see how we can pin the Mac
dependencies down. Can't have that free floating!

On Fri, May 17, 2019, 7:44 PM noisyshape notifications@github.com wrote:

I don't know about AP, but building on Mac is simple once you have
dependencies set up:

export B_BUILD_TYPE=Release and BARRIER_VERSION_STAGE=Release

Run ./clean_build.sh

build/bundle should then have Barrier.app which can be opened without
installing and Barrier-2.2.0-Release.dmg.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/debauchee/barrier/issues/308?email_source=notifications&email_token=AAABJ43ATQP5DXTSY76EZIDPV5URXA5CNFSM4HNNJ3D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWGFPI#issuecomment-493642429,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAABJ4336DFSHMOZDL2NCRTPV5URXANCNFSM4HNNJ3DQ
.

@nelsonjchen commented on GitHub (May 18, 2019): Cool, thanks for sharing. We'll also need to see how we can pin the Mac dependencies down. Can't have that free floating! On Fri, May 17, 2019, 7:44 PM noisyshape <notifications@github.com> wrote: > I don't know about AP, but building on Mac is simple once you have > dependencies set up: > > 1. export B_BUILD_TYPE=Release and BARRIER_VERSION_STAGE=Release > 2. Run ./clean_build.sh > > build/bundle should then have Barrier.app which can be opened without > installing and Barrier-2.2.0-Release.dmg. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/debauchee/barrier/issues/308?email_source=notifications&email_token=AAABJ43ATQP5DXTSY76EZIDPV5URXA5CNFSM4HNNJ3D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWGFPI#issuecomment-493642429>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAABJ4336DFSHMOZDL2NCRTPV5URXANCNFSM4HNNJ3DQ> > . >

gitea-mirror commented

2026-05-05 05:50:56 -06:00

Author

Owner

@walker0643 commented on GitHub (May 18, 2019):

Once you guys are sure that our new Azure solution is a complete replacement for both Travis and AV please @ highlight me and I’ll turn them off.

@walker0643 commented on GitHub (May 18, 2019): Once you guys are sure that our new Azure solution is a complete replacement for both Travis and AV please @ highlight me and I’ll turn them off.

gitea-mirror commented

2026-05-05 05:51:00 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 26, 2019):

#320 should put us one step closer to this goal.

@AdrianKoshka commented on GitHub (May 26, 2019): #320 should put us one step closer to this goal.

gitea-mirror commented

2026-05-05 05:51:03 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 30, 2019):

I noticed we don't have a downloadable "linux" installer artefact, I feel like this might not matter though? Flathub provides build artefacts. See: https://github.com/flathub/com.github.debauchee.barrier/pull/2. What does everyone else feel?

@AdrianKoshka commented on GitHub (May 30, 2019): I noticed we don't have a downloadable "linux" installer artefact, I feel like this might not matter though? Flathub provides build artefacts. See: https://github.com/flathub/com.github.debauchee.barrier/pull/2. What does everyone else feel?

gitea-mirror commented

2026-05-05 05:51:05 -06:00

Author

Owner

@nelsonjchen commented on GitHub (May 30, 2019):

I don't have much experience with Linux packaging nor any experience with modern Linux Desktop packaging. I did notice that VS Code and PyCharm, in addition to tarballs, are being officially distributed as Snaps from their download page which was pretty interesting.

@nelsonjchen commented on GitHub (May 30, 2019): I don't have much experience with Linux packaging nor any experience with modern Linux Desktop packaging. I did notice that VS Code and PyCharm, in addition to tarballs, are being officially distributed as Snaps from their download page which was pretty interesting.

gitea-mirror commented

2026-05-05 05:51:06 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 30, 2019):

Tarballs would be acceptable in my opinion for the type of people I expect to download build artefacts (though, perhaps that's naive). I don't have much experience either, it's why I went with flatpak, which I was familiar with.

in addition to tarballs, are being officially distributed as Snaps from their download page which was pretty interesting.

Hrmm

@AdrianKoshka commented on GitHub (May 30, 2019): Tarballs would be acceptable in my opinion for the type of people I expect to download build artefacts (though, perhaps that's naive). I don't have much experience either, it's why I went with flatpak, which I was familiar with. > in addition to tarballs, are being officially distributed as Snaps from their download page which was pretty interesting. Hrmm

gitea-mirror commented

2026-05-05 05:51:08 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jul 25, 2019):

@walker0643 At this point, I think it's safe to shutdown/remove appveyor and travis.

@AdrianKoshka commented on GitHub (Jul 25, 2019): @walker0643 At this point, I think it's safe to shutdown/remove appveyor and travis.

gitea-mirror commented

2026-05-05 05:51:11 -06:00

Author

Owner

@walker0643 commented on GitHub (Aug 9, 2019):

Done

@walker0643 commented on GitHub (Aug 9, 2019): Done

Rows
Columns

[GH-ISSUE #308] Turn off Redundant CI systems #248