Increase version after commit to master in VSTS - continuous-integration

Our application uses VSTS for our CI flow and we have a requirement that the patch version should increase by one each time code is merged back into master.
We have created a shell script that will bump the version of the application and tag the repo, but now we are looking for the best place in the flow to inject it. We've thought of the following:
Master commit hook build - The problem with putting this here is that we have protected the master branch with certain policies (must resolve all comments, project must build, etc). Because of this, the build agent runs the script does not have access to push changes.
Pull Request build - This option would integrate the script into the build job that is used to verify the build. This actually works, but when the updates are pushed to the branch, this triggers an infinite build loop because the PR automatically rebuilds the branch. In general, this option seems more brittle.
I would love to have option 1 work out, but despite all attempts to grant the agent proper roles, it still does not have access to the repo. We're getting the following error:
TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.
Is there a standard way to do this that I'm missing?

To update the file version and add tag for the new commit through CI build, you can add a PowerShell task. detail steps as below:
Set permission and configure in build definition
First go to Version control Tab, allow below items for Build Service:
Branch creation: Allow
Contribute: Allow
Read: Inherited allow
Tag creation: Inherited allow
Then in your build definition, add the variable system.prefergit as true in Variable Tab, and enable Allow script to access OAuth token in Options Tab.
More details, you can refer Run Git commands in a script.
Add powershell script
git -c http.extraheader="AUTHORIZATION: bearer %SYSTEM_ACCESSTOKEN%" fetch
git checkout master
# Get the line of the file that contain the version
# split the line, and only get the version number major.minor.patch.
# check the version numbers (such as if patch less than 9) and increase the version
#replace the old version with new version in the file
git add .
git commit -m 'change the version as $newVersion'
git tag $newVersion
git push origin master --tags
Note: Even the new version and tag can push to remote repo successful, the PowerShell task may failed. So you should set the task after PowerShell task with custom option as Even if a previous task has failed.

You can try to update your branch policy per documentation on https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops and https://learn.microsoft.com/en-us/azure/devops/organizations/security/permissions?view=azure-devops#git-repository-object-level
Try updating your branch policy with to "Allow" "Bypass policies when pushing"

Related

Update Cloud Build ref to show correct branch it ran on

I'm using a webhook trigger and part of the configuration requires setting a default branch. This webhook invokes on pull requests so when the trigger runs it check-out that branch.
Everything works great except that in the Cloud Build history it obviously doesn't show the branch it ran on but the default branch set in the configuration, ie. 'master'
Is it possible to update the ref during build to be the actual branch it executed on so there is a bit more clarity when reviewing build history?
Referring to this documentation here, have I found the correct variable and would reassigning it work?
steps:
- id: 'Setup Credentials'
name: 'gcr.io/cloud-builders/git'
entrypoint: '/bin/bash'
args:
- '-c'
- |
# checkout 'feature/my-branch' branch
# do work on branch
$_REF_EVENT_NAME='feature/my-branch' # overwrite the configured default branch
If its possible then I'd want to update the commit reference as well as that's from the masters last commit not the branch.
Actually, you can't. This ref column is important when you use other type of trigger, but for webhook, the value is generic and not updatable.

fatal: remote <Repository> already exists

As part of the development of a CI & CD flow for the company I work at, I am building a command line program (Bash script on OSX) that
creates a new local Git repo
adds some default branches to this repo
Then adds a new repo to Bitbucket using the next code:
gitUserName = Joris <-- provided by the user, this is an example
projectName = TestProject <-- provided by the user, this is an example
git remote add $projectName "https://bitbucket.org/$gitUserName/$projectName.git"
After running this command, I don't see the repository on my Bitbucket account on the website. When I try to re-run this command, it says the repository already exists.
Also, when I run git push $projectName master it says fatal: repository 'https://bitbucket.org/Joris/TestProject.git/' not found
This behavior seems inconsistent, and I have followed the Atlassian guide to set this up so I don't really understand why it doesn't add the repository as expected. I do realize that I can also just go on the BitBucket website and add the repository manually, but the purpose of my program is that it generates a fully set-up repository for a user based on as little commands as possible.
The git remote add documentation says that the command adds a remote to the local repo. This terminology is, IMO, a bit off; it would better to say it adds a remote configuration to the local repository (i.e. configures the repo to access a remote). This does not actually create the remote repo; that must be done separately.
In the case of bitbucket, the "normal" thing to do is to go to the website and create the repo through their UI. Because you're trying to automate things, you don't want to do that; so in that case, you would need to use the BitBucket REST API, which is documented here: https://developer.atlassian.com/server/bitbucket/reference/rest-api/
The "Core API" section talks about repositories and permissions, so you should be able to script out requests to (if necessary) check if the repo exists and set it up if it doesn't. You'll just need a way for your script to send HTTP requests and receive the responses.
In your machine:
Create repo:
git init
Add branches:
git checkout -b branchX
git checkout -b branchY
git checkout -b branchZ
In Bitbucket website:
Create new repository named TestProject, allow write permissions to user Joris in settings and save. Finally copy the url of the repository, this must be something like bitbucket.mydomain:port/nameofproject/testproject.git (Notice this is all in lowcase)
In your machine:
git remote add origin theURL
git push origin *:*
git push origin --tags
The last is the command to push all your local repo, this will overwrite the history and tags in your remote repo, but since is a new repo it doesn't matter.

