I am trying to write a script that will create a tag and then create a draft release based on that tag. Essentially replicating the flow of what happens when you create a release via the Github website release flow below.
I am currently doing the following to create the tag and then the release:
# get latest commit hash of master
hash=$(cat .git/refs/heads/master);
# create tag based on commit
git tag -a $version $hash -m $version;
# push tag to github
git push origin $version --no-verify;
# commit has of newly created tag
tagHash=$(git rev-list -1 $version);
# # create release
gh release create $version --draft --generate-notes --title $version --target master;
It appears to always create a release and compares changes to the last minor version as opposed to most recent release.
For example, running the script above creates a release with
Full Changelog: v1.14.1...v1.15.3
But if I create the release via the web UI, it generates the following instead:
Full Changelog: v1.15.2...v1.15.3
I think I need to update my script to create a tag based on the previously create tag's hash as opposed to creating it from master/main?
i.e.:
# how can I get $lastTagsHash?
# create tag based on commit
git tag -a $version $lastTagsHash -m $version;
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'm using ruby-git to operate my Git repo. I can get the local branch that checkout from remote branch, how can I get it upstream remote branch? This's the code:
require 'Git'
repo = Git.open("xxxpath.git")
localbranch = repo.branches["localbranchnamexxx"]
The same way you would do it in normal git
remote_branch = repo.branches["origin/localbranchnamexxx"]
Counter-intuitively (to me, at least), the branch tracking information is stored in the git config, not in any branch or ref structures.
require 'git'
repo = Git.open("xxxpath.git")
localbranch = repo.current_branch
upstream_remote = repo.config["branch.#{localbranch}.remote"]
upstream_ref = repo.config["branch.#{localbranch}.merge"]
upstream_branch = upstream_ref.split('/').last
upstream = "#{upstream_remote}/#{upstream_branch}"
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
Suppose you have a repository at github.com/someone/repo and you fork it to github.com/you/repo. You want to use your fork instead of the main repo, so you do a
go get github.com/you/repo
Now all the import paths in this repo will be "broken", meaning, if there are multiple packages in the repository that reference each other via absolute URLs, they will reference the source, not the fork.
Is there a better way as cloning it manually into the right path?
git clone git#github.com:you/repo.git $GOPATH/src/github.com/someone/repo
If you are using go modules. You could use replace directive
The replace directive allows you to supply another import path that might
be another module located in VCS (GitHub or elsewhere), or on your
local filesystem with a relative or absolute file path. The new import
path from the replace directive is used without needing to update the
import paths in the actual source code.
So you could do below in your go.mod file
module some-project
go 1.12
require (
github.com/someone/repo v1.20.0
)
replace github.com/someone/repo => github.com/you/repo v3.2.1
where v3.2.1 is tag on your repo. Also can be done through CLI
go mod edit -replace="github.com/someone/repo#v0.0.0=github.com/you/repo#v1.1.1"
To handle pull requests
fork a repository github.com/someone/repo to github.com/you/repo
download original code: go get github.com/someone/repo
be there: cd "$(go env GOPATH)/src"/github.com/someone/repo
enable uploading to your fork: git remote add myfork https://github.com/you/repo.git
upload your changes to your repo: git push myfork
http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html
To use a package in your project
https://github.com/golang/go/wiki/PackageManagementTools
One way to solve it is that suggested by Ivan Rave and http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html -- the way of forking.
Another one is to workaround the golang behavior. When you go get, golang lays out your directories under same name as in the repository URI, and this is where the trouble begins.
If, instead, you issue your own git clone, you can clone your repository onto your filesystem on a path named after the original repository.
Assuming original repository is in github.com/awsome-org/tool and you fork it onto github.com/awesome-you/tool, you can:
cd $GOPATH
mkdir -p {src,bin,pkg}
mkdir -p src/github.com/awesome-org/
cd src/github.com/awesome-org/
git clone git#github.com:awesome-you/tool.git # OR: git clone https://github.com/awesome-you/tool.git
cd tool/
go get ./...
golang is perfectly happy to continue with this repository and doesn't actually care some upper directory has the name awesome-org while the git remote is awesome-you. All import for awesome-org are resovled via the directory you have just created, which is your local working set.
In more length, please see my blog post: Forking Golang repositories on GitHub and managing the import path
edit: fixed directory path
If your fork is only temporary (ie you intend that it be merged) then just do your development in situ, eg in $GOPATH/src/launchpad.net/goamz.
You then use the features of the version control system (eg git remote) to make the upstream repository your repository rather than the original one.
It makes it harder for other people to use your repository with go get but much easier for it to be integrated upstream.
In fact I have a repository for goamz at lp:~nick-craig-wood/goamz/goamz which I develop for in exactly that way. Maybe the author will merge it one day!
Here's a way to that works for everyone:
Use github to fork to "my/repo" (just an example):
go get github.com/my/repo
cd ~/go/src/github.com/my/repo
git branch enhancement
rm -rf .
go get github.com/golang/tools/cmd/gomvpkg/…
gomvpkg <<oldrepo>> ~/go/src/github.com/my/repo
git commit
Repeat each time when you make the code better:
git commit
git checkout enhancement
git cherry-pick <<commit_id>>
git checkout master
Why? This lets you have your repo that any go get works with. It also lets you maintain & enhance a branch that's good for a pull request. It doesn't bloat git with "vendor", it preserves history, and build tools can make sense of it.
Instead of cloning to a specific location, you can clone wherever you want.
Then, you can run a command like this, to have Go refer to the local version:
go mod edit -replace github.com/owner/repo=../repo
https://golang.org/cmd/go#hdr-Module_maintenance
The answer to this is that if you fork a repo with multiple packages you will need to rename all the relevant import paths. This is largely a good thing since you've forked all of those packages and the import paths should reflect this.
Use vendoring and submodules together
Fork the lib on github (go-mssqldb in this case)
Add a submodule which clones your fork into your vendor folder but has the path of the upstream repo
Update your import statements in your source code to point to the vendor folder, (not including the vendor/ prefix). E.g. vendor/bob/lib => import "bob/lib"
E.g.
cd ~/go/src/github.com/myproj
mygithubuser=timabell
upstreamgithubuser=denisenkom
librepo=go-mssqldb
git submodule add "git#github.com:$mygithubuser/$librepo" "vendor/$upstreamgithubuser/$librepo"
Why
This solves all the problems I've heard about and come across while trying to figure this out myself.
Internal package refs in the lib now work because the path is unchanged from upstream
A fresh checkout of your project works because the submodule system gets it from your fork at the right commit but in the upstream folder path
You don't have to know to manually hack the paths or mess with the go tooling.
More info
https://git-scm.com/book/en/v2/Git-Tools-Submodules
How do I fix the error message "use of an internal package not allowed" when go getting a golang package?
https://github.com/denisenkom/go-mssqldb/issues/406
https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment
The modern answer (go 1.15 and higher, at least).
go mod init github.com/theirs/repo
Make an explicit init arg that is the ORIGINAL package names. If you don't include the repo name, it will assume the one in gopath. But when you use go modules, they no longer care where they are on disk, or where git actually pulls dependencies from.
To automate this process, I wrote a small script. You can find more details on my blog to add a command like "gofork" to your bash.
function gofork() {
if [ $# -ne 2 ] || [ -z "$1" ] || [ -z "$2" ]; then
echo 'Usage: gofork yourFork originalModule'
echo 'Example: gofork github.com/YourName/go-contrib github.com/heirko/go-contrib'
return
fi
echo "Go get fork $1 and replace $2 in GOPATH: $GOPATH"
go get $1
go get $2
currentDir=$PWD
cd $GOPATH/src/$1
remote1=$(git config --get remote.origin.url)
cd $GOPATH/src/$2
remote2=$(git config --get remote.origin.url)
cd $currentDir
rm -rf $GOPATH/src/$2
mv $GOPATH/src/$1 $GOPATH/src/$2
cd $GOPATH/src/$2
git remote add their $remote2
echo Now in $GOPATH/src/$2 origin remote is $remote1
echo And in $GOPATH/src/$2 their remote is $remote2
cd $currentDir
}
export -f gofork
You can use command go get -f to get you a forked repo
in your Gopkg.toml file add these block below
[[constraint]]
name = "github.com/globalsign/mgo"
branch = "master"
source = "github.com/myfork/project2"
So it will use the forked project2 in place of github.com/globalsign/mgo