LC0051 and download of pre-release

[NAVFreak]

This was not nice of you! 😝 We are using secrets in our pipeline and it blanks out numbers warning LC005***: Possible overflow assigning 'Text' to 'Code[***0]'

My colleague called me in despair and said he couldn't remove it with pragma disable LC0050 since it was the only one listed on 50

However, I wonder how to trigger newest release from VS Code. I have ticked pre-release setting but when does it download? Now I had to use the pipeline ps script to download it manually into the folder so I could see that it was actually LC0051.

[Arthurvdv]

My apologies 😳 We try as much as possible to avoid breaking pipelines and this was probably an unpleasant experience for your colleague.

I have a question though: Is it an deliberate choice to run the Pre-release version instead of the Latest (stable) version of the LinterCop in your pipelines?

We only run the Latest in our pipelines and some of us use the Pre-release on their VS Code so we can gather feedback on new rules. It also isn't helpful that your current setup hides the numbers. If you want we can have a call to see if we can improve this, where I also can share our current setup of our Azure DevOps pipelines what works for us.

Because the new LC0051 rule is only available in the pre-release, you'll find the documentation on this in the prerelease branch. In the wiki the documentation on this rule is already available.

When introducing new rules we are reluctant to have these on a warning level as default severity. This so we don't break to much pipelines out there with a new release. In the case of the LC0051 rule i thought is was justified to have this as a warning as default severity level.

[Arthurvdv]

I have ticked pre-release setting but when does it download?

I see i forgot to answer your question on this.

I believe it works best when no AL project/workspace is open in VS Code. This because the AL Compiler wil lock the .dll file where it can't be updated.

[NAVFreak]

I have a question though: Is it an deliberate choice to run the Pre-release version instead of the Latest (stable) version of the LinterCop in your pipelines?

To be honest, I didn't know we were running pre-release until a month ago. Then I was, I will fix it later. I guess I have to blame all those late nights of troubleshooting pipelines. But now when I looked into the code I think I have found the reason for that.

To my defence I was uses using example code 😜 Source: ALOps Custom Code Cop

It also isn't helpful that your current setup hides the numbers. If you want we can have a call to see if we can improve this, where I also can share our current setup of our Azure DevOps pipelines what works for us.

Tell me about it! The amount of hours troubleshooting which symbols version the pipeline was used 😣 Instead I have a habit of converting numbers to text representations 1 => One when displaying files in the build folders. But that seems to be due to the fact that we store our secrets in Azure Key Vault, read more and because of that it automatic masks numbers in pipeline console..

I see i forgot to answer your question on this. I believe it works best when no AL project/workspace is open in VS Code. This because the AL Compiler wil lock the .dll file where it can't be updated.

That is nice! Will start use that. I did a powershell script yesterday to do this and I also noticed that VS code needed to be closed or as you say, projects closed.

[Arthurvdv]

To my defence I was uses using example code 😜

Fair point 😅 I've created an PR so that the example code does what you would have expected it to do.

our secrets in Azure Key Vault

We also retrieve secrets from an Azure Key Vault in our pipelines and do not experience the same issue as you.

I'm guessing based in the info on the Please! make a setting for showing unimportant numbers in task there, that the "..it is both "real" secrets and settings.." maybe is the reason. Settings are not secrets, so should not have to be in a Key Vault.

In the beginning also try'ed that approach, with the goal to have settings available cross multiple projects. I've changed that to use templates. Also 05_MultiVersion_pipeline.yml is an nice example for inspiration.

[Arthurvdv]

I believe we've resolved this for the moment (awaiting PR) and going to close this issue. Feel free to reopen this issue if you're still experiencing problems.