I'm using Heroku and Golang.
I have one or many .scss files and I use a golang library to generate a .css from them.
What I don't understand is how to generate the .css file during Heroku build step.
As stated here https://devcenter.heroku.com/articles/release-phase#design-considerations:
Asset compilation should happen during builds considering the dyno filesystem is ephemeral.
I don't want to commit my generated files.
Am I wrong?
Heroku supports Docker deploy https://devcenter.heroku.com/categories/deploying-with-docker
It means that any transpilations you can do on "Docker build" step
Related
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.
Currently my Heroku CI tests are triggered on all git push to master branch at Github.
Is it possible to avoid triggering CI tests if specific files are being pushed, such as README.md?
Pretty sure heroku processes the .slugignore file for CI as there's an open issue now for ignoring it: https://github.com/heroku/heroku-ci/issues/39
The slugignore docs say
The .slugignore file causes files to be removed after you push code to Heroku and before the buildpack runs.
I don't use heroku ci so I wasn't able to test for sure. YMMV
I've been trying to convert and deploy one of our node.js apps into a lambda function and have been having some problems with the node_modules dependencies - saying that it can't find certain modules. I started by creating a package.json, npm install the dependencies locally then copy the node modules folder up to lambda.
For instance I have a project that requires sequelize and convict and have been getting errors saying that it cannot find the moment module as a sub-dependency. I see that moment is included in the root of my node_modules but it was not included in the sub folder under the sequelize module.
However, this project runs fine locally. What is the difference in lambda and what's the best practice for deploying a somewhat long list of node modules with it - just a copy of the node_modules folder? On some of the other simpler projects I have, the small amount of node_modules can be copied up with no problems.
{
"errorMessage": "Cannot find module 'moment'",
"errorType": "Error",
"stackTrace": [
"Function.Module._resolveFilename (module.js:338:15)",
"Function.Module._load (module.js:280:25)",
"Module.require (module.js:364:17)",
"require (module.js:380:17)",
"VERSION (/var/task/node_modules/sequelize/node_modules/moment-timezone/moment-timezone.js:14:28)",
"Object. (/var/task/node_modules/sequelize/node_modules/moment-timezone/moment-timezone.js:18:2)",
"Module._compile (module.js:456:26)",
"Object.Module._extensions..js (module.js:474:10)",
"Module.load (module.js:356:32)",
"Function.Module._load (module.js:312:12)"
]
}
I resolved this by uploading all from a zip file which contains all the data I need for my lambda function.
you can just create your project in your local machine and make all the changes that you need then the file you are going to zip should have this same structure and also see that there is an option to load your code from a zip file.
This sounds to me like an issue caused by different versions of npm. Are you running the same version of nodejs locally as is used by Lambda (ie. v0.10.36)?
Depending on the version of npm you're using to install the modules locally, the node_modules directory's contents are laid out slightly differently (mainly in order to de-duplicate things), and that may be why your dependencies can't find their dependencies in Lambda.
After a bit of digging, it sounds like a clean install (ie. rm your node_modules directory and run npm install) might clean things up for you. The reason why is that it seems that npm doesn't install sub-dependencies if they're already present at the top level (ie. you installed moment before sequelize, etc).
I have a Leiningen project that is dependent on another Leiningen project. Both are on Github. I cloned the project I am dependent on to the checkouts folder as a Git submodule, which works great in my development environment. I can use the classes from the dependency without even having to add it as a dependency in projects.clj (despite the fact that the documentation says "If you have a project in checkouts without putting it in :dependencies then its source will be visible but its dependencies will not be found").
The main problem is that when I push the project to Heroku, the submodules are cloned automatically but there is no checkouts directory under /app. I guess that Heroku ignores checkouts for some reason.
Presumably I am doing this wrong and there's a right way for me to work in parallel with two Git repos, one of which is dependent on the other. The main issue for me is that I need to be able to deploy my app easily to Heroku. What is the standard way to deal with this situation?
Update: I also noticed that my circle.yml file, which is in the repo, is not in the /app directory. I'm totally confused about what exactly is in the /app directory and where the other stuff disappeared to.
The problem is that heroku runs lein with-profile production compile :all which ignores checkout dependencies (see https://github.com/technomancy/leiningen/issues/1263).
A possible solution is to add :checkout-deps-shares [:source-paths] to your production profile. It's discouraged (according to heroku engineers you really should use an uberjar in production) but it should do the trick.
I'm using DocPad to build my website, and in the docs it's saying that we can use an helper called buildr to bundle, compress files.
Is it possible to integrate buildr execution within the command docpad generate or docpad run?
Also does it needs it own config file buildr.coffee or it's possible to write the configs inside the docpad.config plugin section?
I imagine it would be more or less the same as this gist for grunt except with the grunt stuff changed to buildr.