I receive a syntax error when trying to create a tag on my main branch in the example below:
gitGraph
commit
tag: "v1.0"
branch dev
branch update-MS1-reference
commit
checkout dev
merge update-MS1-reference
tag: "v1.1rc00"
checkout update-MS1-reference
commit
checkout dev
merge update-MS1-reference
tag: "v1.1rc01"
checkout main
merge dev
tag: "v1.1"
If i try it in mermaid.live, i get this error message:
Expecting 'GG', 'EOF', 'NL', 'acc_title', 'acc_descr', 'acc_descr_multiline_value', 'section', 'CHECKOUT', 'BRANCH', 'CHERRY_PICK', 'MERGE', 'COMMIT', 'open_directive', ';', got 'COMMIT_TAG'
Why can i not create tags on the main branch?
I see no errors if i remove the tags from main like this:
gitGraph
commit
branch dev
branch update-MS1-reference
commit
checkout dev
merge update-MS1-reference
tag: "v1.1rc00"
checkout update-MS1-reference
commit
checkout dev
merge update-MS1-reference
tag: "v1.1rc01"
checkout main
merge dev
It seems to not be related to main at all, i was doing line breaks without spaces, so it would see "committag: "1.0".
After adding a space after commit on the line above, it worked
Related
In Jenkins, I have a multibranch pipeline job using a Jenkinsfile. I have disabled the default SCM checkout via:
options {skipDefaultCheckout(true)}
so that I can control the checkout for each stage and use the SSH URL from GitHub. I have a working stage that checks out the "main" branch using:
checkout([
$class: 'GitSCM',
branches: [[name: '*/main']],
extensions: [[$class: 'LocalBranch', localBranch: 'main']],
userRemoteConfigs: [[credentialsId: 'XXX', url: 'git#github.com:XXX.git']]
])
For another stage, I would like to checkout and build/test the branch that is triggered (in this case a feature branch called "feature-0001"). I have tried this (note the change for the branches and extensions lines):
checkout([
$class: 'GitSCM',
branches: [[name: env.BRANCH_NAME]],
extensions: [[$class: 'LocalBranch']],
userRemoteConfigs: [[credentialsId: XXX, url: 'git#github.com:XXX.git']]
])
but I get the following error:
Error when executing failure post condition:
java.io.IOException: Cannot retrieve Git metadata for the build
In addition, the build log also has:
git rev-parse "origin/feature-0001^{commit}" # timeout=10
git rev-parse "feature-0001^{commit}" # timeout=10
I'm not sure where the "^{commit}" comes from or if it's causing any issues.
Any guidance would be appreciated, thank you!
P.S. I have also tried many variations of BRANCH_NAME including
$env.BRANCH_NAME, ${env.BRANCH_NAME}, $BRANCH_NAME, ${BRANCH_NAME}
branches: [[name: "refs/heads/${env.BRANCH_NAME}"]] worked.
I was also using the incorrect url/credentials causing further issues.
If you want an unambiguous way to reference your branch name in the SCM checkout step, try (as explained here):
branches: [[name: 'refs/heads/${env.BRANCH_NAME}']]
The ^{commit} revision specification would therefore apply to the ref refs/heads/${env.BRANCH_NAME}
<rev>^{<type>}, e.g. v0.99.8^{commit}
A suffix ^ followed by an object type name enclosed in brace pair means dereference the object at <rev> recursively until an object of type <type> is found or the object cannot be dereferenced anymore (in which case, barf).
For example, if <rev> is a commit-ish, <rev>^{commit} describes the corresponding commit object.
i need an explanation or example python code to check does an branch exist.
My repo is stored in an GitLab enviorement. I addded an GitLabVariable as an substitute
of the Branchname.
branches = git.Git().branch("--all").split()
if os.environ.get('GitLabVariable') in branches:
I am using following code to checkout or switch the branch within python code,
repo.git.checkout('branch_name')
But when the code later executes is still referring to 'master' branch code.
I am using GitPython version 2.1.11.
import git
repo = git.Repo("/home/user/.emacs.d")
To checkout a branch:
to see available branches
>>> repo.heads
[<git.Head "refs/heads/master">, <git.Head "refs/heads/straight">]
you can use the branch name like this:
>>> repo.heads.straight.checkout()
<git.Head "refs/heads/straight">
the branch changed to straight
If you want to use git directly
>>> repo.git.checkout("master")
"Your branch is up-to-date with 'origin/master'."
the branch changed to master
I've created the following rake task below to generate our release notes for each sprint.
I'm pulling in all commits to master older than 2 weeks.
The problem is when a branch has been developed on for more than 2-week sprints, the older commits won't be included.
Can anyone suggest a way I can get these commits in?
task :new_release_note do
puts "Creating new release note"
puts "..."
git_log = `git log --since="two weeks ago" --no-merges --format=%B`
git_log.gsub!(/^$\n/, '')
git_log.gsub!(/^/, "* ")
current_time = DateTime.now
current_date = current_time.strftime "%Y-%m-%d"
current_date_UK = current_time.strftime "%d-%m-%Y"
template = "__Release Notes__
=======================
#{current_date_UK}
__New Features__
----------------
* -
__Improvements__
----------------
* -
__Fixes__
---------
* -
__Change Log__
----------------
Detailed release notes below, listing all commit messages for this release.
#{git_log}
"
out_file = File.new("./doc/release_notes/release-notes-#{current_date}.md", "w")
out_file.puts(template)
if File.exist?(out_file)
puts "New release note generated successfully at /doc/release-notes/release-notes-#{current_date}.md"
else
puts "Error - file not generated."
end
end
Can anyone suggest a way I can get these commits in?
Few options:
git tag
git notes
git whatchanged
git tag
Read this answer on what is git tag and how to use it: What is git tag, How to create tags & How to checkout git remote tag(s)
In short: git tag allows you to mark commit which can be later on to perform your merge. As you know
git pull = git fetch + git merge
So once you have marked your last merge with the tag you can pull out all the changes form the last merge
# "Merge" the last X commits based upon your previous tag
git cherry-pick <tag_name>..master
git notes
git notes allow us to add content to commit without updating the SHA-1 of the commit, meaning we can attach content to the commit while leaving the SHA-1 unmodified.
Now once you have your notes you can find out the last commit which you "merged" previously and grab the changes from this point on using the above cherry-pick.
You can search and find your notes with git log --grep
git whatchanged
Once you what is your referenced commit you can see the list of files which were updated during this time period with the git whatchanged command
# Print out a list of files which was updated/added between the 2 commits
git whatchanged <TAG_NAME>...HEAD
Consider using git tag and tag your releases with version numbers. What my team does is to create a release branch with a version number for each release i.e. release-2.5.8 and when the release is ready, it gets merged into master. Then we tag that merge commit with a version number i.e. v2.5.8 If you do this, along with squash merges then to see all the related commits it's as easy as doing:
git log v2.5.8...v2.5.9
Which will show you all the commits within those 2 releases.
The reason I recommend squash merging your feature branch is for exactly your use case. You want to know what was done during the dev of that feature, but how can you just by date? You really can't. So when your feature is ready to be merged into your release, if you squash merge, you can keep all the notes in a single commit for the merge of that feature. The idea here is you keep what is relevant and discard what is no longer needed during development.
You might also want to check out Gitflow
I want to update my yml file to ignore commits from certain users. Is this possible? Is there a similar solution? Ideally I wouldn't even want to trigger the build in the first place.
Pseudo code example of yml file (ignore syntax, I'm just showcasing what I'm trying to do)
user: git show -s --format='%ae' $BITBUCKET_COMMIT
unwantedUser: "person#mail.com"
pipelines:
tags:
'**' && user != unwantedUser: # any tags by wanted users
- step:
script:
(...)
What would be the actual syntax to achieve that?
I ended up including the [skip ci] string in my commit messages to avoid triggering the pipeline.
From the documentation:
Can I commit without triggering the pipeline? Yes. If you don't want
to run a pipeline on a commit that would normally trigger one, you can
include [skip ci] or [ci skip] anywhere in your commit message of the
HEAD commit. Any commits that include [skip ci] or [ci skip] in the
message are ignored by Pipelines.
Alternatively, if you want to trigger pipeline manualy you can use 'custom' tag.
From the documentation
pipelines:
custom: # Pipelines that can only be triggered manually
sonar:
- step:
script:
- echo "Manual triggers for Sonar are awesome!"
Custom pipelines do not run automatically on a commit to a branch. You can run a pipeline with commits view page or branches view page.