Azure Functions in VS Code Plugin doesn't find subscriptions - visual-studio-code

I'm developing an azure function in VS Code. I have the Azure Functions extension installed.
I have created the function and its running locally just fine.
But when I sign in to azure using the extension it does not see any of my Azure subscriptions. Therefore I can't select a subscription and deploy the function.
Has anyone else encountered this and found a workaround?

I had the same problem and I was able to sign in by clearing the azure tenant id in the azure extension settings for VS Code

You can try to the following ways to troubleshoot.
1.Go to azure portal and login your account to check if the account has active subscription listed.
2.In VS code, try to sign out and sign in again.
3.Use the below script with azure cli to login your account
az login --debug
4.If you have set MFA for your account, re-open the browser and re-login to the portal, which triggered the wizard for me to configure all needed for MFA authentication. After that, az login works again.

Move your mouse to there, you will see a filter icon.
Click it, then you will find all subscriptions.

Related

No subscription of azure on eclipse

I am trying to deploy my web app on azure but no available subscription is appearing where I have already subscribed in my azure account .
Check the subscriptions available on your Azure account
In the Eclipse >Tools>Azure>Sign-in
You can sign-in with device login or using Service Principal.
Here I have signed with device login - After clicking on device login you have to copy the code from Eclipse and paste the code in browser and then the final step is Logging into Azure using username password or Current user if already signed-in.
Refer here for more information on signing to Azure account using Eclipse.

security button Azure Devops Disappeared

yesterday i installed Azure Devops 2019 (2020) and everything was ok.
i created my first collection
then i granded permission to my friend as collection administrator in its group
then we checked this button and grant permission to others via panel
But today security button hide for both of us (today my security button disappeared and gone )
You can try deleting and redeploying the Azure DevOps server to see if there is still the question.
By the way, you can use the REST API to view the security of the collection. This REST API was not documented, and I found it using the developer console (F12 in most browsers).
GET https://{instance}/{collection}/_settings/security?__rt=fps&__ver=2

Cloud Build service account not created when API enabled - Cant deploy app

I am having issues deploying an update to a current app which was last deployed in July 2019.
It asked me to enable Cloud Build.
I had to first enable billing account for the app. I did this. I then enabled the cloud build API.
I now get a permission denied error when I run gcloud app deploy. The docs say to check the service account permissions, but when I load that page it says I need to enable the Cloud Build API. I click on the link and it shows me that the API is enabled. I click manage, go settings, and it says "The Cloud Build API needs to be enabled before changing the permissions of the service account."
Usually enabling an API takes few minutes before you can use it. Can you try again deploying your app?
Additionally, you don't need to add any new permission to your cloud build service account unless you are using cloud build in some kind of CI/CD pipeline. in That case you need to ⁠add some few more permissions to this service account.
You can always check which APIs are enabled using ⁠gcloud command line.
I'd suggest try to disable and re-enable the API, wait for a few mins and try again.
UPDATE:
The issue described might be a result of a known issue.
I suggest you star this Public Issue to stay updated.

How to access VSTS work items from testing code which running on V2.x VSTS agent?

We run our E2E automation test on build agent (V1.105.xxx) after the build is successfully. The test code leverage Visual studio Unit Test framework to access VSTS work items to load test data using data driven approach (each test case method linked to one test case work item):
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.Tes‌​tCase","https://myaccount.vi‌​sualstudio.com/Defau‌​ltCollection;MyProje‌​ct";, "1111111", DataAccessMethod.Sequential)
And we run our V1.x build agent in interactive mode with PAT auth as follows:
C:\agent\agent\VsoAgent.exe /Login:e2etest,xxxxxxxxxxxxxxxxxxxx;AuthType=PAT
But we could not find a way run V2.x agent with PAT auth so as to access the VSTS work items.
Is it still supported in V2.x agent?
When use PAT to configure build agent, the PAT token is used only for the initial configuration of the agent. More information, you can refer to Communication.
Regarding interactive mode, it will prompt the login window to let you authentication when configure or run build agent if the cached account can’t access vsts or there isn’t cached account. You need to change the permission for this user.
You can try to set Read permission to deny for this user in Version Control admin page, the queue build that need to download that source and check the result, the build will not start anymore.
Summarize the issue and solution:
Per starain's comments, in old V1.x agent, regarding the access to VSTS work items from our testing code, it is nothing related to the PAT token we used to run the agent in interactive mode. Actually we run the agent using local admin account of the VM, which we ever used to connect to VSTS, and the credential was cached. The testing code just used that cached credential to access VSTS work items.
So the solution for V2.x is simple, just run the agent service using the local admin account. No need to run in interactive mode.
Thanks starain's great help!

tf.exe authenticate for vsts

I am trying to list all the workspaces and trying to authenticate tf.exe with vsts using the below commandline.
tf workspaces /Collection: https://[account].visualstudio.com/defaultcollection /login:USername,Password
The vsts account is backed by Azure Active Directory synced with an on-prem AD.
It works fine when I have connected to the vsts from visual studio and then running the above tf.exe command without the login switch.
But, when I use the login switch for tf.exe and use the same credentials that I use in visual studio it throws
TF30063: You are not authorized to access https://[account].visualstudio.com/defaultcollection
TF30063: You are not authorized to access https://[account].visualstudio.com/defaultcollection
What I am trying to achieve is that I am going to provision a server and then not going to login to visual studio and want my tf to work as it works when logged in to the visual studio online account in the team explorer of my visual studio.
I am an admin of the vsts account and have full right on everything. If there are other ways of doing this possibly authenticate TF.exe using PAT token that would work as well.
I would use tf.exe again for a checkin command from automated builds.
Any help in solving this would be appreciated.
There is the Check in changes task in TFVC Build Tasks extension that you can use it to check in changes. Also, you can call TF command to check in changes during the build process, it uses build service account.
On the other hand, you can create a console application to check in changes through TFS API (Workspace.CheckIn method), then call this app through command line.
I was having the same issue (TF30063) when running tf.exe. For me the solution was:
Exit all running instances of Visual Studio
Rename %LocalAppData%\Microsoft\Team Foundation\7.0\Cache to %LocalAppData%\Microsoft\Team Foundation\7.0\Cache_old (or you could delete it; but I wanted to preserve the original so I had the option restore it when going back into VS). NB: the 7.0 varies according to which version of TF you're using.
Navigate to my project's folder pushd c:\projects\vsts_tfvc_repos\Project123
Run tf /collection:myinstance.visualstudio.com /workspace:%computername%
/login:myMicrosoftAccount#example.com,myPassword to initialise the session under the correct account
Thereafter, everything worked as expected...