How can I build project a with dependency b when both are not found in stack indices?
I used stack install on b, added extra-deps but still failed to build a.
Didn't see b in your package indices. Updating and trying again.
Why b is not in my "package indices"? How should I build project a?
Related
I am trying to build a GitHub Actions workflow as a Continuous Deployment procedure on this forked repository of a Clojure project.
The process goes well until it reaches this point:
Error: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project flow: Compilation failure: Compilation failure:
Error: Source option 5 is no longer supported. Use 6 or later.
Error: Target option 1.5 is no longer supported. Use 1.6 or later.
Error: -> [Help 1]
Usually, other problems in Stack Overflow related to this error message involve tweaking the pom.xml (see examples: 1, 2, 3, 4, 5, 6).
However, since this is a Clojure project managed by Leiningen, there is not such a file initially. The pom.xml is generated after lein install (and other command) is executed. Clojure is a hosted language on the JVM, after all.
As a side note, I am not sure why this project has :java-source-paths (link) instead of :source-paths. Not sure if this aspect is related to the problem discussed here.
How to fix it?
Does anyone know how I could resolve this cycle in dependencies? I've been stuck on this problem for 3 days. I tried build cleans, clearing derived data, rebuilding pods, even doing git reverts are not helping.
error: Cycle in dependencies between targets 'Pods-Trust' and 'PromiseKit';
building could produce unreliable results.
Cycle path: Pods-Trust → PromiseKit → Pods-Trust
Cycle details:
→ Target 'Pods-Trust' has target dependency on Target 'PromiseKit'
→ Target 'PromiseKit' has link command with output '/Users/User/Library/Developer/Xcode/DerivedData/Payd-ampguiegvrhgtrfmpddfkkwgmpnf/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/PromiseKit.build/Objects-normal/x86_64/PromiseKit'
○ Target 'PromiseKit' has a command with output '/Users/User/Library/Developer/Xcode/DerivedData/Payd-ampguiegvrhgtrfmpddfkkwgmpnf/Build/Products/Release-iphonesimulator/PromiseKit/PromiseKit.framework/PromiseKit'
Had similar thing few times - try to delete derived data + clean project + pod install ... at least it worked for me
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.
I have two stack projects, A and B. B depends on A; B's stack.yaml is the following:
resolver: lts-12.10
packages:
- .
- ../path/to/A/
where there exists a file ../path/to/A/stack.yaml, and stack build in A's directory builds successfully.
In B's directory, I stack build --ghc-options -v, and stack builds A, then proceeds to trying to build B, failing to find A's modules. I don't know how stack works, but the verbose output shows that GHC is looking only in ./.stack-work and ./src/ - not in A's directory. Running stack dot produces a diagram with nodes A and B, but no arrows between them. It's like stack is seeing A but not as a dependency of B.
stack solver reports that no changes need to be made.
Using latest stack (v1.7.1)
Found the answer on another SO article: the piece I was missing was adding A's package name to the dependencies list in B's package.yaml file. This hadn't occured to be earlier, as I'd incorrectly assumed that dependencies was for upstream repository packages only.
It's my understanding (1) that the build-depends section in my project's .cabal file will ensure packages specified there are present in the resolver specified in stack.yml are available (in the appropriate versions) and used when I test or run my package (e.g., with stack ghci or stack test, etc.).
I also gather (2) that the extra-deps section of my stack.yml is used to acquire packages that are not in the specified resolver.
But I'm confused about the role of
stack build some-package
How does this differ from extra-deps? Will some-package be used when I stack test or stack ghci etc.? Why use it instead of just adding some-package to extra-deps? (And, have I got (1) and (2) right?)
The main purpose of the build command is to actually trigger the build, i.e. compilation. By default stack build will build all the "local" packages listed in the stack.yaml's packages section. If you pass a package name as an argument to build, that has usually one of the following two purposes:
You want to build only a certain (local) package in a multi-package project
Or you you want to install an executable from a non-local package, for example hlint. Typically you will do this with stack install PKG which is a shortcut for stack build --copy-bins PKG.
One core design principle of stack is that builds should be reproducible, i.e. a project with the same code and same configuration should always give the same result for stack build.
That means that stack build or stack install will never change the project configuration or add dependencies to the project.
For more details on the build command, take a look at the relevant docs.