I have Gitlab CE version 8.3 which is integrated with Jira. I am an admin user for Gitlab & have admin rights to the project in Jira. While pushing any commit to Gitlab with reference to issue id of jira creates successful link for it but no comments get posted from gitlab to jira. What could be the issue here?
My configurations also seem to be correct since the link between jira & gitlab is fine.
There's usually one more step you need to deal with in GitLab config, and that's setting appropriate "JIRA issue transition" value (which will trigger these comments).
In case you use custom workflows (but even if you don't) you need to double check whether value for "JIRA issue transition" specified under Gitlab's Services (Settings > Services > JIRA) matches transition ID in your JIRA workflow (take a look at this).
More info is available here.
"It is the ID of a transition that moves issues to a closed state. You can find this number under the JIRA workflow administration (Administration > Issues > Workflows) by selecting View under Operations of the desired workflow of your project. The ID of each state can be found inside the parenthesis of each transition name under the Transitions (id) column (see screenshot). By default, this ID is set to 2."
Related
How to integrate Veracode scanner as a pre-commit hook for git working repository? How can we check weather the scanner is actually running?
You can create a GitHub Action about Veracode static scan analysis. To do this you can follow the steps below:
In the Security tab of your GitHub project (you need to have admin rights for the GitHub project), click on "Enable settings" for "Code
scanning alerts".
This takes you to the Settings of the project, where you need to “Enable” “GitHub Advanced Security” for “Code scanning”,
and then click the “Go to code scanning” button that will be enabled.
Scrolling down on the list appearing with multiple code scanning tools, you pick “Veracode Static Analysis” (usually appearing on the bottom of the page).
Clicking to “Set up this workflow”, automatically creates a subdirectory in master branch in .github/workflows path. The workflow is configured in a .yml file, that contains the steps of the pipeline.
Prerequisite: you need to set up Veracode API Keys as Project Secrets (have a look here Create Veracode API keys and here
setup GitHub Action Secrets for Repository. Name your API Keys as VERACODE_API_ID and VERACODE_API_KEY (as these are the names that are set in .yml file or change them accordingly in both locations)
In the .yml file that got created automatically there is a pipeline that runs according to the rules set on the line where it says
you can have a look at this link for more information on push/pull request branches/tags
branch names can be altered, following regular expressions as well, see here for more info.
You can configure the Action to run on schedule as well.
Hover over “cron” to see the man-read format that appears. With this, the Action will run according to cron. Scheduled workflows run on the latest commit on the default or base branch.
Find more information on how to configure scheduled events on GitHub Actions here
In the Actions tab of your Project you can now see the logs of the run of the pipeline and each run's status.
After you have set up the GitHub Action as described above (steps 1-8), and the Action has run well (check its status as described in step 9) in the Security tab of your GitHub project, you should be able to see that "Code scanning alerts" are "Active", click on "View alerts", that takes you to the list of the Veracode flaws if any.
I've set up an automatic "pull request check" via jenkins/github/sonarqube integration.
The workflow is as follows:
Github pull request created by user → Github Webhook triggers, and calls Jenkins API to execute sonarqube scanner → reports to sonarqube server → sonarqube server calls github API(create commit statuses : ref https://developer.github.com/v3/repos/statuses/) and posts a comment about the PR.
The issue is that it marks the PR as check failed just because it didn't pass its code health checks. The build passed, but the code is "dirty" - and that causes the PR to be marked as unacceptable. I'd like to find a way to prevent code quality checks from appearing as an actual status of the commit, and only allow commenting.
Additional images to provide some context:
SonarQube uses a techuser account token to post its analysis summary as a comment on the PR thread. (Sorry for the black boxes, corporate stuff..)
This functionality is everything we need, nothing more.
However... the plugin does one more thing, which is marking the commit as a failure. Note that we're already using something else to check for actual build failures. Although it didn't fail, sonarqube marking the commit as failure because of code quality makes the whole commit display as a failure. I'd like to prevent sonarqube from setting branch check statuses, while letting it comment on the issue. I couldn't find an option for anything like that neither in jenkins plugin configuration nor sonarqube admin page nor sonarqube scanner script documentation.
Thanks in advance.
What you want to achieve is currently not possible when using the SonarQube GitHub plugin, since this behaviour is hardcoded in the plugin and there is no configuration option to customize this.
In upcoming versions of SonarQube and SonarCloud, pull request will have a built-in support and the behaviour will be the following:
The status will be red if there is at least an open issue on the PR analyzed by SonarQube/SonarCloud
Teams will have the ability to mark those issues as "Confirmed" in SonarQube/SonarCloud (to acknowledge that they accept this technical debt), in which case the status will be automatically turned to green in GitHub
I was trying to get an SVN, Jenkins and Jira integration going. The aim being to change the status of a ticket/issue to 'Fixed' when it is referred to in an SCM comment. The process being orchestrated by Jenkins. The flow details are
developer puts in the Jira ticket number (MDP-1) on an SVN commit
message.
The build is kicked off in JenkinsJenkins (using the Jira
plugin) can figure out the Jira ticket referred to it in the SVN
commit message. It updates the Jira ticket by putting in a Jira
comment.
So far, this is working great!
Now, I also want to change
the status of the ticket to 'fixed'. I am trying to use the Jenkins
step (Progress jenkins issues by workflow action). I am unable to
access the Jira issue ID/ticket number.
I know, under the hood, the Jira plugin has access to this. Thats why it is able to put in a comment to the Jira ticket in the first case. Question is how/what variable do I use to get access to this Jira ticket# in Jenkins
I actually got this working with another Jenkins plugin (https://wiki.jenkins-ci.org/display/JENKINS/Jira-Ext+Plugin).
This captures the Jira issue_id(s) captured in the SCM commit message and exposes them in an environment variable.
Just what I was looking for!
I'm trying to link Gitlab commit messages to JIRA, that is, if a user commits such as:
PROJECT-ID: Some commit message
Then through the Gitlab UI, it links these commit messages to JIRA.
The only way I can seem to do this at the moment takes control of issue tracking itself from Gitlab and links the "Issue" user interface button in Gitlab back to JIRA.
I'd like to still manage and raise issues in Gitlab, but just have Gitlab link any formatted commit messages to JIRA.
I'm using the community addtion
Unless you set GitLab to use JIRA as your issue tracker, you can't make it link formatted commit messages to JIRA automatically.
You can do this only if you set JIRA to be your issue tracker in GitLab. You can find information about doing that here: http://doc.gitlab.com/ee/integration/jira.html
UPDATE: As Peter said, this functionality is only available using GitLab's Enterprise Edition.
UPDATE: As jalanb stated in the comment below, this functionality is now available in the community edition as well.
There is also the lesstif/gitlab-jira-integration open source solution, that I haven't tried yet myself. It is only a few commits, but I myself considered this approach so it must be sound ;-)
I'm a little confused though. You write you want to use Jira and "I'd like to still manage and raise issues in Gitlab, but just have Gitlab link any formatted commit messages to JIRA." I'm not sure you can get the supertight integration you're looking for. Or maybe I misunderstand.
I followed Empower Jenkins with Artifactory video on YouTube. Basically, I added a new user to artifactory and granted it deploy permissions. Then I configured system configuration on Jenkins and tested that the configurations were right.
I created a new job and tried to set the deployment task to deploy it to artifactory. The problem is there is no repository on the dropdown.
I want to know how to fix this.
Try saving the job and reloading it.
The logic behind this behavior is to avoid a long list of repositories. Some users have hundreds of local repositories which takes a long time to display. By entering credentials, you can display a filtered list containing only relevant repositories.
There is an open issue to add a refresh button so there will be no need to save the job prior to displaying the list.
Update
This issue was resolved with the release of version 2.2.3 of the plugin. For more info see HAP-483