Can't fetch from same repository in Bitbucket Pipelines

I'm trying to do the following with Bitbucket Pipelines when i push to my test brand:
- git fetch
- git checkout master
- git pull origin test
- git push origin master
But i get the following message on git fetch: Permission denied (publickey). I was following this tutorial https://confluence.atlassian.com/bitbucket/use-ssh-keys-in-bitbucket-pipelines-847452940.html so i already added an ssh key, but cannot understand what are the next steps that i need for the execution to have permissions to connect to the repository.
If “from same repository” really means that you want to access the repository in which the pipeline runs, the answer is: you don’t need that. When the pipeline runs, it starts the Docker image you defined in your YAML configuration and automatically checks out the commit you pushed. This means that at the moment when when your command (git fetch) is executed, the sources are already waiting for you in path /project.
BitBucket Pipelines automatically checks out the repository upon running. However, if you want to make changes to the repository (e.g. git tag or git push) you will need to add the SSH keys according to the post you have already found (https://confluence.atlassian.com/bitbucket/use-ssh-keys-in-bitbucket-pipelines-847452940.html). That works for our environment.
Can you post the full bitbucket-pipelines.yml file?

StashIssueReportingPostJob not enabled - how to enable?

using the AmadeusIT sonar-stash plugin...
After branching from main for feature/sprint we updated code locally and added, committed and pushed to BitBucket, creating a pull request. We'd like to run a scan and see the issues presently only for the code we just issued a PR for... I run sonar-scanner with this invocation:
sonar-scanner -Dsonar.analysis.mode=preview -Dsonar.stash.pullrequest.id=8 -
Dsonar.stash.repository=StaticAnalysisPOC -Dsonar.stash.login=myLogin -
Dsonar.stash.password=myPassword -Dsonar.login=sonarLogin -
Dsonar.password=sonarPword -
Dsonar.projectKey=com.company.static:StaticAnalysisPOC -
Dsonar.projectName=stat -Dsonar.projectVersion=1.0.3
output was:
INFO: Executing post-job org.sonar.plugins.stash.StashIssueReportingPostJob
INFO: org.sonar.plugins.stash.StashIssueReportingPostJob#43294e9b
not enabled, skipping
Tech Stack/Versions;
SonarQube 6.x - latest
BitBucket (on prem) 4.x - latest
Thanks!
According to the code of the plugin, you have to add parameter -Dsonar.stash.notification=true
My resolution to success was as follows:
Create feature branch off master
Run a clean, vanilla scan with following invocation on master (for baseline scan) as such: "$ sonar-scanner" - this should be called when you are attached to the master on your local machine i.e. "$ git branch" returns "master"
Issue a pull request for master to update your local master in local repo i.e. "$ git pull origin master"
Switch to feature branch on your local machine as such: "$ git checkout "featureBranchName"
5.In Eclipse, if you have the project already open, you can verify you are now attached to feature branch referenced above.
6.Now you may perform your code changes, fixes, etc. as per your desired work on the feature branch.
When work is complete, add, commit and push your changes as such:
"$ git add ."
"$ git commit -m "my commit comment"
"$ git push origin myBranchName"
Go to Bitbucket and create a pull request from your newly pushed changes in your feature branch
Take feature branch "pull request id" and append it to this invocation of sonar scanner:
$ sonar-scanner -Dsonar.analysis.mode=preview -Dsonar.stash.pullrequest.id=
<yourPullRequestIDFromAbove> -Dsonar.stash.repository=<YourStashRepo> -
Dsonar.stash.login=<StashLoginUser> -Dsonar.stash.password=<stashPassword> -
Dsonar.login=<SonarLogin> - Dsonar.password=<sonarPassword> -Dsonar.stash.notification=true -
Dsonar.projectKey=<ProjectKey> -Dsonar.projectName=<projectNameInSonar> -
Dsonar.stash.project=<StashProjectName> -Dsonar.projectVersion=
<projectVersion>
10.Review the issues as found in Bitbucket for your pull request ID

Location of Git Executable for Jenkins on Windows

Which is the correct installation directory for Jenkins to use? Here are the options I have tried and the results I have seen.
C:\Git\bin\git.exe
C:\Git\cmd\git
same as above
C:\Git\cmd\gitk.cmd
If I continue and ask the job to build here is the console output.
Started by an SCM change
Building in workspace C:\Jenkins\workspace\git_test
Checkout:git_test / C:\Jenkins\workspace\git_test - hudson.remoting.LocalChannel#12f2468
Using strategy: Default
Cloning the remote Git repository
Cloning repository ssh:///jenkins#xxxx.yyyyyyyyy.com:test.git
git --version
Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information
Fetching upstream changes from origin
Seen 0 remote branches
No candidate revisions
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
Finished: FAILURE
Since they all result in one error or another its not clear which one is correct.
This is not a problem with git not being found but that putty has not yet been told that it can trust the ssh-key presented by the repository sshd server.
Run a manual git command first on the Jenkins server, so you can say yes to accept the host key, and then try again.

Resources