Barrier: Turn off Redundant CI systems

[AdrianKoshka]

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

[nelsonjchen]

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]

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.

[TafThorne]

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

[nelsonjchen]

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

[AdrianKoshka]

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

[nelsonjchen]

Weird! The button appears for me now!

[AdrianKoshka]

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.

[nelsonjchen]

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.

[AdrianKoshka]

Right, fair enough.

[AdrianKoshka]

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

[nelsonjchen]

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.

[AdrianKoshka]

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

[AdrianKoshka]

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

[noisyshape]

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.

[nelsonjchen]

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 [e-mail] 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
.

[walker0643]

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.

[AdrianKoshka]

320 should put us one step closer to this goal.

[AdrianKoshka]

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?

[nelsonjchen]

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.

[AdrianKoshka]

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]

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

[walker0643]

Done