I have a bunch of Azure Pipeline and Release packages. The piplines build and publish my code to a testing environment every night, and as part of that publish they create artifacts used by the selenium testing software.
This has been working correctly for several years now. Sometime around the last upgrade we did to Azure Devops the artifacts have started getting deleted after about a day instead of honoring the deletion schedule that I have setup.
The artifacts are generated by the pipeline packages and used by the release packages, and everything is working correctly. However sometime after the last release has finished running for the night, all the artifacts get deleted. I have tried running the entire process manually, and when it is done the artifacts still exist (at least until the next day - I haven't identified a specific time they get deleted), so the issue does not appear to be within any of the packages themselves.
The Settings Retention policy, I believe these apply to the pipelines.
The Release Retention policy, obviously these should apply to the release packages.
Does anyone have any idea why my artifacts are not sticking around past 1 day?
It seems I have figured out the problem, and it appears to be a change in the way Azure Devops works with the newest version. This is the first version I have noticed this issue in:
Azure DevOps Server 2020 Update 1.1
The settings indicate that artifacts should be kept for 20 days in my instance. However, every time I run a build it over-writes the existing artifacts with the newest ones. My guess is that this artifact path gets tied to the build in the database. And since all artifact paths are identical in my case (something that did not occur to me to mention in the original post), deleting an artifact that is 20 days old will delete the data from the current artifact path as well.
I solved this issue for myself by including $(Build.BuildNumber) as part of my artifact path. Unfortunately you cannot directly use a date variable in that path, however since I have the date built into my buildnumber this approach worked for me.
Related
I have a build done for a ASP.Net project.
In code I have updated the names of several fields in an HTML but, when the build is launched and published, it never updates the changes I have made.
It always takes the original version to create the artifact.
I have deleted and created the build from scratch, but it always does the same thing.
What can I do?
I have more builds just like this one and this doesn't happen.
Best regards,
Have you checked the commit version of your pipeline?
It may due to your pipeline using another branch, which is the original version.
I am trying to add an Artifact to a release pipeline. Within the dropdown of the "Source (build pipeline)" there are two options for the same build pipeline.
Apple
Apple
Apparently at one point, someone created the first build pipeline and named it Apple, then deleted it and later on created a new build pipeline with the same name.
What this means now is for my release pipeline, it ONLY references the first one and so throws an error that the artifact does not exist. The first job has id 15 the second has id 140.
If I export it always references the 15 regardless of which I select int he dropdown.
If I export, edit and import, it overrides the 140 with the 15.
So basically I cannot create a release pipeline and reference this artifact.
I could rename my second pipeline but the ripple impact on other areas would be a pain to correct.
What can I do to clear/delete/free this original orphaned build pipeline? Is a Microsoft support call my only hope?
What can I do to clear/delete/free this original orphaned build pipeline? Is a Microsoft support call my only hope?
I have create a sample to test this issue, but could not reproduce this issue on my side.
You could try to login the azure devops in private mode, then remove the artifacts and re-add it, check it.
If above still not help you, you could use Rest API to restore the deleted build pipeline:
Here is the Rest API:
PATCH https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?deleted=false&api-version=5.1
It could restore the deleted build definition and build history.
Here is my restored pipeline:
After restore the old build pipeline, we will get the the artifact from the new restored pipeline:
Besides, you could also try to rename the old pipeline with Id 15 after you restoring it.
I am trying to find the most correct and simplest deployment process for each application release we have. The difficulties are the following:
It is Azure DevOps Releases.
Application has more than one artifact that should be delivered as a whole. Application distro, Its modules, and some configuration for servers that are not directly linked with the application, and of course automation scripts (which is versioned). All of them have their own build process and can be versioned separately.
All those components (App, separate server config, automation) are delivered as one product version. However, they could have different versions, for example: 12.2.1 (app), 12.2.3 (server), 12.2.1 (automation).
The question is how to build the process when after release (official), we can stick all of the final versions together (i mean not specifying them manually during pipeline release creation for each) taking into account that one of the component's version can be increased and we should be able to increase the version for release in terms of hotfixes for example.
Release Pipelines and 3 Artifacts: ok, there are 3 artifacts and a user has to specify all 3 versions manually during creation - quite a high risk to misclick. Unfortunately, there are 10 of them... 10 multiply 3 = 30 times to do a mistake.
Release Pipeline and 1 Artifact (app): Consider only one version of the application and automatically obtain automation scripts and configuration from feed by using app version. Could work, but no observability on what artifacts are going to be used, no way to downgrade, the only the latest version of artifacts (12.2.3.*).
Specify the version in the variable group connected to the stage (environments). Can easily make a mistake because release uses the baken version of the variable group. If you update VG, but not create a release - it will be epic fail. Moreover, there is no vision of what it is going to install/update, etc.
Please, share your ideas on how to manage multiple artifact versions within one product release to make the process more robust and clear with a little of flexibility.
That's how it works for me via this simple approach:-
A single build pipeline with many Agent Jobs where each one represents an artifact.
So here you will publish the different artifacts under separate folders and automatically increase versions "If needed", using a script per each and at the end all will be under the same BuildId.
Another variety if separation isn't needed that all be under the same Agent Job.
A single release pipeline that is linked to this big nested artifact that will perform the deploy.
Here also if separation is needed, could have multi stages or multi Agent Jobs as before.
Versions increasing either will happen manually at commits or scripts will automatically increase each build.
I would prefer the first as the 2nd doesn't indicate that there was any change.
The possibility of developer forgetting to update the version will be the same as developer introduces a bug so that can be fixed later.
Then at the end, you have a Single Release => Single Build => Many versions => A commit.
I have been searching and have not been able to find a solution to my issue of being able to run a task prior to the build being deleted by the retention policy of the project in VSTS. Here's my current setup:
Build runs, uploads artifacts to Artifactory.
The URL to the artifact is stored in the properties under build summary.
Project retention policy runs and removes builds that meet criteria.
Corresponding artifact in Artifactory remains.
What I want to do is, up on deletion of the build in VSTS, that somehow attach to the pre-deletion of the build and run a task to delete the corresponding artifact in Artifactory. Then continue to delete the build in VSTS.
Is this possible? Is there something I was missing when trying to search for this?
For this issue, from my point of view, it is impossible to remove external artifacts pre-deletion of build by project retention policy.
Because your retention policies are processed once per day. The timing of this process varies because we spread the work throughout the day for load balancing purposes. There is no option to change this process. So we can't track when the builds were deleted and cannot delete the corresponding external artifacts in the pre-deletion of the builds. For details ,please refer to this document.
You can through Artifactory Discard Builds task to remove build artifacts stored in Artifactory. Check the Delete artifacts checkbox, to also delete the build artifacts and not only the build meta-data.
I am using Azure DevOps pipelines releases to try to deploy a windows service on premise. Periodically, the windows copy files step will hang and try again every 30 seconds and output "The process cannot access the file because it is being used by another process" as it attempts to copy the build artifacts.
We've ruled out any kind of permission issue. We've tried all sorts of tools to see what might be locking these files up and they don't tell us much.
This has happened before in the past with some other projects I was also trying to release on premise. Sometimes, I am able to just wait an hour or two and redeploy successfully (not exactly a solution I'm satisfied with), but this one particular project, a windows service, seems to be experiencing the issue very, very frequently. Almost every time I try to deploy.
Has anyone else experienced this? Or any word from Microsoft on the issue?
Thanks in advance.
I experienced this issue while trying to create and deploy a release from an existing artifact. So I have a build pipeline on Azure Devops that generates artifacts to be used by the release pipeline. All I did was to make a commit that triggered the build pipeline which generated a new artifact and triggered the release and it worked fine.
It was the first time I experienced this and I had no clue on why it happened.
I'm going to be doing more research and share any thing I find helpful.