I'm using YouTrack API to create new comment on an issue when a Git commit is made. But runAs parameter to execute request does not seems to work. I've tried Youtrack user ID of the target user but its still posting the comment as the user whose login is used to send the API request.
/youtrack/rest/issue/execute/SIN-35?command=comment&comment=Hello_World&runAs= Sruthi_KV&disableNotifications=true
For target user, please use login which is set in YouTrack user's Profile (Administration> Users> target user> Additional profile settings).
Check you're able to get valid data about the user in following way:
baseURL/rest/admin/user/login
Related
In my app the user accounts are created beforehand and are persisted on Keycloak. The problem is that I can not get the idp (google) to automatically link to existing accounts.
Everytime I try to login with one I get a token exchange error: federated_identity_account_exists. I checked the users in keycloak and they are not duplicated and idp is also not linked. I have been scratching my head for the past couple of hours on this one.
I tried using the first broker login flow on keycloak and also creating my own, but to no avail.
My own flow went something like this
Create user if unique (alternative)
Automatically set existing user (alternative)
but also tried just
Automatically set existing user (required)
I can ask this question in many ways, like
How to configure Jenkins credentials with Github Personal Access Token
How to clone Github repo in Jenkins using Github Personal Access Token
So this is the problem
The alternate solution that I am aware of
SSH connection
username password configuration in Jenkins. However,
use of a password with the GitHub API is now deprecated.
But My question is how to setup Github connection with Jenkins using Personal Access Token
[UPDATE]
The new solution proposed by git is
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
Which says:
Beginning August 13, 2021, we will no longer accept account passwords
when authenticating Git operations and will require the use of
token-based authentication, such as a personal access token (for
developers) or an OAuth or GitHub App installation token (for
integrators) for all authenticated Git operations on GitHub.com. You
may also continue using SSH keys where you prefer.
What you need to do:
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/#what-you-need-to-do-today
Basically, change the add URL as
https://<access token>#github.com/<userName>/<repository>.git
Something like this
https://<access token>#github.com/dupinder/NgnixDockerizedDevEnv.git
and set the credentials to none.
Thanks to #Gil Stal
[OLD Technique]
After many discussion on multiple threads from Stackoverflow
I found one thread that is useful.
Refer to this answer:
https://stackoverflow.com/a/61104603/5108695
Basically
Personal access token can be used as a password, as far as Jenkins is concerned at least. I added new credentials to the credential manager.
Go to Jenkins
Go to credentials > System > Global credentials > Add credentials a page will open.
In Kind drop-down select Username and password.
In User put a non-existing username like jenkins-user or user.
Add Personal Access Token in the password field
Now start configuring your project.
source code management tab, select new configured credentials from Drop-down near credential Under Repository URL
So this is how we can configure or setup Authentication between Jenkins and Github using Personal Access Token
References:
Git Clone in Jenkins with Personal Access Token idles forever
Change jenkins pipeline to use github instead of gitlab
The accepted answer wont work anymore because of this: https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations.
You will need to:
Change the URL of the repo to: https://<access token>#github.com/<user-name>/<repo-name>.git (Replace every <...> with the real parameters)
Set the credentials to none.
As of August 2021 the answer posted by Dupinder Singh is accurate. The only thing I would add is that if you are part of a team, the url format appears to be a bit different. This is what worked for me:
https://<access token>#github.com/<team>/<repo>.git
for example
https://ghp_6dh3jdk394jsmbh299jjdg20fh87hd83ksk39#github.com/MyKuleTeam/KuleGuyCode.git
Note that if you use a personal access token you don't need to have any github credentials stored in jenkins.
As for credentials for Jenkins Github Plugin, please be aware only Personal access tokens are now accepted by this plugin.
To generate such a token, follow the Github docs (e.g. here). Don't save it, it can be regenerated in Github and updated in Jenkins if lost or when migrating to a different server.
To add the token do Jenkins credentials store, go to <JENKINS_URL:PORT>/credentials/store/system/domain/_/newCredentials and select Kind "Secret text" (not the default "Username and password"), then paste the token as Secret and choose some ID.
Testing: the credential should appear on the list of Credentials at <JENKINS_URL:PORT>/credentials/ and be selectable from the drop-down list at <JENKINS_URL:PORT>/configure/, where pressing the "Test connection" button should display "Credentials verified for user <GITHUB_USER>".
More info: see the Github plugin docs.
Caveats: Git Plugin has its long-standing issues, so if the newly created "Secret text" does not appear in your pipelines, try if this solution helps (with "the user who triggered the build" considered safer than "SYSTEM"):
client-and-managed-masters/why-credentials-are-not-listed-in-the-git-scm-section
There is (yet another) way to do this as of 2020/04 which is supposed to be superior to personal access tokens. The best part is that you can continue using a username/password-style credential, and the plugin will handle authenticating with GitHub in the background.
Benefits include:
Larger rate limits - The rate limit for a GitHub app scales with your organization size, whereas a user based token has a limit of 5000 regardless of how many repositories you have.
User-independent authentication - Each GitHub app has its own user-independent authentication. No more need for 'bot' users or figuring out who should be the owner of 2FA or OAuth tokens.
Improved security and tighter permissions - GitHub Apps offer much finer-grained permissions compared to a service user and its personal access tokens. This lets the Jenkins GitHub app require a much smaller set of privileges to run properly.
Access to GitHub Checks API - GitHub Apps can access the the GitHub Checks API to create check runs and check suites from Jenkins jobs and provide detailed feedback on commits as well as code annotation
Links:
https://www.jenkins.io/blog/2020/04/16/github-app-authentication/
https://github.com/jenkinsci/github-branch-source-plugin/blob/master/docs/github-app.adoc
I have set the proper LDAP configuration in Sonar 5.6.6 LTS (ldap plugin v2.2.0.608) and I see in logs that the connection is established.
When I first try to login with my LDAP-login, I am able to do so, but my user has of course no permissions - that is okay.
The problem occurs, when I want to first add my user and give him i.e. sonar-administrators group. When it is set and I try to login, Sonar authenticates me not against the external system (LDAP) but uses his own data base.
I am sure it worked with Sonar 4.5 but now I cannot configure it properly.
The problem was that creation of new users adds them by default to the local database of SonarQube. To change this default behavior I found out that the REST API endpoint to create users contains the flag 'local' which defines whether the user should be considered as a local user added to the local database or he should be added as an external user authenticated again an external system like LDAP.
So final answer is to use the following REST API endpoint:
private final String CREATE_USER_API = "/api/users/create?login={login}&name={name}&local=false"
Please note the following property: local=false at the end of the string.
I am trying to follow the tutorial here: http://wiki.cloudbees.com/bin/view/Documentation/CloudBeesEclipseToolkit that describes how to configure your eclipse to use the CloudBees subversion respository. When I get to step 2, and try to validate my account username and password, I get:
Failed to validate your account.
Reason:
Failed to get account services info.
Authentication of user: xxxx failed.;
Details -
Unexpected response code:400. Message: Bad Request
I did use my google account (and oauth?) to create my cloudbees account. I am using my google username and password to try to validate.
The account name is what you see when you enter in cloudbees on the top right.
Regarding your missing password this is due to the fact that google and github sign in don't ask user to define a password - that's why you get an authentication failure.
Users can use https://grandcentral.cloudbees.com/account/forgot_password to request password reset and define the password.
I was able to fix this by clicking on the builds sectio of my account. This led me to some pages that told me I didn't have a password with cloudbees, and prompted me to create one.
When I used this password, instead of my gmail one, validation worked.
Also, I had to use my account name minus #gmaail.com to perform svn checkins, which wasn't the most intuative - it's not clear what un/ow and where
I use Salesforce IDE (standalone).
I had to change my SF password, and from that moment, when I start the IDE, I get a login error, and telling me I need to call from the API: reset password.
I don't understand what needs to be done, as there is no setting in the IDE for password.
Do I need to call reset API in my apexclass? this seems weird.
Thansk
Your Force.com project has your outdated password associated to it. You can either delete the project and create a new one (which would require you to specify the new password), or change your password on the current project by right-clicking on the project in the Package Explorer and going to Properties. You should see something similar to the screenshot below, where you can enter your new password and security token, if necessary.