lock go module for specific branch while update - go

Dep has a very useful option - lock given a package for branch via constraints. You just specify a branch for a package and dep ensure -update update this package only within a selected branch.
In go modules I have to manually type go get -u package#branch and if I want to update all my modules by go get -u it will change branch in package to branch with most recent commit if any.
Is it possible to have dep-like behavior or automate this workflow?

A request for this feature is tracked at https://golang.org/issue/26964.

Related

Create conan package for specific commit ID and use it as dependencies on other packages

I am currently using Jenkins to build C/C++ projects. The projects uses conan packages as dependencies. I am trying to create a package with specific commit ID which can be later used by other packages.
For example:
RepoA is dependent on package created by RepoB. When RepoA build is trigged in jenkins RepoB build is triggered first in the pipeline and the packages are deployed in local cache which can be used by the RepoA later from the local cache.
RepoA has branch name called X and RepoB will also have same branch name called X. I need to use packages created from RepoB branch X for RepoA. Is there a way in conan to make RepoA use package created from RepoB branch X. I already can use the branch name as channel and use the right packages accordingly for RepoA as the branch name will be kept same. But apart from using the branch name is there any other way to create packages with commit ID as package ID and use it later for RepoA. If anyone knows the answer would be a great help.
The link below explains different package revision but I am cannot get a grasp of how to use it. It would be great if someone can give an example for the solution
Conan package revisions

Is it possible to not run Buildkite for readme updates?

I have the following action on buildkite that automatically packs and deploy a package to repo manager every time a PR gets merged into master.
But I would like that it was not run if my update is only a README.md update, is it possible to do so?

Go modules when running get vs build

I have a project where I use go modules. There I need to specify that I depend on a particular fork of a library (call it ), because it has an important patch. When I run go get -u <my_project>, I get a compilation error that clearly means that go took the main repo of , instead of the fork.
After that, I switch to the directory where go downloaded and run go build. Then, go takes the proper version of and compilation is successful.
Could you tell me what could be the reason for that and how to fix it?
Here is specific command to get :
go get -u github.com/planetA/konk
The dependency is "github.com/opencontainers/runc". For this dependency, go.mod contains following:
replace (
github.com/opencontainers/runc => github.com/planeta/runc v1.0.0-rc9.0.20191206160324-51eabe724369
)
require (
github.com/opencontainers/runc v1.0.0-rc9.0.20191206223258-201b06374548
)
Interestingly, in following sequence of commands, second go get does not produce error
go get -u github.com/planetA/konk
cd ~/go/src/github.com/planetA/konk
go build -tags seccomp
go get -u github.com/planetA/konk
I had a similar problem and I resolved this by detaching the fork itself and making a separate repo. Depends on your use case, this is also a much cleaner solution as you don't need to add too many edits to make it work. You can do so by:
Clone the fork repository on your local.
Delete the fork repository from github/gitlab etc. if you want the package name to be the same as the fork if not you can rename the new repo you create.
Create a new repo and push your content onto it
Now go get github.com/myusername/mynewrepo
But if you still want to make it work using the fork here is a great reference.

Vendoring Golang Shared Repository

Trying to move to the officially supported Golang vendoring solution from legacy Godeps workflow.
Scenario:
Repo A===
\
========> Repo C (shared library code)
/
Repo B===
What is the best workflow I can choose for a mid-size (roughly 5-10 member) team of engineers to vendor Repo C for both Repo A and Repo B? Engineers of varying abilities, most of which probably shouldn't need to know the details of this at all?
I'm currently using govendor for this. I'd prefer not to switch but would if there is a tool that provides a better workflow.
This needs to integrate with a CI server running the builds. I can think of 3 scenarios:
Vendor Repo C into A & B:
Pros:
Reproducible Builds
Easy integration with CI
Cons:
Manual and Error Prone - Can easily vendor incorrect code
Engineers need decent knowledge of vendor tool and methodology
Symlink Repo C trunk branch into vendor folders of A & B:
Pros:
Engineers need no knowledge of vendor tool
Low Developer Maintenance
Cons:
Builds not (easily) reproducible
Possibility of including code in build that shouldn't be released
Less Flexible (Repo A and Repo B can't have differing versions of C)
Include Repo C as a git submodule or subtree in Repo A and Repo B (either utilizing vendor or not):
Pros:
Engineers need no knowledge of vendor tool
Easy Setup
Less Maintenance
Reproducible Builds
Cons:
Having to use git submodule or subtree
Finding surprisingly little about this question on the internet. Is there some idiomatic way of doing this? I'm sure there are other ways of doing this; what am I missing?
i suggest to use a manifest based approach with version constraint.
Project A == Manifest
|- Repo A#~1.0.1
|- Repo B#~1.0.1
Repo A == Manifest
|- Repo C#~1.0.1
Repo B == Manifest
|- Repo C#~1.0.5
Repo C == Manifest empty
Which will resolve into
Project A == Resolved Manifest
|- Repo A#1.0.1
|- Repo B#1.0.1
|- Repo C#1.0.5
where ~1.0.1 means >=1.0.1 <1.1.0.
As you see B and A dependency to C are independent, yet within project they are resolved correctly.
In the event A and B would define incompatible dependency to C, an error should occur as the project should not be build-able.
You may prefer to use caret ^ rather than tilde ~, ^1.0.1 -> >=1.0.1 < 2.0.0.
Note that you are not forced to use those 'helpers' such tilde and caret, you may define explicit version range.
You shall decide which constraint to apply given the level of confidence you give to the remote author to correctly upgrade its version number.
Finally,you can use glide to solve that for you.
Starting with Repo C, assuming you already tagged the repos, run glide init, git commit -am 'glide init', git push
Repo A, glide init, glide get git#repo.com/repoc, git commit -am 'glide init', git push
Repo B, glide init, glide get git#repo.com/repoc, git commit -am 'glide init', git push
Finally, Project A, glide init, glide get git#repo.com/repoa, glide get git#repo.com/repob, git commit -am 'glide init', git push
To re install the project, glide install, go build.
Nothing prevent you to tarball ProjectA with its vendor folder, in order to skip the glide install command when you execute the remote installation.
But you normally don t want to commit the vendor folder for a development environment. You d usually add vendor/ to your .gitignore file and run glide install or glide update.
Expect some difficulties in the begin, passed that step, things will work.
Once you jumped to that workflow, note that you ll have to bump every changes on your repos.
That is bloatware when you work both project A and repo B to reach a viable change, so in that case, rather than vendoring repoB into project A (you can leave the manifest definition, but get ride of the repoB folder into vendor/), install repoB as a go module with the go get command.
Doing so the changes are taken in effect immediately on re-build. Once the change set is completed, browse into each repos and bump them appropriately.
Finally you may want to use a version bumper to help you to get it done quick and fast, it happens i did one for my personal usage.
hope this helps.

Integrating GitLab with TeamCity

Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:
The build configuration in Teamcity must use the build format number
%build.vcs.number% you will also want to configure monitoring of all
branches so merge requests build, that setting is in the vsc root
advanced settings.
I'm not sure how this works. Lets say I have a repository Foo.
I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge
I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.
But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).
I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.
So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.
I'm currently running GitLab 7.9 and TeamCity 8.1.4
Update:
Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240
I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.
I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.
I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)
Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.
Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.
Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:
IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git#your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git#your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>
As stated here [1], GitLab-CE can fire an event on creation of a merge-request,
so all you have to do is building some meta, that can evaluate the WebHooks.
[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events

Resources