I have a build pipeline on Azure Devops which works fine. On first launch, the project is checked out, which is quite long, then the task is launched.
On the next run, the 'checkout' step is pretty quick and the task is launched.
The problem I have is that when I make a change in my sources - even the smallest - that is detected by the build, the checkout step is done again from scratch which is very long. I tried to find if there is an option in order to keep unchanged data but I couldn't find it.
As I don't clean sources in the initial tasks, I expected this step duration to be proportional to the source files changed...
i think the default is to perform a clean checkout, there are a couple of settings for the checkout process documented. I think your best bet is clean: false and fetchDepth: 1 (shallow checkout). I'm not sure the first one does what you ask for. second one will definitely speed up the checkout
Well, actually on another build I don't have the problem.
Updates are taken into account and the checkout phase lasts less than 10 seconds. I'll use that one as template.
Curiousely the 'clean' flag is set to true ?
Anyway, thanks for your help
Related
I have recently updated a CircleCI workflow that originally just had a test job, to have an optional deploy step that requires manual approval.
Previously on GitHub, the commit would get a green tick when tests were completed. However, now since there is a pending job in the workflow, it never changes to a tick unless the deploy job is also executed.
Is there any way to specify that I only care about the test job and give a tick once that job is complete, rather than waiting for the entire workflow to complete?
This screenshot illustrates the problem (notice the icon next to the commit sha1 is still "pending"):
Unfortunately this is still not possible in the CircleCI/GitHub integration (April 2022).
You can comment/vote here or here to hopefully help moving this up in priority...
I am wondering why my build pipeline for Azure DevOps is getting practically all the changes instead of just the most recent one?
I only made one change to 1 file, that didn't have an associated work item. This is what the change looks like. As you can see I have only changed one file. So why is it detecting all the changes?
I thought maybe it was because I didn't have this option enabled.
But even with that option enabled on a pipeline setup the EXACT same way all the changes are still pulled. Am I missing something subtle here?
There's an option on the pipeline to automatically link work items that are completed in a run.
You can edit the Pipeline and in the settings, tick Automatically link work items included in this run. You can pick * for all branches, or a specific branch.
Not sure what you did for your pipeline. Every time you change the files of repos for pipeline and then re-run the pipeline, it lists the changes for each build for the current project. This depends on how many changes you have made to the repo project since the last pipeline.
The below shows:
Then, click into the latest pipeline, and that is true, it will list all changes compared to the previous pipeline.
Click into it and you could get the detailed every single change.
In VSTS builds, is there a way I can know who have make changes in build steps?
Can I get history builds?
The reason for this is, we have a big team. Many time it happens that someone changes the build step for some reason and we never know who made the changes and why.
Like in git repo, we know which file is changed by who and why (in comments).
In VSTS builds, is there a way I can know who have make changes in build steps? Can I get history builds?
The answer is yes. You could check the History of the build definition:
Click on the three horizontal dots and we will get an option compare difference, through which we can know the details of the pipeline modification. If the modifier adds a note when saving the modification, we can also know the reason for the build pipeline modification.
I'm currently using AppCenter to Test my Xamarin app. The complete suite is being run at night. But I'm currently looking for a way to make this part of my CI builds to introduce an extra quality gate before features get merged.
However, we would need to slim down the amount of tests that need to be run otherwise this would become unmanageable. For this we can specify categories on our App Center test build step. When queued manually I'm able to specify the categories, however when we make this CI Build part of a branch policy and use a manual trigger for our build validation we are unable to specify the categories as we don't get the popup when queuing.
Any suggestions on how to adres this issue differently?
Seems you want to set build variables in pull requests when you queue the build under policies.
Unfortunately, this could not be achieved by now. It will not pop up the dialog when you queue the build. There has been a related uservoice, you could vote up and follow it, TFS PM will kindly review your suggestion.
Allow Setting Build Variables in Pull Requests
https://developercommunity.visualstudio.com/idea/365725/allow-setting-build-variables-in-pull-requests.html
The only workaround for now is editing the build definitions and add the variable under variables directly, then queue again. You could clone the original build definition first.
This trips up a lot of newcomers to TFS, and I'm keen to hear your solutions.
So you've fixed a bug, tested it, looks good, everyone is on top of you to get it out as soon as possible, so you queue a new remote build, wait patiently, then put it into test/production only to find out it's actually an old version - you forgot to check in before doing the build!!
OK, so this is a common oversight, and it costs valuable time. Is it possible to pop up a warning first, or is there some neat trick other have found to avoid this?
Instead of manually kicking off a build after you check-in, what if you set up a "Continuous Integration" build so that the build would be automatically kicked off once you checked in? This way it would be impossible to forget to check in your changes. Here is an article on how you can set that up: http://msdn.microsoft.com/en-us/library/bb668971.aspx.
Continous Integration as mentioned above is the best solution! :)
But you could write a custom activity within your build definition to check if there were any new changesets since the last build and if there is no new changeset show a warning message in the build log or something, but then again the developer has to read to log otherwise it's not useful.
I wouldnt spend any time at all for something like this, I would rather knock on the developers head everytime he misses the check-in! :}