@lextm ubuntu1804 lane is failing

The failure was not caused by the changes, but instability around NuGet package restore. You can see the same changes work in https://github.com/lextm/dotdevelop/actions/runs/470535881

Well, you could squash the 2 commits into 1, to see if next CI run passes.

I intentionally left two commits, as that illustrated clearly why Makefile needs to be modified.

Two GitHub Actions runs in my fork can be used as reference,

• Initial commit to add more Ubuntu versions, https://github.com/lextm/dotdevelop/actions/runs/470472832 Failed due to incorrect PATH modification in Makefile.
• Second commit to modify Makefile https://github.com/lextm/dotdevelop/actions/runs/470535881 Passed.

My suggestion is that if you push with your --force in your branch, the CI will run again and that ugly red (x) will disappear. If you don't want to squash, you could just change the commit message of last commit slightly (e.g. with git commit --amend).

PS: Actually, thinking more about this, are you sure squashing the 2 commits into 1 is not the right approach? Because if you push the commits one by one, the first commit's CI would break, right?

The rule of GitHub Actions on pull request creation is that it only triggers a single run, no matter how many commits are there. That's why there was only one run for this pull request so far.

I know I can modify on my side to trigger another run (squash or whatever), but the repo owner can force rerun the workflow from Actions tab, which is a far more common way to resolve instable CI builds.

no matter how many commits are there

Not 100% accurate statement: it triggers a single run per push, so if you have 2 commits, you could push 1 first, and the 2nd later, in order to have CI run in each of them. I even did a script myself to push this way: https://github.com/nblockchain/fsx/blob/master/Tools/gitPush1by1.fsx

But even if you could not do the above, it's always preferable that CI is not broken in between commits, because it prevents bisections.

but the repo owner can force rerun the workflow from Actions tab, which is a far more common way to resolve instable CI builds.

Well, if you had proposed this PR from your fork, you wouldn't need the repo owner to help ;)

Will rebase to 8.6 branch later today.

After rebase to 8.6, all checks now passed.

Can you do two pushes to check if 0e1dde1 also passes CI? (if it doesn't, then they should be squashed into 1)

nice!

centos was fine, add it again? https://github.com/dotdevelop/dotdevelop/actions/runs/446259191

https://github.com/lextm/dotdevelop/blob/878a534e914362df95bbc1c1861d84329b8c7324/.github/workflows/monodevelop.yml#L13-L37

@lytico I plan to add CentOS and Fedora in a separate pull request.

Can you do two pushes to check if 0e1dde1 also passes CI? (if it doesn't, then they should be squashed into 1)

FYI I've copied your branch to my fork, but doing one push per commit, and the first commit breaks CI:
https://github.com/knocte/monodevelop/commits/ubuntu-ci

So this is proof that, strictly speaking, the commits should be squashed into one before merging (or when merging). Having all commits pass CI is a good practice, to easean the work of future developers when bisecting problems.