I'm trying to understand how GitVersion works.
Here there is a snippet for 'gitversion /showconfig'
branches:
develop:
mode: ContinuousDeployment
main:
mode: ContinuousDelivery
hotfix:
mode: ContinuousDelivery
...
After shipping the release/1.1, my git is in this state:
Master branch has tags 1.0.0 and tag 1.1.0.
Develop branch is in 1.2.0-alpha.1.
Now I tried to to simulate an hotfix in production for the release 1.1.0
> git checkout master
> gitversion /showvariable FullSemVer
1.1.0
> git checkout -b fix/1.1
> gitversion /showvariable FullSemVer
1.1.0
> Add-Content -Name EmptyFile7.txt -Value 'Correction'
> git add --all; git commit -m "fix(gitversion): modified EmptyFile7.txt"
> gitversion /showvariable FullSemVer
1.2.0-fix-1-1.1+1
I expected 1.1.1-fix-.... and now I don't know how to tag this fix.
For example, is this right?
> git checkout master
> git merge hotfix/1.1
> git tag 1.1.1
Should I handle all this not as a bugfix but in develop/release way?
Riccardo
The right branch was hotfix and not fix
> git checkout master
> gitversion /showvariable FullSemVer
1.1.0
> git checkout -b hotfix/1.1.1
# Fix
> Add-Content -Path EmptyFile7.txt -Value 'Correction'
> git add --all; git commit -m "fix(gitversion): modified EmptyFile7.txt"
> gitversion /showvariable FullSemVer
1.1.1-beta.1+1
Now I can switch to master and approve the hotfix
> git checkout master
> git merge hotfix/1.1.1
> git tag 1.1.1
and finally merge back to develop
> git checkout develop
> git merge hotfix/1.1.1
Related
I'm trying to create a pipeline on Gitlab CI that increments the app version everytime we get a commit on master. But it is ignoring my ci.skip command and I don't know why.
The yaml file is this one:
.gitlab-ci.yml
workflow:
rules:
- if: $CI_COMMIT_BRANCH == 'master'
before_script:
- git config --global user.email "${GITLAB_USER_EMAIL}"
- git config --global user.name "${GITLAB_USER_NAME}"
- git remote set-url origin https://push:$PUSH_KEY#$CI_SERVER_HOST/$CI_PROJECT_PATH.git
auto_release:
image: node:10
script:
- yarn
- yarn release
- git push --follow-tags origin HEAD:master -o ci.skip
- echo "Done!"
So everytime I push a new commit it gets locked inside an eternal loop that commits a new version and commits a new version over and over again. The only way to stop is manually cancelling the jobs.
Pleas note: When we use the image node or node:latest it works, but our version requires node:10 otherwise it will break and won't build.
node:10 is a very old image. The git version it contains does not support push options (at least with the shorthand -o), so that's why the push triggers the next CI build.
Check the git version in the image - if it's 2.10 to 2.17 you can use --push-option=ci.skip. If it's still an older version, you need to create your own docker image that contains node version 10 and a modern git version.
I had made a commit in the GitLab branch, then merged it into the main branch, but the .gitlab-ci.yml pipeline is not updating the last committed code into the production server.
Note: Pipeline is working, but committed changes are not visible.
Depend on your version of GitLab, it could be an older bug.
For instance, gitlab-org/gitlab-runner issue 4587 "GitlabRunner does not check out the latest commit but the previous one"
In your gitlab-ci.yml, check what
Workaround:
have same problem, but if use checkout & pull - everything ok
git checkout -f $CI_COMMIT_REF_NAME && git pull
As in, for instance:
script:
- echo $CI_COMMIT_REF_NAME
- git checkout $CI_COMMIT_REF_NAME
- git pull
I had the same issue.
Try turning off the cache in your pipeline and see once
- cache:
I am trying to build a Jenkins pipeline (with a Windows agent, if this could be relevant) for a project in C/C++. My jenkinsfile contains the following lines:
stage('Clone') {
steps {
[...]
checkout changelog: false, poll: false,
scm: [$class: 'GitSCM', branches: [[name: "$gitlabBranch"]],
doGenerateSubmoduleConfigurations: false,
extensions: [],
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: 'gitlab-credentials', url: "$gitlabSourceRepoHttpUrl"]]]
[...]
And the logfile is:
[Pipeline] checkout (hide)
using credential gitlab-credentials
Fetching changes from the remote Git repository
skipping resolution of commit remotes/origin/master, since it originates from another repository
Checking out Revision ccc3e1e628ffa2a4e98d847ea952f048724ffaf5 (refs/remotes/origin/master)
> git rev-parse --is-inside-work-tree # timeout=10
> git config remote.origin.url [URL REDACTED] # timeout=10
Fetching upstream changes from [URL REDACTED]
> git --version # timeout=10
using GIT_ASKPASS to set credentials gitlab-credentials (https-pipeline)
Setting http proxy: [REDACTED]
> git fetch --tags --progress -- [URL REDACTED] +refs/heads/*:refs/remotes/origin/* # timeout=10
> git rev-parse "refs/remotes/origin/master^{commit}" # timeout=10
> git rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10
> git config core.sparsecheckout # timeout=10
> git checkout -f ccc3e1e628ffa2a4e98d847ea952f048724ffaf5 # timeout=10
Commit message: "Update Jenkinsfile"
> git rev-list --no-walk 628bc28a2c03a0f6f10ca1a75420c06efef16177 # timeout=10
The problem is, all data is fetched with timestamp set to the time of fetch, and therefore all files are compiled. What should I change?
I just checked, and I am sure that it is the checkout which retrieves everything: before that line, there are the old files, after that everything is updated.
I have this YAML snippet, to clone a second repo in my pipeline.
resources:
repositories:
- repository: clone-scripts
type: git
name: 'DevOpsProject/pipeline-scripts'
ref: 'refs/heads/main'
however, when executed, it shows this error
git remote add origin https://dev.visualstudio.com/DevOpsProject/_git/pipeline-scripts
git config gc.auto 0
git config --get-all http.https://dev.visualstudio.com/DevOpsProject/_git/pipeline-scripts.extraheader
git config --get-all http.proxy
git config http.version HTTP/1.1
git -c http.extraheader="AUTHORIZATION: bearer ***" fetch --force --tags --prune --progress --no-recurse-submodules origin
remote: TF401019: The Git repository with name or identifier pipeline-scripts does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'https://dev.visualstudio.com/DevOpsProject/_git/pipeline-scripts/' not found
what I have seen, is that it is not taking into account the 'DefaultCollection' when executing
git remote add origin https://dev.visualstudio.com/DefaultCollection/DevOpsProject/_git/pipeline-scripts (OK)
But how do you execute that, it's wrong
git remote add origin https://dev.visualstudio.com/DevOpsProject/_git/pipeline-scripts
Any ideas? in the Azure documentation, I have read but i can't find any information about that.
resources:
repositories:
- repository: clone-scripts
type: git
name: 'DefaultCollection/DevOpsProject/pipeline-scripts'
ref: 'refs/heads/main'
Its just to check those permisions in repo config
I committed a branch and it is merged with master. Later on production, it is found to be bug in the commit.
I need to raise a PR with previous commit of master against master.
I tried the following
git checkout <specific-commit-id>
git checkout -b <new-branch-name>
git push origin <new-branch-name>
When I try to raise PR against master, it says
The source branch is 2 commits behind the target branch
Expected it to allow me to merge it in master but it didn't allow
How can I do so?
Follow the steps below,
git checkout <branch-name>
git checkout -b <new-branch-name> <properly-working-commit-id-of-current-branch-which-we-want-to-deploy>
git add .
git commit --amend -m 'commit-name'
git push origin <branch-name>
By doing so it allows us to merge in GitLab