Post on automatic pull request close

codewrecks/content/post/azdo/pills/automatic-pull-request-close.md

@@ -0,0 +1,85 @@
+---
+title: "Pills: "
+description: "."
+date: 2024-01-12T08:10:42+02:00
+draft: false
+categories: ["AzureDevOps"]
+tags: ["Pills"]
+---
+
+Pull requests are. surely one of the best features that you can get with git and an Austin provider like Github or Azure Devops. Sometimes especially with branches that need a lot of work and get a lot of feedback. closing the pull request requires some time. One of the most annoying thing is you prepare your pull request, then you need to change something because of some other user feedback. And then you need to retest everything.
+
+This kind of Workflow can make. closing a branch especially painful because you always need to switch to the branch and then re execute tests. Clearly, all requests are best when you have a really big suit of automatic tests. If possible, you need to include some end to end test, something that can build your solution, package your artifacts and then deploy in a test server and finally execute some basic tests to verify that some basic functionalities are okay.
+
+If you have such scenario it is. possible that you can automatically close a bull request when you. have approval from member of the team and all the tests are green. With this workflow if. all required member of the team approved your code if the tester green pull request is automatically closed without any other intervention. If some member of the team determine that you need to do some more work and the code is not ready to be merged, it can simply avoid to approve the pull request, put comment inside the code, and then after you fix the code the other members can verify if the new code is OK And when all the tests are green, everything is OK record. is automatically closed.
+
+![Options to automatically close the pull request](../images/automatic-pr.close.png)
+
+***Figure 1***: *Options to automatically close the pull request*
+
+As you can see, figure one. you can also choose the strategy you....ample, the picture I've chosen to use a rebase. Choosing to close a put request with the days allows me to have a linear history where each one of the feature is. absolutely in the same line and we have linear history. 
+
+Using rebates and fast forward is not the only option. You can also use rebase and squash where. all the comments that compose the branch that is about to be closed are squashed into a single commit so that only you have a linear history but each feature branch that get close with the pull request will be closed with only one single commit that contains all the changes of that pull requests.
+
+In figure one you can look also at other option You can see that you have the option to delete it your source branches one day request is closed and also to complete any work item that is associated with the full request. So not only you got your code merger to the base branch but you have also your work item closed and the original branch deleted from the procedure because it's not used anymore.
+
+If you have other Rose configure for the branch and the most common one is one or more build the UI allows you to check all the additional checks that are needed to be passed before the automatic close take place. If you have a large amount of tests you can. ask for the bill to complete a test to pass and so you are sure that your branch is not automatically closed if some of the tests fail. Just one important thing, the bill that you're using to check your food request need to completely fail to fade the test If the test execution phase is marked as failed partially the build, so the build completes and all the reports failing test, it will not prevent your branch to be closed. So be sure, in all the pipeline that are used for full request to make the pipeline run fail, if some tests are failing, this. cleavely required you that the build that you use in your full request have zero failure tests. 
+
+That is the reason why if you have some tests that are erratic or tests that are supposed to fail because they will be fixed in a subsequent release, you need to keep them away from the pipeline or use it to verify pool requests.
+
+If you prepare a more traditional approach, where you have merge and you do not rebase on squash anything, you can also use the classic rebased strategy. As you can see in figure 2.
+
+![Options to automatically close the pull request with merge strategy](../images/close-pr-with-merge.png)
+
+***Figure 1***: *Options to automatically close the pull request with merge strategy*
+
+Thanks to this option, you can open your pull request, then immediately set up your automatic completion. If all the required member of the team approve your request and all the tests are green, your branch will be automatically closed Your work item will be automatically close, and you can just open your pull request and forget. You just need to come back to your code if something gets wrong. So some test is failing or some member of the team do not approve your code.
+
+To make this technique powerful if possible, you need to have at least some end to end test that can verify passive functionality of your application. So you are pretty sure that how the get automatically merge does not break anything. And this is. not only for automatic approval. but also for standard approval.
+
+Gian Maria.
+
+---
+title: "Pill: Enhancing DevOps with Automated Pull Requests"
+description: "Exploring automated pull request workflows in Azure DevOps for efficient code integration."
+date: 2024-01-12T08:10:42+02:00
+draft: false
+categories: ["AzureDevOps"]
+tags: ["Automation", "Pull Requests"]
+---
+
+Pull requests are a cornerstone of collaborative software development, particularly with distributed version control systems like Git and platforms such as GitHub or Azure DevOps. However, managing pull requests can become cumbersome, particularly for **branches undergoing extensive modifications and receiving frequent feedback.** This complexity is evident when preparing a pull request only to find it needs additional changes due to peer review, necessitating a complete retest of the code.
+
+Such workflows highlight the challenges in finalizing a branch. Developers often find themselves continuously switching to the branch in question to **change the code based on other members feedback**, re test everything, signal to other members that the PR is updated then move to another branch and repeat. This is where a **comprehensive suite of automated tests, including end-to-end tests, becomes invaluable.** These tests should cover the entire spectrum of the development process: building the solution, packaging artifacts, deploying to a test server, and conducting basic functionality checks.
+
+> Having a good test pyramid implemented can make your life easier especially for pull request process.
+
+When this automated testing framework is in place, you can configure your DevOps workflow to auto-complete pull requests. This means that **when all conditions are met, Azure DevOps will automatically close the Pull Request for you**, without any manual intervention. Usually checks consists of explicit member approval, or team approval (where any member of the team can approve) and also all related check should pass. Here is what the system present you as options for automatic completion of PR.
+
+![Configuration Options for Automatic Pull Request completion](../images/automatic-pr.close.png)
+
+***Figure 1***: *Configuration Options for Automatic Pull Request completion*
+
+As shown in **Figure 1**, you can choose from different strategies for merging the code. For instance, **using a rebase strategy, as depicted in the figure, ensures a linear commit history.** With this feature, all the commit of the PR branch will be rebased on the target branch so you have a clear and linear history.
+
+Alternatives to rebasing include the **rebase-and-squash method, where all commits in a branch are condensed into a single commit upon pull request closure.** This maintains not only a linear history but also a shorter history where each feature branch will be contained in a single commit that reflects all changes made in that branch. **This solution can be avoided if you absolutely need to maintain identity of people for each commit in the branch**, a feature that is usually not needed (if you absolutely need it you have other problems).
+
+**Figure 1** also presents options that needs to be done after the code is merged. These include automatic deletion of source branch and completing associated work items. With these options when the Pull request will be closed you will have the **source branch deleted** and the **work item associated with the pull request closed**. 
+
+For branches with additional checks, such as build validations, the interface **allows for specifying which of the prerequisites you want to wait before automatic completion takes place**. 
+
+Note: It's critical to configure your pipelines to **fail completely if any test fails, because partial failures (where the build completes but reports failing tests) will not prevent branch closure.** 
+
+> For pipeline used in Pull Request check, you need to configure your build to fail if one test fails.
+
+This approach also accounts for tests that are known to fail intermittently or are scheduled for future fixes. Such tests should be excluded from the pipeline or not used for verifying pull requests.
+
+For those preferring a more traditional merge strategy without rebasing or squashing, Azure DevOps offers classic merge options, as illustrated in Figure 2.
+
+![Options to automatically close the pull request with merge strategy](../images/close-pr-with-merge.png)
+
+***Figure 2***: *Options to automatically close the pull request with merge strategy*
+
+For this automated process to be really effective you need to cover **the most functionality you can with the automatic tests, especially end-to-end tests** to validate the core functionality of your application. This ensures that **when the pull request is automatically merged, you can be confident that nothing is broken.** This is true not only for automatic approval but also for standard approval.
+
+Gian Maria.

