I have several private repo,such as A,B,C,D and the remote git url is https://127.0.0.1/repo/repo.git . How can i push A,B,C,D to the same remote git url(https://127.0.0.1/repo/repo.git) ? then local git just like .cocoapods/repos/master/Specs content, such as
├── Specs
└── A
└── B
└── C
└── D
if it done , how can i make the profile for installing.
Just add the pod-spec file of your cocoa-pod to the main repo folder and update the pod-spec source files path.
More details:
to create a cocoa-pod you need two steps
pod lib create POD_NAME
///this command runs in terminal to create for you a library with example option and many other things
pod lib lint POD_NAME.podspec
/// validate your spec file, check syntax and your files.
You could skip the first command and create your pod-spec file manually || copy it from any repo
then update it, add your code to your cocoa-pod folder, set the git repo in your pod-spec
make sure the git-repo have the pod-spec file in the main directory
You will find a complete example with Demo application in this project
https://github.com/abuzeid-ibrahim/DevPods
Related
Question
Can go mod tidy generate meaningful commit versions for local git repositories?
Background
I recently noticed that go mod tidy, when run from a local directory, generates a version using the "zero time" value from Golang, like so:
require example.com/db_api v0.0.0-00010101000000-000000000000
This seems reasonable for a local repository with no commits and no version tags... however, when I tried to add commits and tags to a local directory, I noticed that go mod tidy still relied on the zero timestamp as the identifier for the require statement.
Example
Let's start with a dependency:
➜ db_api git:(heads/v1.0.0) tree
.
├── go.mod
└── vars
└── constants.go
And a main repo:
➜ webapp git:(master) ✗ tree
.
├── go.mod
└── main.go
Now, if I add a create replace directive like so (such that the webapp/main.go depends on the constants.go file in the db_api directory...
replace example.com/db_api => ../db_api
Then the result of go mod tidy will always be the above "zero timestamp", as opposed to v1.0.0.
In contrast, running go mod tidy against a generic "GitHub" repo (i.e. cobra), results in a "tag" based version pin:
require (
example.com/db_api v0.0.0-00010101000000-000000000000
github.com/spf13/cobra v1.2.1
)
It seems to me like, the logic associated with remote git repositories (to get the latest semver tag), should be identical even for remote repositories. However, based on my experiments in here, it appears like local repositories aren't inspected for tags.
Hence, the original question... Can go mod tidy guess versioned data from a local repo in the same manner as it would for a remote repository, or is a local git repo fundamentally different in the way it is pinned in a go module?
Can go mod tidy generate meaningful commit versions for local git repositories?
No
Hence, the original question... Can go mod tidy guess versioned data from a local repo in the same manner as it would for a remote repository,
No
or is a local git repo fundamentally different in the way it is pinned in a go module?
Yes.
replace in go.mod means "use those files I dumped there as the module". The fact that you might manage these files with git or rsync or whatnot doesn't matter the slightest.
I have a small module that contains some shared code. The module looks like the following :
Shared
├── go.mod
├── go.sum
├── logging
│ └── logger.go
└── db-utils
├── db.go
If I'll try to build the Shared module from inside the directory I'm getting an error that no go file available under this module.
bash-3.2$ go build .
no Go files in /Users/xxxx/go/src/Shared
Is there a way to build a Go module that only has packages inside and doesn't have a main.go file? The motivation here is to use those packages in other go modules that can't access the internet or private repo in order to retrieve the packages.
The go command stores downloaded modules in the module cache as source code, not compiled object files. go build rebuilds the object files on demand and stores them in a separate build cache.
If you want to distribute a non-public module for use with other modules, you have a few options:
You can publish the module to a private repository — typically accessed with credentials stored in a .netrc file — and use the GOPRIVATE environment variable to tell the go command not to try to fetch it from the public proxy and checksum servers.
You can provide a private GOPROXY server or directory containing the source code, and use the GOPROXY environment variable to instruct the go command to use that proxy.
You can publish the source code as a directory tree and use a replace directive in the consumer's go.mod file to slot it into the module graph.
If you only needed to build files in either the logging or db-utils directory, then you could executing the following from the root directory Shared:
go build <INSERT_MODULE_NAME_FROM_GO_MOD>/logging
go build <INSERT_MODULE_NAME_FROM_GO_MOD>/db-utils
I'm not certain if those commands will work if one of the files has a dependency on a file from the other directory.
Another command that will probably build the entire project is this:
go build ./...
Is there a way to build a go module that only has packages inside and doesn't have a main.go file?
No. The input for the build process is a package, not a module. Note how it says [packages] in the CLI documentation of go build.
When building a package leads to multiple packages being compiled, that is merely a consequence of direct and indirect import statements coming from .go-files located in the package you are building.
Note that Go does not support compiling packages to binaries to distribute closed-source libraries or such. This was not always the case, though. See #28152 and Binary-Only packages. The closest which exists to supporting that are plugins, but they are a work in progress and require resolution of symbols at runtime.
Like this github repository, I forked the repository and made some changes to the code. When I run it, my changes are not in effect because the original code imports itself. I could simply just change the import library to mine like "import github.com/brucewangno1/ytdl". But is there any other clean way to avoid this?
Another easy way is to use go get instead:
$ go get github.com/original/a_library
$ cd $GOPATH/src/github.com/original/a_library
$ git remote add my_origin https://github.com/myaccount/a_library
In your case it will be
$ go get github.com/rylio/ytdl
$ cd $GOPATH/src/github.com/rylio/ytdl
$ git remote add my_origin https://github.com/brucewangno1/ytdl
Once you are done with changes, commit them and push using below:
$ git push my_origin my_branch
When working with golang forks of a repo, try and work in the import path of the original repo, and update the tooling to use your forked repo.
What I mean is, if you have forked the project github.com/rylio/ytdl/ to your own github account github.com/brucewangno1/ytdl
Then you might have a gopath such as:
$GOPATH/src/github.com
├── rylio
│ └── ytdl
└── brucewangno1
└── ytdl
You should make changes in the directory $GOPATH/src/github.com/rylio/ytdl.
To add the changes to your forked repo, you can set another origin in git, inside your local clone of rylio/ytdl
git remote add fork git#github.brucewangno1/tydl.git
If you do not plan on merging changes back into the upstream repo, you can use tools such as dep to ensure that you pull your own fork of that project instead of the upstream one. Something like:
[[constraint]]
name = "github.com/c/d
source = "https://github.com/myusername/d.git"
This answer assumes that you forked repository
https://github.com/rylio/ytdl/ to https://github.com/brucewangno1/ytdl
You need to create directory named rylio in your $GOPATH and clone your fork into that directory.
mkdir $GOPATH/src/github.com/rylio
cd $GOPATH/src/github.com/rylio
git clone https://github.com/brucewangno1/ytdl
Now, you will not face any issues related to the imports.
I have a project with two folders, that are independent, and needs separate builds in Jenkins (running v2.74)
My structure is
folder
├── project1
│ └── Jenkinsfile
└── project2
└── Jenkinsfile
When I click "scan organization" in Jenkins, it doesnt discover the Jenkinsfiles in subdirectories.
Here is a sample from the "Scan organization log":
Proposing kg-pipeline
Examining my-test-project
Checking branches...
Getting remote branches...
Checking branch jenkins
‘Jenkinsfile’ not found
Does not meet criteria
Checking branch master
‘Jenkinsfile’ not found
Does not meet criteria
2 branches were processed
Finished examining my-test-project
I didnt touch the configuration of the job that scans the organization and finds branches with Jenkinsfiles. Here is the current setting for the project
My question is: How do I configure Jenkins to see each folder individually? I am also interested in links to example projects set up this way.
There is a simple solution.
go to JENKINS_URL/job/JOB_NAME/configure
under Build Configuration, select by Jenkinsfile for Mode
under Script Path, set it to DIR_NAME/Jenkinsfile
For instance, if you had your Jenkinsfile inside a src directory, then you would set it to src/Jenkinsfile and Jenkins will be able to find the Jenkinsfile now
Currently trying to set up the same thing - this might help, even though it's not a complete answer:
According to this you should be able to setup two Multibranch Pipeline Projects, each with the configuration Mode "by Jenkinsfile".
Support for using custom paths for the Jeninsfile was added in JENKINS-34561
You can add more than one "Pipeline Jenkinsfile" under Project Recognizers with your paths to Jenkins files.
As a complete beginner to Go I'm not sure where to init Git.
The docs here https://golang.org/doc/code.html appear to suggest outside the hello directory early on and then later tell me to run git init inside the hello directory.
Any advice on this would be useful.
The example is clear:
$ cd $GOPATH/src/github.com/user/hello
$ git init
You do initialize the repo within your project 'hello'.
That way:
you can push it to your GitHub repo (that you need to create first on GitHub, empty):
git remote add origin https://<user>#github.com/<user>/hello
git push -u origin master
your go project is "go gettable"
go get github.com/<user>/hello
# that would clone and compile the project in `$GOPATH/src/github.com/<user>/hello`.
The .git you see outside hello (on the same page) is for another project:
src/
github.com/golang/example/
.git/ # Git repository metadata
hello/
hello.go # command source
Here, the project is 'example' and include several packages, including the hello one.
You'd want to initialize it at the same level as it would have been if you'd run go get github.com/user/hello - i.e. in the hello directory.
Basically, if you initialize git, push your repo up an go get again, nothing should change.