[ISSUE]: Azure DevOps task v3.1.1 fails with 'Overwriting readonly variable is not permitted' #1400
Comments
|
I'm afraid I don't have the capabilities to offer a PR, but this is the second time this has happened in less than a month. It might be worth adding a test to make sure that the |
|
It's not clear to me how or why this change done in 3.1.1 introduced a regression if it's just putting back the functionality removed in 3.0.4 (as indicated in this issue), but the impact appears to be even more severe. With 3.0.4 the workaround was just switching to variables with Strangely, though -- not all my pipelines fail when using 3.1.1. Some get the error above while others work just fine. I have not identified what makes them different. Also interesting is in the 3.1.0 version the variables with |
|
@mryandot @SeanGriffin-Wellsky the task is also run as part of this repository and I don't see any similar errors. It seems in your case most probably there is a pipeline policy that does not allow to override variables. Some information I found https://github.com/microsoft/azure-pipelines-yaml/blob/master/design/readonly-variables.md. I will see if I can do anything from the task itself |
|
@jochenjonc @mryandot @SeanGriffin-Wellsky mind to let me know which agent version you're using where you have this issue and if it's Azure hosted or self-hosted. In my case it's Azure hosted, agent version: '4.248.0' |
|
@arturcic I am running the tests with a clean pipeline on the One of the first issues I ran into that gave me hope was realizing the I switched to running the tasks directly and tried both So I tried again setting it to 6.0.x and it did run, but returned the same errors. Finally I switched the task to use I did look at the logs you linked to, but they appear to be running PowerShell tasks which run |
|
@arturcic I'm using an Azure Hosted agent with |
|
I'm like @jochenjonc: Azure Hosted agent, ubuntu-latest, v4.248.0. That said, I've another pipeline that succeeds that also runs on Azure Hosted agent, ubuntu-latest, v4.248.0, but it's in a different ADO project and also does the build inside a container rather than on the base host. Both pipelines use this for their task execution: - task: GitVersion/setup@3
displayName: 'Setup GitVersion'
inputs:
versionSpec: '5.x'
- task: gitversion/execute@3
displayName: 'Run GitVersion'
inputs:
useConfigFile: true
configFilePath: '$(System.DefaultWorkingDirectory)/GitVersion.yml'I've locked my task version at 3.1.0 to workaround the issue for now. |
|
I've done some more testing and I'm still not having luck narrowing anything down without knowing how to debug the task itself. If I use PowerShell to do a Basically using |
I wonder if it's and organization/project setting in ADO that can be set to mark the variables readonly or not. In the GitTools organization where we actually test the code, as I mentioned I don't see this error, that means there should be a setting |
The thing is the tasks install and then run the dotnet tool GitVersion.Tool which internally detects that it's running in Azure Pipelines and sets those output variables using the "." syntax https://github.com/GitTools/GitVersion/blob/c63c1a30d0e77be2d7d9fde7aa6c0e6b91275c24/src/GitVersion.BuildAgents/Agents/AzurePipelines.cs#L15. The task does the same actions/src/tools/gitversion/tool.ts Line 61 in 1aabac0 In some instances that is allowed to override, in some it's readonly. |
If the task installs GitVersion.Tool, and GitVersion.Tool sets the . properties, then why does the task also need to set it? Is it because there's a possibility of the GitVersion.Tool being a version that doesn't set the . properties, instead relying on the task itself to do so? I poked around in all the settings I could find at the project level in ADO and didn't see anything about setting output vars to readonly. Both my projects (the one that succeeds and the one that fails) are in the same ADO Organization. I do not have access to view org-level settings. When I browser search for "Azure DevOps sets output variables to readonly" I get this summarized AI answer
But I cannot find the definitive source from Microsoft stating this. |
|
@arturcic I have successfully replicated your pipeline which builds the tasks, then calls node in PowerShell tasks to invoke them, and it works just fine. I suspect that PowerShell may not have the same protections in place that other tasks have for read-only variables. It does appear in the output that the Output variables are set before the non-output; is it possible to test reversing the order without using PowerShell to do it, or would it require a new release? |
|
Hi, |
You can reference the specific task version in your pipeline: |
|
Hi Mike, I'm not able to provide a specific version in the marketplace. Also it doesn't recognize the specified version:
A task is missing. The pipeline references a task called 'gitversion/setup'. This usually indicates the task isn't installed, and you may be able to install it from the Marketplace: https://marketplace.visualstudio.com. (Task version 3.1.0, job 'Job', step ''.) |
|
@inventgroep Then that specific version is likely not installed in your organization. Check under "Manage Extensions" for the GitTools extension to see which versions are listed, and try using one of those older versions. |
|
@Mikebeem We use Azure DevOps online, not on premise. It's impossible to install or use an older version. On the 10th of December it was automatically updated from version 3.0.4 to 3.1.1. Can you tell me when this issue is being fixed? |
|
@inventgroep then you can try to use version 3.0.4: No I don't know when it is fixed. I'm just an Azure Devops online user like you. |
|
Hey guys, what would be a safe way to test this extensions before publishing it to the GA? I need your feedback |
|
I can, but tomorrow at 13:00 (GMT+1).
Thanks,
Wietse
From: Artur ***@***.***>
Sent: dinsdag 17 december 2024 09:22
To: GitTools/actions ***@***.***>
Cc: Wietse Kok ***@***.***>; Mention ***@***.***>
Subject: Re: [GitTools/actions] [ISSUE]: Azure DevOps task v3.1.1 fails with 'Overwriting readonly variable is not permitted' (Issue #1400)
Hey guys, what would be a safe way to test this extensions before publishing it to the GA? I need your feedback
—
Reply to this email directly, view it on GitHub<#1400 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIHPHEU5WD5XSGLMOGNQXDL2F7NMFAVCNFSM6AAAAABTMZ5VZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBXG44DANRWGQ>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
well I'd prefer to have a "preview" channel or something where the community can test their pipelines before upgrading the GA extension, and provide feedback |
|
@arturcic I have an "experimental" DevOps instance specifically for testing build changes (templates, extensions, etc.); if I could choose to connect it to a preview version of the extension without forcing our main instance there, I'd be willing to test it there before a new release; I'd just have to get notifications set up so I can do it in a timely manner when you want to release a new version. That said, the only issues that have broken releases for us so far have to do with that output-implies-readonly-except-for-powershell issue, which I would think could be caught with a unit test on the build output. I would guess most other errors are caught using your current method for running your builds with the new task code. |
|
I guess we can use the GitHub releases for that, and if it's a preview then it publishes the preview version otherwise the stable, and if you follow/watch the GitHub releases, then you will be notified and provide the feedback for preview before we get the stable out |
|
The whole problem here is the automatic-updating of marketplace extensions with no ability to manage upgrades in hosted Azure DevOps. As far as I can find, if it's not a separate product in the Marketplace, then we can't manage what version gets installed when, and we can't install the newer version from the GitHub releases. It seems like it would have to be a separate product in the Marketplace to do any kind of practical preview. Is that an option? The only other way around it is to lock to an explicit version of the task in the pipelines, and only update that after testing. |
There is actually an extension with a different name which is unpublished for now, but it can be used for this purpose, I still explore the option and keep you posted here |
|
I think, that would be a good option.
I changed my complete pipeline and the errors are gone. If you like, I can find out to in which situation the error occurs and provide a sample pipeline.
From: mryandot ***@***.***>
Sent: dinsdag 17 december 2024 18:33
To: GitTools/actions ***@***.***>
Cc: Wietse Kok ***@***.***>; Mention ***@***.***>
Subject: Re: [GitTools/actions] [ISSUE]: Azure DevOps task v3.1.1 fails with 'Overwriting readonly variable is not permitted' (Issue #1400)
The whole problem here is the automatic-updating of marketplace extensions with no ability to manage upgrades in hosted Azure DevOps. As far as I can find, if it's not a separate product in the Marketplace, then we can't manage what version gets installed when, and we can't install the newer version from the GitHub releases. It seems like it would have to be a separate product in the Marketplace to do any kind of practical preview. Is that an option?
—
Reply to this email directly, view it on GitHub<#1400 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIHPHEQZS5L6R7F5POA6YT32GBN53AVCNFSM6AAAAABTMZ5VZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZGEZDGNJVGA>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
That will be really helpful |
Prerequisites
GitVersion package
AzureDevops task
What are you seeing?
Yesterday after the release of v3.1.1 builds started failing, we still had the following config at that time:
We could see it was using v3.1.1. When we set the version fixed on v3.1.0 builds are working again.
What is expected?
A working build ;-)
Steps to Reproduce
Output log or link to your CI build (if appropriate).
The text was updated successfully, but these errors were encountered: