Azure Pipelines for Github allows build of plugin

Development
27

Azure Pipelines has started failing to build for me on Linux, and I’m pretty sure I haven’t changed anything. Here’s the error:

g++ -std=c++11 -Wsuggest-override  -fPIC -I/home/vsts/work/_temp/Rack-SDK/include -I/home/vsts/work/_temp/Rack-SDK/dep/include -MMD -MP -g -O3 -march=nocona -funsafe-math-optimizations -Wall -Wextra -Wno-unused-parameter -DARCH_LIN -c -o build/src/Follower.cpp.o src/Follower.cpp
In file included from /home/vsts/work/_temp/Rack-SDK/include/window.hpp:8:0,
                 from /home/vsts/work/_temp/Rack-SDK/include/rack.hpp:11,
                 from src/EntrianRack.hpp:6,
                 from src/Follower.cpp:16:
/home/vsts/work/_temp/Rack-SDK/dep/include/GL/glew.h:1205:24: fatal error: GL/glu.h: No such file or directory

The internet tells me I need to install libglu-dev or similar, but I didn’t need to do that previously, and I’m not sure it’s even possible in an Azure Pipeline. I’m using imageName: 'ubuntu-16.04'.

Is anyone else seeing this? Any workarounds? (Paging @baconpaul…)

28

Same error here…

29

I haven’t run my rack pipeline in a while - I’ve been heads down in surge proper - but we do a set of apt-gets in our pipeline. I would recommend an apt-get install libglu-dev or what not as a first attempt to fix this.

Here’s the point in our surge synth release pipeline where we do our apt gets.

3 Likes
30

Thanks, adding sudo apt-get install libglu-dev fixed it!

2 Likes
31

Thanks, Paul!

(Now I feel foolish for not just trying it - I just assumed that sudo wouldn’t be a thing in an Azure pipeline.)

1 Like
32

I encountered an issue with implementing the pipeline. It seems there’s a bug in azure where the Personnal Access Token isn’t recognized as such, which prevent uploading the release.

Error: Invalid GitHub service connection scheme: Token. Only OAuth and GitHub personal access token connections are allowed.

If anyone encounter this issue, I followed the workaround there : https://ljvmiranda921.github.io/notebook/2019/12/28/workaround-azure-github-pat/

And it worked !

Thanks again to @baconpaul for providing the guidelines and the script :sunny:

2 Likes
33

Just set it up for myself, thanks for documenting this! I’m using a azure-pipelines.yml adapted from the one @qno uses.

I ran into it too! I solved it instead by going, in azure, to Settings > Service Connections, and adding a new github service connection with the appropriate authorizations.

1 Like
34

Yeah, tried this at first but didn’t work for me. You’re lucky, took me a few days to get it working !

35

I see Microsoft are discontinuing the MacOS 10.13 VM - have any Pipeline users here moved to the next version, and did it cause you any problems?

“On March 23, 2020, Azure Pipelines will remove Windows Server 2012 R2 with Visual Studio 2015(vs2015-win2012r2), macOS High Sierra 10.13 (macOS-10.13), and Windows Server Core 1803 (win1803) from our hosted pools.”

36

I just checked by updating the images on a azure definition to:

  • imageName: macOS-latest
  • imageName: windows-latest
  • imageName: ubuntu-latest

It still works for me. I’m not sure if macOS plugin will work correct, because afaik the macOS minimum deployment target version 10.7 support is deprecated or even removed in macOS-10.14 contained XCode. Minimum supported version is now 10.9. It is set in Rack Makefile to -mmacosx-version-min=10.7 but Azure build logs show no complaints about this. Maybe this switch is useless for compiling a shared library in macOS.

37

I moved most of our pipelines to 10.14 (although haven’t built surge-rack in a while) and it seems everything works just fine. But I also build for 10.9 or 10.11 as my target in most cases.

1 Like
38

Hey, so, yesterday, after getting a PR to my repo, I was a little bit concerned to see that it triggered an Azure build that reported all steps were successful - including upload. While an incredibly unlikely attack vector, it’d remain one if people were able to push arbitrary code in binaries I distribute for beta testing.

So I ran a test: made a burner Github account, sent a PR, saw that Azure ran every step… but didn’t actually upload any new file to my releases. So that means the configuration we’re all kinda copying from each other has no issue on this front.

For reference, here’s mine:

I thought it was worth mentioning, since I don’t understand Pipelines well, and have no clue where the magic lies that protects me from this issue.

2 Likes
39

Well that’s quite different from where it started! But I don’t see anything in that pipeline that stops a publish on pr. We conditionalize on branch in the original rack one (but that is still has some vulnerabilities) and in surge proper use azure secrets and stuff to protect. At a minimum I would put some condition on the publish (like: not a PR) in that pipeline.

40

This https://github.com/AriaSalvatrice/AriaVCVModules/pull/58 should do the trick! :wink:

But your logs from PR CI build also says

References service endpoint. PRs from repository forks are not allowed to access secrets in the pipeline. For more information see https://go.microsoft.com/fwlink/?linkid=862029

So repo external PR’s don’t seem to be able to upload at all. Just your own PR’s.

See here - https://ariasalvatrice.visualstudio.com/AriaVCVModules/_build/results?buildId=429&view=logs&j=773bff40-edb6-5f2e-7b44-1cdc196fc707&t=17ce893b-824d-59dc-bd0f-7a8f1eb224eb

1 Like
41

Thanks! I changed it to build the development branch instead, since I use Azure to get development builds in the hands of testers

42

I’d like to mention that @qno has worked more CI magic on my repository, and offered a replacement for Azure Pipelines that uses Github Actions instead!

Now, I’m really no expert in this stuff, it’d definitely take me a whole day to set it up from scratch, so I don’t understand fully how it works, but I can confirm it works. While it’s tailored to my needs (e.g., it only uploads builds from the branch named development), I’m sure it will be useful to others. There was nothing to setup on Github (if you were to do it from scratch you’d just have to create a release to point to).

Here’s the file that takes care of everything:

43

Cool, are there other differences besides building only a certain branch?

I’ve been using an azure script that I’ve modified from yours to suit my needs (getting sources from gitlab instead of github and different message that prints the last changelog entry and time of build on the Release page).

What I’ve been wondering is if it is possible to update the release in a way that the time shown in the main page of the repo shows the correct most recent activity instead of when the release was first set up. Every plugin repo I’ve checked looked the same in this regard. And I feel it is misleading a bit.

I’m completely unfamiliar with Azure and Github actions.

44

Hello,

I want to mention that I already worked on a more generic approach of building a plugin with Github Actions that should mostly fit to developers out of the box. I created an example repository based on the Plugin Development tutorial code.

I will open a new discussion for this topic later.

3 Likes
45

Thanks, I was able to get what I needed by using this!

Here is what I ended up with

and here is the generated release page.

Now it shows the date of the build correctly!

46

Thank you, I used this, but changed it slightly to create dev builds with tag ‘latest’ if Tag wasn’t pushed and release builds if tag was pushed.