I am using http://github.com/tmthrgd/go-bindata to embed static files and templates within Go executable file. It requires to run go generate to run a Go code that read each file and write binary representation as standard go file. go generate have to be fired before build process.
Is there a chance to configure Heroku to handle this?
go generate should be run locally while developing, not on heroku. If you run it on heroku it will lead to very hard to debug issues. If go generate has unexpected results you wont be able to easily inspect this.
You could run go generate with a tool like modd or with a git hook.
Having the results of go generate tracked by git also means that you can track which changes affected generated code.
In a language like ruby it might be customary to run bundle install on the server and omit dependencies from git. For go programs this is not so. Dependencies should be vendored and tracked by git. Same for generated code.
The rest is not at all advised for this case and I would never do something like this.
fork the go heroku buildpack
add a line to run go generate
use your modified go heroku buildpack
deploy your app
around this line
more on buildpacks
Related
I have a config file for my go program, and clearly it has different values when I run locally vs on my server.
My boss recently asked me to switch deployment methods so that I run "go build" locally, and then deploy that build. Thus, I need to switch out my global config file each time I build.
Unfortunately, I have a piss poor memory, and I'll almost certainly forget to switch these files out. I would love if there were way (maybe in a build script file, or anything) to use different config file when building as opposed to running "go run main.go" as I usually do when I am working locally on development.
Does anyone have any ideas or best practices here?
Note: I already gitignore this file, but since building if basically solidifies the whole program (including these set variables) into a single file, just having another file on the server wouldn't do.
Thanks all!
Use build constraints.
Here's an example:
config.go
//go:build !live
// Add your local config here
config_live.go
//go:build live
// Add your server config here
Use go build to build the local version. Use go build -tags live to build the server version.
When a private agent build starts in VSTS, it gets assigned a directory, e.g. C:\vstsagent_work\1\s
Is there a way to set this to a different path? On other CI servers, like Jenkins, I can define a custom workspace for a job. I'm dealing with a huge monorepo and have dozens of build definitions around the same repository. It makes sense (to me anyway) to share a single directory on the build agent computer.
The benefit to me is that my builds can use pre-built components from upstream repositories, if they have already been built.
Thanks for any help
VSTS build always creates a working directory per build definition. This leaves you two options:
Create a single build definition and use conditionals on steps to skip certain steps in order to only run what is needed. This allows you to use the standard steps and may require a powershell script to figure out which steps to run and which ones to skip. Set variables from powershell using the special logging commands.
Disable the get sources step and add a step that manually fetches sources. You'll need to clean the working directory, checkout the right commit, basically replicating the actions in the get sources step manually. It may require some fidgeting to get all the behavior correctly for normal build, pull request builds etc. That way you can take full control over the location where sources are checked out.
I'd also recommend you investigate the 2017 project formats that use the new <packageReference> in the project files to fetch packages. The new system supports configuring a version range which can always fetch the latest available version of packages. It's a better long-term solution.
No, it isn’t available in VSTS build system.
You can change working directory of agent (C:\vstsagent_work) (Re-configure it and specify another working folder), but it won’t uses the same source folder for different build definitions, the folder would be 1, 2, 3 ….
In starting a new project, I put together the skeleton for a Node app that has tests and generates some build artifacts, like asset compilation and compression. I have the tests running in Codeship so successful builds initiate a deploy to Heroku. They've made it all super easy, except I can't find any way to deploy built files, just a copy of what's in the repo.
Has anyone done this successfully? I feel like writing a custom deploy script to rebuild the assets after the tests and manually deploy them would be working against the existing toolset, and I know can't possibly be the first person to want to do this...
Turns out that Codeship doesn't keep anything, in fact, different servers do the deployment than the testing. It seems that the best-practice here is to recreate the assets on the Heroku side with a custom buildpack, which, directly after the git pull, does the dependency installation and compiles the app slug.
I have a catalog of builds indexed by git revision stored on s3 by our CI server. Instead of performing a build at deploy time, I would like to just download a pre-built application, unpack it and go.
I'm trying to accomplish this with a custom buildpack, but in order to do so, I need for it find out which revision of the code is being compiled. Sadly (for me), I can not find this information anywhere in the environment.
It seems like this is something that ought to be discoverable somehow, but I'm completely flummoxed as to where.
You might want to take a look at the (not officially supported) heroku-anvil plugin, which includes the heroku release command to push externally created slugs to a Heroku app. It was originally designed for working with slugs created with Anvil, but should work for any TAR GZ, as long as it can be run on Heroku. For example you could do something like this:
$ heroku release https://s3.amazonaws.com/my-bucket/slugs-000.tgz -a myapp-staging
Releasing to myapp-staging.heroku.com... done, v42
I'd like to develop a heroku app with the neo4j addon, and i've followed the instructions here but I'm lost as to how to integrate the heroku-like environment variables into my local development environment.
My major goals:
Make things behave as similarly as possible to the deployed app.
Allow me to run automated test suites locally.
Allow me to run the app locally, for quick development iteration.
The only heroku helpcenter article I've found (here) that deals with this seems to recommend always deploying, but this means I have to check-in and push every little edit I make, syntax errors and all, and doesn't allow for running automated tests locally.
It seems like there should be a way for me to edit my Foreman Procfiles to get the desired behavior, but I don't see how I can do that without affecting the deployed processes as well.
This article seems to be what I needed, although I'm still not sure how I was supposed to find it: https://devcenter.heroku.com/articles/config-vars#local-setup
In summary, you can do heroku config > .env to install the production environment locally, then edit the file as needed. Foreman then uses this file to set environment variables.
The article recommends adding the .env file to .gitignore, but as far as I can tell, checking it in is safe since it seems heroku seems to already override it.