My project "testheeroku7777" consist of two files.
main.go:
package main
import "fmt"
func main() {
fmt.Println("Hello world!")
}
Procfile:
web: testheeroku7777
When I push:
testheeroku7777> git push heroku master
It gives an error:
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 645.21 KiB | 5.92 MiB/s, done.
Total 8 (delta 1), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> App not compatible with buildpack: https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/go.tgz
remote: More info: https://devcenter.heroku.com/articles/buildpacks#detection-failure
remote:
remote: ! Push failed
remote: Verifying deploy...
remote:
remote: ! Push rejected to testheeroku7777.
remote: To https://git.heroku.com/testheeroku7777.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/testheeroku7777.git'
I've read provided links but I have no idea about this error.
This issue has to do with Go’s new dependency management system. Heroku is looking for a dependency management system in your project, and can’t find one. That’s why it’s throwing an error. Even though yours is a simple project, Heroku must have a dependency-management system that it can recognise.
Using Go modules is the officially-sanctioned method of dependency-management. But – and it’s a big but – a surprising quirk of Go modules is that Go modules don’t work for projects that are within the GOPATH.
When Go started, the developers made a big thing of having all projects in one place, the GOPATH. All the documentation was explicit on this – this is where your go code has to stored, it won’t run from anywhere else. But now, if you’re writing code that needs Go modules – and any code that’s going on heroku needs Go modules – the directories for that code must be outside GOPATH. I don’t know why they don’t make that more explicit, but that seems to be the way it is.
So, to get your code working, what you need to do is:
Move your project to somewhere outside GOPATH – the desktop, say,
in the name of originality.
Create a remote git repository with the same name as your current
project.
Then create a go module file by typing, at the terminal command
prompt in your local directory, go mod init
github.com/myGithubUserName/myProjectName
Next, create a local git repository by typing git init in the terminal.
Identify the remote repository you created earlier by typing git
remote add origin
http//www.github.com/myGithubUserName/myProjectName.git in the
terminal.
Write some excellent code.
Type git add . && git commit -m “first commit” at the prompt to
commit your code.
Type git push -u origin master to update the remote repository.
After all that, and only after all that, are you ready to type git push heroku master. The only consolation is that all should run smoothly now.
There are earlier dependency-management systems as mentioned by other posters, like govendor and dep, but Go modules are the officially-sanctioned method and I guess we’re all as well to adapt to it now as later. The most popular tutorial about Go modules seems to be this one: https://roberto.selbach.ca/intro-to-go-modules/. A search will find a few others too.
Heroku doesn't have the Go runtime installed in the base image, and therefore requires that you utilize the go buildpack to build your app. However, this also requires that you use a vendoring tool such as dep, or govendor, which means this very basic app, by itself, unfortunately won't work.
Related
I finished an Xcode project and pushed it to github from Xcode 'Source Control' Menu. Then I changed the project name CountryBook to Countries. I Built project and ran. Everything was okay. Then I coiped project folder to desktop as a backup. Then pushed project again. Everything has messed up. Some old named folders and files still exist in repo. Then I deleted every directory and file from github repository. Now, backup version of project is working. But when I try to push it to repo, old files are still exist. I deleted 'origin' from 'Remotes' and created a new repo named 'Countries'. I pushed project again but it was same. A mixed version of old files and new files. When I clone the github version of project, of course it is not runnable. What sould I do and how can I push clean version of my project? I don't want to lose project.
This is Countries repo now:
This is my working project folder with correct content:
I would fix it via command line, lets assume you start from scratch:
Step 1 - prepare the working branch:
Clone the project
Navigate to root folder of the project
Checkout the main branch ("main", "master", or whatever it is)
Create a new branch you will be working with
git clone https://github.com/yourorg/yourrepo
cd yourrepo
git checkout main # or master
git checkout -b fixprojectstructure # branch name can be anything
Step 2 - clean project locally
Delete old project, old workspace, ensure the names in Podfile and Podfile.lock are fine
Build the project and ensure it's working
Step 3 - commit your changes:
# assuming you are in the root of the project
git add .
git commit -m "Some explanation"
Step 4 - push your changes:
I usually do it the lazy way: just run git push, which will show you the proper syntax to push remotely, something like
> git push
fatal: The current branch fixprojectstructure has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin fixprojectstructure
> git push --set-upstream origin fixprojectstructure
Enumerating objects: ...
...
remote: Create a pull request for 'fixprojectstructure' on GitHub by visiting:
remote: https://github.com/.../pull/new/fixprojectstructure
remote:
...
Branch 'fixprojectstructure' set up to track remote branch 'fixprojectstructure' from 'origin'.
Step 5 - merge your changes:
Basically just do what the line above is saying:
Navigate to https://github.com/.../pull/new/fixprojectstructure
Create pull request
Merge pull request to main (or whatever the initial branch was)
Note on the side: configure the gitignore file properly for your repo as well. For starters, follow the gitignore template to create a proper gitignore file, and then change it the way you need to.
For instance:
Usually, if you use cocoapods, you do not store .workspace folder and its contents in the repo. Instead it's generated using pod install command on each machine that needs it.
It's also common to exclude Pods directory from storing in the repo, although there are pro / cons arguments both ways.
I always use composer packages in Laravel but I never changed one. This is my first time and I don't want to do it incorrect.
I need to use and change a packages foo/bar. Everything that follows now is just guessed:
I forked the repo
I created a develop branch
I added a vcs to my composer.json
"require": {
//...
"foo/bar": "dev-develop",
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/thisisme/bar"
}
],
composer update
Now I have the thisisme/bar fork in my vendor folder in foo.
So far so good. Now I can use my own fork.
But currently, as I don't know what is good practice to modify the repo, I cloned the repo to a completely different location. Then I push my changes there and run composer update in my project to get the changes. But this is a pain.
Do I need to have a sub git in my project in vendor/foo with
git remote add origin https://github.com/thisisme/bar.git. Because "git in git" feels wrong and finally is not really working as git commands seem to interact with the "parent git".
While VonCs answer is correct regarding git, I'm not certainly sure that git submodule support is well aligned with composer(1) vendor dir for packages from a VCS repository. At least I have not experimented much with it and when I use a composer configuration with a VCS git repository, I normally don't need that1.
While composer(1) has support for git for vendor packages, it is on repository level, that is, you can have your own repository for your package (as you have configured it shown in your question) and then composer takes care of updating (or giving a warnings about local changes).
composer(1) supports this with its own remote for the packages (non-bare) clone (in the source install, read on).
So yes, what you describe ("But this is a pain."), is as long as you don't use it to your benefit. While you develop your (cloned) package, you don't need to run composer update all the time.
.git
composer.json
vendor/foo/bar/.git
A Composer project with two Git repositories
This is why IMHO "git in git" must not feel wrong. Similar to git sub-modules, git supports this very well. By default it even keeps track in the parent project of the current revision (changes) of the sub-project but without having the information of the remote - as it is local (gitlink).
You won't see this thought as within the tree, the gitlink would be at vendor/foo/bar and commonly (& given that) vendor is git ignored, no version tracking in the main project for vendor/foo/bar/.git - but there in the sub-project.
This is not a problem as Composer manages that git sub-project for you (the initial clone and further checkouts) in terms of your main project.
And git realizes it is a different project.
You should be able to cd into the package directory within the vendor folder (vendor/foo/bar) and configure your remote(s) there. You can then work within that project and git(1) will work there and not within the parent repository.
To have this work with composer(1) it is important that you configure composer to prefer the source install variant for that repository. This is the preferred-install option and you can configure it for your repository specifically.
{
"config": {
"preferred-install": {
"foo/bar": "source"
}
}
}
From the wording in your question, I assume that you have not yet configured it.
And this is somewhat important as only with the source install, there will be a (non-bare) git clone in vendor/foo/bar and therefore the git checkout with the overall git configuration within the packages folder in the vendor directory (as you have Github configured as the repository source and composer optimizes to take the dist version by default IIRC).
After you changed your configuration to the source install and updated it, cd into vendor/foo/bar and then run git remote -v. It now should show you the "composer" remote(s) for that package.
As you use the develop branch, you can add changes locally but mind the gap that you would also need to push them to the remote repository (Github) before you use composer again to update (at least) that foo/bar package - as while you use git for the development of the foo/bar package now, in your main project you use composer to manage the dependency.
This is the price you have on the payroll using Github instead of a configuration that is more near to the place of work, but at least locally, you can handle the package with "git in git".
This is normally straight forward. One overall price remains thought, due to managing two instead of one repository but that you can't prevent with this kind of composer project [composer only versioned vendor folder]).
Note: If development takes longer than a few hours, it may also make sense to include the new Git sub-project in the backup routine of your parenting project, so that when you remove the folder vendor/foo/bar you have a backup of the (local) Git repository and working tree in it. However, this depends on the project configuration and is your own responsibility.
A bit of a workflow with some hints is also outlined in the composer documentation in Loading a package from a VCS repository.
1 There is a type of setup for a composer project where vendor itself is under git version control, with that git sub-modules can work (very well), but this is most likely not the kind of setup you have for your project, so I skip it for this answer.
If you're working with sail or docker-compose and linking the foo/bar project in the vendor dir is only a temporary until 'it works' solution you could just add it as a volume link. This is what I usually do.
Eg: I'm working on my-project in ~/projects/my-project, I clone the foo/bar repo to ~/projects/bar
Then in the docker-compose.yml I can add the volume:
volumes:
- .:/var/www/html
- ../bar:/var/www/html/vendor/foo/bar
Again, this has a huge assumption on docker being used, but I like to think that everybody is using it these days.
Do I need to have a sub git in my project in vendor/foo with git remote add origin https://github.com/thisisme/bar.git.
That could be achieved with a submodule which allows for your parent Git repository to only store a reference to another repository.
You would use git submodule add for that.
A git clone --recurse-submodule would therefore clone your project with the submodule Git repository in it cloned as well, and checked out to the exact reference you previously committed.
How can i successfully upload my Go project to existing github repository? Here is how my $GOPATH looks like: /home/user/go.
There I have created the following directories: src/github.com/StefanCepa/ . And inside that directory I have 2x directories which represent two different projects. I would like each of those projects to be posted on seperate github repository.
Any ideas how can I do that? Commiting stuff written in Go on github is kinda confusing to me.
This is done the same way that you would initialize and commit a new repository regardless of the language.
Go just makes it a little easier to find your other Go projects thanks to the $GOPATH and the standards of the language. Simple example below.
Within project 1:
$ cd ~/go/src/github.com/StefanCepa/projectOne/
$ git init
$ git add .
$ git commit -m 'init'
$ git remote add origin https://github.com/StefanCepa/projectOne.git
$ git push -u origin master
Within project 2:
*same process as above
My Gitlab CI Auto DevOps job failed with
Status: Downloaded newer image for gliderlabs/herokuish:latest
-----> Unable to select a buildpack
ERROR: Job failed: exit code 1
I've gone through
Auto DevOps and
Getting started with Auto DevOps
and am still not sure where I should put the buildpack.
Mine should be heroku-buildpack-go, which I've lost track where I get that from.
My repo consist only a single-character README.md, and the "Hello, playground" main.go.
Conclusion:
Thanks to David's comprehensive explanation, I was able to get DevOps started with correct buildpack:
From this I would conclude that your single .go file at the root of the directory tree does not meet the activation criteria for auto-building Go projects. I'd suggest picking one of the dependency managers in the requirements above and modifying your project to support it.
FTA, I just did touch go.mod then git add & git push and the AutoDevops started building my GO project indeed.
However it seems to me that Gitlab AutoDevops is not able to build any GO projects very easily, as I get the following error (with project variable TRACE=true):
...
!! The go.mod file for this project does not specify a Go version
!!
!! Defaulting to go1.11.1
!!
!! For more details see: https://devcenter.heroku.com/articles/go-apps-with-modules#build-configuration
!!
-----> Installing go1.11.1
-----> Fetching go1.11.1.linux-amd64.tar.gz... done
!! Installing package '.' (default)
!!
!! To install a different package spec add a comment in the following form to your `go.mod` file:
!! // +heroku install ./cmd/...
!!
!! For more details see: https://devcenter.heroku.com/articles/go-apps-with-modules#build-configuration
!!
-----> Running: go install -v -tags heroku .
go: cannot determine module path for source directory /tmp/build (outside GOPATH, no import comments)
ERROR: Job failed: exit code 1
The easier solution is to use .gitlab-ci.yml file instead, documented in
https://blog.boatswain.io/post/build-go-project-with-gitlab-ci/
(and followed up at Gitlab CI - Start Shared Runner for normal repos).
From the AutoDevops documentation:
Auto Build creates a build of the application in one of two ways:
If there is a Dockerfile, it will use docker build to create a Docker image.
Otherwise, it will use Herokuish and Heroku buildpacks to automatically detect and build the application into a Docker image.
Then looking at the build activation criteria, as per the Heroku Go buildpack documentation:
This buildpack will detect your repository as Go if you are using either:
go modules
dep
govendor
glide
GB
Godep
Or more specifically for godep, govendor or GB:
The Heroku Go buildpack is used when an application meets one of the following requirements:
has a Godeps/Godeps.json file, identifying the application as being managed by godep;
has a vendor/vendor.json file, identifying the application as being managed by govendor;
has a src directory, which has sub directories, contains one or more .go files, identifying the application as being managed by gb.
From this I would conclude that your single .go file at the root of the directory tree does not meet the activation criteria for auto-building Go projects. I'd suggest picking one of the dependency managers in the requirements above and modifying your project to support it. After that AutoDevops should start building your project.
If you are still having issues after that, this debugging note might help:
After making sure that the project meets the buildpack requirements;
if it still fails, setting a project variable TRACE=true will enable verbose logging which may help to continue troubleshooting.
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.