Drop support for CI builds using Azure Pipelines #5389
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Trying to reinstate support for Azure Pipelines is somewhere between heroic and futile. I originally tried to do this because it was highly valuable to be able to run Git's test suite in a private Azure DevOps project when developing embargoed releases. Now that upstream drops even more Azure Pipeline support code, it is time to declare defeat. Signed-off-by: Johannes Schindelin <[email protected]>
contrib/buildsystems: drop support for building .vcproj/.vcxproj files Before we had CMake support, the only way to build Git in Visual Studio was via this hacky `generate` script. For a while I tried to fix whenever things got broken, in particular to allow building confidence in embargoed releases by running the CI builds in Azure Pipelines in a private Azure DevOps project. I even carried the patches in Git for Windows with the intention of upstreaming them, eventually. However, it is a lot of work with too little benefit. CMake is much better supported by Visual Studio. So let's drop this hacky script (plus support code). Signed-off-by: Johannes Schindelin <[email protected]>
Now that we dropped `contrib/buildsystems/generate` to generate Visual Studio Solution files, it is time to also drop the `vcxproj` Makefile target that depended on that script. Signed-off-by: Johannes Schindelin <[email protected]>
mjcheetham
approved these changes
Jan 30, 2025
dscho
added a commit
that referenced
this pull request
Feb 7, 2025
This PR introduces a merging-rebase purely to reorganize what is in this fork's default branch. The main clean-ups are: - The backports that were needed to apply the security fixes to upstream Git's `maint-2.40` (which was not maintained very well, failing CI builds) were dropped; They are already part of v2.48.0 (they were backports, after all). - The fall-out of #5389 (I moved the patches that drop Azure Pipeline/`vcxproj` support to the beginning, and then dropped all of the patches that modified the now-no-longer-existing parts). - I also moved the security fixes to the beginning. - `fixup!`s were applied. - Combined many of the `fscache` topics into a single one. Who knows whether I will upstream this topic at all, it's somewhat incompatible with partial clones, and FSMonitor might turn out to be good enough on its own (FSCache would help the cold-cache scenario, though). All in all, there are still a little under 300 patches (291, to be precise, down from 319) organized in a little over 100 topic branches (102, to be precise, down from 121). I have to admit that I am a bit satisfied by the outcome. Note that the outcome is strictly tree-same, i.e. this PR's combined diff is empty. GitHub complained about a "too long PR body" so I'll post the range-diff as a follow-up comment.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A long time ago, we used Azure Pipelines for CI builds. Eventually, when GitHub Actions was spawned from Azure Pipelines, we moved over to that system for CI/PR builds.
However, I've tried to keep a working Azure Pipelines definition around for the embargoed releases, to be able to increase confidence in the patches by running the full CI build in a private Azure DevOps project (we cannot do the same on GitHub because even the very generous offer of 50,000 build minutes per month is no match for Git's test suite).
It took a lot of work, and it would take even more work what with upstream's "remove stale code for Azure Pipelines" part of
ps/ci-misc-updates.Time to let it go.