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...
Related
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.
We are currently checking the test plan module on our Azure Devops server and I'm facing an issue that the community may help.
According to this once a test run has been marked as failed or blocked there is no way to resume the test once the raised defects have been resolved. You either have to mark the test run as paused (so as to be granted the "resume" option) or reset the whole test to active in which case you loose all your progress and need to start over. Two questions:
This "workaround" works as long as you are careful and save the test run as paused. Otherwise if a failed step exists the run is saved as failed. Once this is done I have found no way of changing it to "paused" so as to get the resume option. Is there a way I'm missing?
In the test list under a specific suite you get the current test run outcome and state of test case. In case of "Paused" you don't have a way to know if the test execution is paused or you are utilizing the aforementioned workaround (e.g. a bug is registered). I cannot see a way that I could enhance the test run with some information that would signal this (there is no wit template I have found) on the grid. So is the standard query module (bringing testcases and associated bugs with state) the only way?
thanks
For the first question, if the test case is on status Failed and you retest the test case, all test steps need to be redone. Also there is no resume-button. This is by design. For now, set the status to Paused can resume the test, but it cannot truly reflect the result. As far as I know, there is no other way.
You could add your request for this feature(For example: when status = Failed/Block, the restore button is enable) on our UserVoice site , which is our main forum for product suggestions.After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it.
For the second question, as workaround , you can also add tags to paused test cases for labeling.
My understanding is if the bug was in Activity, the new code will be used since Activity does not have the concept of version. But what if there is a bug in Workflow code and causing some workflows to fail (or even worse, not fail but stuck), we fixed the bug and deployed the new version, but those failing workflows are stuck on old versions. Is there a way to automatically move those failed / stuck workflows to new version and re-run them?
This happening a lot to us because we just started to learn to use Cadence/Temporal
Thank you in advance!
It depends on the bug.
For bugs that cause workflow to get stuck (in Go a nil pointer dereferencing causes panic which blocks the workflow progress by default) deploying the new version of the code is usually enough to unblock them.
If the bugfix requires backwards incompatible change then the best option would be to reset workflow to the point before the bug. This way workflow will be rolled back and continue through the new code.
For situation when the breakage of workflow code is caused by a new bad build you can rollback the workers to the previous build and mark that build as broken and all workflows going to roll back their state to before that build automatically. See "Recovery from bad deployment" section of the Temporal documentation.
If you are using ElasticSearch integration then you can also perform batch reset of multiple workflows using a predicate to select workflows that match some criteria. See "Signal, cancel, terminate workflows as a batch job" section. Besides the name of the section the batch jobs apply to reset operations as well.
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
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.