codewrecks/content/post/azdo/pills/strange-error-building-net8.md

@@ -0,0 +1,20 @@
+---
+title: "Resolving .NET8 SDK Resolver Failure in Azure DevOps Pipelines"
+description: "A guide to fixing .NET8 SDK resolver failure in Azure DevOps pipelines."
+date: 2024-01-05T07:10:42+02:00
+draft: false
+categories: ["AzureDevOps"]
+tags: ["Pills"]
+---
+
+I encountered a problem with a simple pipeline designed for building a .NET Core project, which I had recently updated to .NET8. After updating the pipeline file to use the new version of the SDK, I faced an unexpected issue: **all builds started failing with this error**.
+
+```text
+##[error]src\Intranet\Jarvis.Common.Shared\Jarvis.Common.Shared.csproj(0,0): Error MSB4242: SDK Resolver Failure: "The SDK resolver 'Microsoft.DotNet.MSBuildSdkResolver' failed while attempting to resolve the SDK 'Microsoft.NET.Sdk'. Exception: 'Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadManifestCompositionException: Manifest provider Microsoft.NET.Sdk.WorkloadManifestReader.SdkDirectoryWorkloadManifestProvider returned a duplicate manifest ID '16.4.8968-net8-rc2'.
+```
+
+I was really puzzled because I had the same SDK directory on my computer, and it was workgin without any issues, **but failing on that build server**.
+
+Then I checked and I found a similar error due to **having preview version of a previous SDK installed in the system**. True to this theory, the build machine I was using had an old preview version of .NET Core 7 installed. Then I removed preview version and subsequently, the pipeline started functioning correctly again. Therefore, if you're facing a similar error in your pipeline, I strongly recommend inspecting your build agent to remove any SDK previews through the control panel that might be installed on your system.
+
+Gian Maria