I am not able to delete publishers from the UI and there is no option for deleting via the tfx-cli either.
No options in the UI in marketplace and tried this answer but there is no such command in the cli.
See here.
For example, you need a user that have permission like 'Owner' in marketplace 'publisher' instance.
You need to generate a Personal Access Token on DevOps side that have these permission:
Or you can simply select the 'Full access' section of the 'Scopes'.
After that, install the tool 'vsce':
npm install --global vsce
After the tool installed successfully, run this command:
vsce delete-publisher <publisher ID>
After give the personal access token and confirmation, the publisher will delete successfully:
Notice:
The publisher ID is here:
Related
I have been installing ckan with docker from the page of datopian-tech. The problem I have is in the last part of section "getting started": When I use the credentials given ckan says that are bad credentials.
You can always create a new account and give it admin rights. After you create a new account use this command to promote it to admin. Note that paster command is removed in CKAN2.9 so you will need to check this guide.
I am trying to use tf.exe get to retrieve the latest for a workspace. I'd like to enter my login credentials on the command line.
If I enter this (at a powershell prompt):
TFS> . tf.exe get \WorkspaceName\ /login:me#home.local, pAsSwOrD
I am prompted for the password for me#home.local.
If I enter this:
TFS> . tf.exe get \WorkspaceName\ /login:me#home.local,pAsSwOrD
I get the message:
TF30063: You are not authorized to access tfsFileServerName\DefaultCollection.
What's going on? In the first instance it accepts my username, but not the password; in the second instance it seems to conflate the username and pwd, making it unrecognizable to the server.
Any insight would be appreciated....
If you use on-premise TFS, try to remove the existing credentials from credential manager(Control panel > Credential manager), and clear TFS related caches %LOCALAPPDATA%\Microsoft\Team Foundation\x.0\Cache. Also, try to test the command in Visual Studio command prompt directly to see how's the result.
If you try to work with Azure DevOps, you need to use OAuth token.
I have previously had Serverless installed on a server, and then when I tried to edit the function and package it back up to edit the zip file I broke it, so I have to start all over. So to begin this issue: I had Serverless running and was using it with this package - https://github.com/adieuadieu/serverless-chrome/tree/master/examples/serverless-framework/aws
When I sudo npm run deploy, I get the ServerlessError:
ServerlessError: User: arn:aws:sts::XXX:assumed-role/EC2CodeDeploy/i-268b1acf is not authorized to perform: cloudformation:DescribeStackResources on resource: arn:aws:cloudformation:us-east-1:YYY:stack/aws-dev/*
I'm not sure why it is trying to connect to a Role and not an IAM. So I check the Role, and it is in an entirely different AWS account than the account I've configured. Let's call this Account B.
When it comes to configuration, I've installed AWS CLI and entered in the key, id, and region in my Account A in AWS. Not touching Account B whatsoever. When I run aws s3 ls I see the correct s3 buckets of the account with the key/id/regioin, so I know CLI is working with the correct account. Sounds good. I check the ~/.aws/creditionals file and just has one profile [default] which seems normal. No other profiles are in here. I copied this over to the ~/.aws/config file so now both files are same. Works great.
I then go into my SSH where I've installed serverless, and run npm run deploy and it gives me the same message above. I think maybe somehow it is not using the correct account for whatever reason. So I manually set the access key and secret with the following commands:
serverless config credentials --provider aws --key XXX --secret YYY
It tells me there already is a profile in the aws creds file, so I then add --o to the end to overwrite. I run sudo npm run deploy and still same error.
I then run this command to manually set a profile in the creds for serverless, with the profile name matching the IAM user name:
serverless config credentials --provider aws --key XXX --secret YYY --profile serverless-agent
Where "serverless-agent" is the name of my IAM user I've been trying to use to deploy. I run this, it tells me there already is an existing profile in the aws creds file so I run it with --o and it tells me the aws file is now updated. In bash I go to Vim the file and I only see the single "[default]" settings, as if nothing has changed. I run sudo npm run deploy and it gives me the same Error.
I then go and manually set the access and secret:
export AWS_ACCESS_KEY_ID=XXX
export AWS_SECRET_ACCESS_KEY=YYY
I run sudo npm run deploy and it gives me the same Error.
I even removed AWS CLI, and the directory that holds the creditionals and config files - and when I manually set my account creds via serverless config it tells me there already is a profile set up in my aws file, prompting me to use the overwrite command - how is this possible when the file is literally not on my computer?
So I then think that serverless itself has a cache or something, calling the wrong file or whatever for creds, so I uninstall serverless via sudo npm uninstall -g serverless so that I can start from zero again. I then do all of the above steps and more all over again, and nothing has changed. Same error message.
I do have Apex.run set up, but that should be using my AWS CLI config file so I'm not sure if that is causing any problems. But then again I've no clue of anything deep on this subject, and I can't find any ability to remove Apex itself in their docs.
In the package I am trying to deploy, I do not have a profile:XXX set in the serverless.yml file, because I've read if you do not then it just defaults to the [default] profile you have set in the aws creds file on your computer. Just to check, I go into the serverless.yml file and set the profile: default, and the error I now get when I run npm run deploy is
Profile default does not exist
How is that possible when I have the "default" profile set in my creds file? So I remember that previously I ran the serverless config creditionals command and added the profile name of serverless-agent to it (yet didn't save in the aws creds file as I mentioned above), so I add that profile name to the serverless.yml file just to see if this works, and same error of "Profile default does not exist".
So back to the error message. The Role is an account not even related to the IAM user I'm using in my aws creds. Without knowing a lot about this, it's as if the config in serverless via ssh isn't correct or something. Is it using old creds I had set up in Apex.run? Why is the aws creds file not updated with the profile when I manually set it in serverless config command? I am using the same user account (but with new key and secret) that I used a few weeks ago when I correctly deployed and my Lambda and API was set up for me on AWS. Boy do I miss those time and wish I didn't mess up my existing Lambda functions, without setting version number prior, forcing me to start all over.
I am so confused. Any help would be greatly appreciated.
If you are using IAM role then you have to use that IAM role through assume role using powershell.
I was also facing same issue earlier, when we moved from from user to role.
I have a strange situation, if I run a Docker project in Visual Studio 2017 I get an error saying: Cannot start service webapplication1: error while creating mount source path '/host_mnt/c/Users/MyUser/vsdbg/vs2017u5': mkdir /host_mnt/c/Users/MyUser/vsdbg/vs2017u5: permission denied
But, if I run the same project with the command docker-compose up -d it works.
It cannot be a permission issue only for Visual Studio.
I just had the same problem - found the solution at https://github.com/docker/for-win/issues/897
Basically, the problem is access to C:\Users\user\vsdbg - not to think too much I gave R/W access for Everyone to this one and C:\Users\user\.nuget, just in case, and it worked like a charm :)
For me absolutely nothing worked, including giving full rights to only the vsdbg and .nuget folders.
My setup is as follows:
I have a primary account called "User" onto which I'm currently
logged in and do my development work
I have a user called "DockerDiskSharing" with full admin rights,
which I intend to use for Docker to run with
What did the trick for me was:
I opened a command prompt with admin rights and added the DockerDiskSharing user to the docker-users group by running
net localgroups docker-users DockerDiskSharing /add
I went to Docker -> Settings -> Shared Drives, I clicked "Reset credentials" and added the DockerDiskSharing user's credentials. I ticked C drive (my main partition) and the D drive (where my project is located)
I opened a command prompt with admin rights and gave full access permissions to the entire Users/User folder by running:
icacls "C:\Users\User" /q /c /t /grant docker-users:F
Still unsure which folders in particular it needs permissions to read/write to though from Users/User...
For other readers getting here which have a forced setup where their primary windows user can't be local admin:
That doesn't work!
After trying out different workarounds, I gave up. Note that I have a local service account which is local admin. If you don't have that, and are not a local admin, I guess you're screwed.
So:
I reset my Docker shared drive, mounted it again with my primary windows credentials
I added my primary user to the local administrators group
And now it works :)
We are using Jenkins as our CI server for our iOS team with the following setup:
Master server on OSX, not running any job
2 slaves on OSX running our integration jobs + UI Testing
Currently all signing identities and provisioning profiles for the apps are uploaded each slave which makes the administration a tad tedious and adding a new node to the cluster even more painful.
To work around this we've looked into using the credentials plugin with Developer profiles and import the profile as the first build step on all iOS jobs but are faced with to main issues:
The import developer profile seems to work the first time (at least for creating the keychain entries) but the job fails with a "no matching provisioning profile" error, even if the developer profile contains all the provisioning profiles required by the target.
Second run on the same job always fail with a "Keychain already exist" error
We've tried some work arounds for the second issue adding a shell build step removing the particular keychain but are still faced with the first error. If we manually install the profile on the slave the build passes but this defeat the purpose of using the credentials plugin.
What do you guys think?
I think the newest version of the credentials plugin now first removes any existing keychains with a matching name before importing, as seen in the log output below.
$ security delete-keychain jenkins-MyAppsBuildName-iOS
$ security create-keychain -p ******** jenkins-MyAppsBuildName-iOS
$ security unlock-keychain -p ******** jenkins-MyAppsBuildName-iOS
Because of this fact, I don't think you will have an issue anymore with duplicate keychain errors on the second run.
As far as the issue relating to the provisioning profile not being found, add the following line inside the execute shell command and run a build on jenkins.
security list-keychains
Take a look at the console for that specific build and you should see a list of all the keychains that are currently in the scope of the shell.
If you do not see "jenkins-MyAppsBuildName-iOS" as a listed keychain, this is why you are having the signing issue. Because the keychain is not listed, it is never even being searched through to find the proper signing identity/profile.
Solution: Warning: it's hacky
I'm not 100% sure why this is happening, but from other threads it appears to be a permissions issue.
Luckily there is an easy way around this.
In the execute shell command add the following:
security list-keychain -s jenkins-${JOB_NAME}
This will reset the keychain list to include the keychain needed to successfully build the project.
To verify that this now lists the proper keychain, you can add the following lines to the shell command:
security list-keychain
security list-keychain -s jenkins-${JOB_NAME}
security list-keychain
Now compare the output of the first list-keychain command with the second list-keychain command in the console. Make sure that the jenkin's build keychain is listed after the second security list-keychain output.
Warning: This will permanently change the keychain list on the system, so it is probably a good idea to reset the keychain after the build completes. You can accomplish this by settings the default desired keychain values in the xcode configuration inside of Jenkin's System Configuration section. After doing so, make sure to tick the check box "Restore OS X keychains after build process as defined in global configuration" under build environment inside of the Jenkins job's page.
Additional info: In my example I set the keychain-list to only include the keychain generated from Jenkins, but you may decide to also include the standard system and login keychain's by modifying the line as such:
security list-keychain -s jenkins-${JOB_NAME} login.keychain System.keychain
Keywords: Jenkins, iOS, slave, node, Xcode, plugin, credentials, .developerprofile