Skip to content

WIP: Golang workflow using "dep" dependency manager #47

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

WIP: Golang workflow using "dep" dependency manager #47

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions aws_lambda_builders/workflows/go_dep/DESIGN.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
### Go-Dep Lambda function builder
Building Lambda functions written in Golang is very straightforward. We use the `dep` dependency manager and
`go` tool to install dependencies and cross-compile the function for architecture that Lambda supports.


The workflow does the following:
1. Check for manifest **Gopkg.toml**
2. Install dependencies using `dep ensure -v`
3. Compile using `GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o $ARTIFACT_DIR/$HANDLER $SOURCE_DIR`
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One question I have is what are the goals for the sam build command. I would love to use a command like this in my workflow, but what if I already have well defined build steps as part of a Makefile in my repo? Make and Makefiles are a pretty common construct within Golang. Could we do something simpler where we just call make build? That way if developers want slightly different arguments, or multiple steps they can still use the sam build api. Maybe this make file could be generated if it is not present the first time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@roryj Right now we want to support the dependency managers directly with good defaults (python, node, and ruby follow this) and then allow/expand to different arguments/multiple step workflows in the future.

4. `chmod a+x $ARTIFACT_DIR/$HANDLER`

#### Challenges
1. **Handler name**: Since the binary must be named after the handler, we have modify the base workflow to pass
handler name to the workflow
2. **Artifact File**: Unlike other workflows, the built artifact is the entire directory. But it is a specific file
within the directory. We need to modify the base workflow to let specific workflows provide the path to artifact file
that will be sent through output.