fubarhouse/ansible-role-golang

Installs the Go programming language and packages on Mac & Linux (Ubuntu, CentOS)

Hi there, I'm Karl 👋

🎖 Certificates

Github Statistics

ansible-role-golang's Issues

Official Debian 9 support

Progress on this one has been progressed in issue #53

Remove unused templates.

Templates are no longer in use, let's delete them.

Official support for 32-bit architectures, non-inclusive of Windows.

Install go1.4 without GVM for source compilation of later versions.

Add initial FreeBSD support

Move GoPM tasks away from an independent installation

• Create tasks file
• Populate tasks file
• Reference tasks file
• Test tasks file
• Test logic
• Implement where required
• General once-over

Add exported variables to version verification

Add ability to manually install packages.

Post go-get, we should be able to clone any particular go repository (github or not) at a particular version of tag, and then install it manually.

• Run go get tasks
• Clone respective repository to place at version number x
• Install via go

Prevent git task from resetting file system each run

Convert _all_ applicable variables to the GOVAR format

Add Gopher to readme; get travis working again...!

For the sake of character, I've added the golang gopher, and I've been trying without success to get some passing tests... This needs to happen now.

$PATH does not include $GOPATH/bin

$GOROOT/bin in $PATH needs to refer to $GOPATH/bin

Rename GoPM tasks to Go Get/Get

Update the default version to the latest release.

Post go1.8.3 release we'll update our version here for the next release.

Build from source

In addition to issue #1 to install many versions, allow an option to build from source.

• Populate GVM task file with source tasks
• Test tasks on multiple platforms & work out problems
• Quick once-over after everything is in place.

GVM audit...

As I am a proper Gopher now, I am seeing less and less validity in a gvm release - other than building from source.

I want to explore this, and basically figure out if removing GVM support is a good idea. The added complexity and support isn't particularly of interest where the application gets very little use in comparison to traditional installation methods.

Restructure & Compatibility fixes

• get travis tests to pass on all commons environments
• restructure tasks for simplicity
• audit everything, double check everything works, assess the functionality of the go get commands

GVM - Go Version Manager

I need to work out if this is going to be a thing I'll be implementing, and how this role would change to accommodate it.

• https://github.com/moovweb/gvm

It would be rather good if we could install them over the top of the file system and gvm just work automatically, but I need to look at the details.

• Create task file
• Populate task file with tasks
• Test tasks on multiple platforms & work out problems
• Identify why gvm use is failing
• with symlinks now in place, do we really need to gvm use? refer to use script for answers.
• Add tasks to build master
• test tasks to build master
• add configurable installation flags (useful because --binary --source and --prefer-binary are rather unreliable).
• Configurable download mirror which replaces URL in GVM install script
• provide master integration with go_versions to add master as well as multiple other
• logic to prevent master installing where go{{ go_version }} should be installed
• provide better support for <= v1.4 by attempting to completely remove the term 'go' from version strings. Thought: master/source already provides the functionality we need if the variable was to be passed through.
• resolve the path issue with go get
• Quick once-over after everything is in place.

Ensure source installs actually compile

Shell profile paths are not accurate.

On a DrupalVM Precise instance, needs investigation...

Install < go1.4 from source

needs further work - I don't believe this should be done but it would be a nice feature, but it depends on the workload it'll introduce.

Configurable mode for workspace?

• Sensible defaults.
• Configurable mode

Remove commons dependency

There's no need for this dependency anymore, as it's only providing a couple of variables which in the case of this role are typically manually inputted. Two new tasks in setup.yml should cover it.

Cleanup tasks

After #1, #2, #3 and #4 are complete I'll look at a v1.0 release - I'll at least be happy then.

• Add tasks file
• Populate tasks file
• Test tasks
• Test logic
• Implement changes on associated tasks files
• General once-over upon completion

Update documentation for release 2.2

Run get commands, not as root.

Fix `go use`

Shell profiles could use rework.

Had a case today where the vagrant user .bash_profile which should have been touched, was actually the root user file, and the permissions were denied.

• fix file path
• test results.

Official Fedora24 support.

Via docker tests in travis.

Official Debian 7 support

Progress on this one has been progressed in issue #53

Install from source.

Installing Go1.4 via the recommended and setting the $GOROOT_BOOTSTRAP variable (which defaults to $HOME/go1.4/

These variables should be optional, as well as a flag to actually build go1.4 for bootstrapping.
Actual installation will happen via the recommended git release branch.

There should be additional logic for preventing traditional version numbers being used.
source installs are tied to specific versions, without the GOOS or GOARCH variables used in the file name (example: go1.8.1.src.tar.gz).

Building process is unified. ( ./all.bash ), and gcc should be installed for versions prior to 1.4 - but that will probably not be enforced in any way.

This issue supersedes issues #28 and #29.

Allow for configurable GOROOT permissions.

A problem I feel is always getting in my way is folder permissions on GOROOT and/or the package paths under $GOPATH/bin, $GOPATH/src and $GOPATH/pkg.

We should have this as a configurable, with some sensible defaults...

Remove Go Version Manager

Fix the default package set config

Remove documentation about legacy versions...

GVM is quite graceful about legacy versions now, so this was implemented as an integration in v1.2 but I've clearly forgotten to update the README.md about this feature.

Update documentation for milestone release.

Add GOARCH autodetection for supported platforms.

Convert system to ansible GO env vars.

Official Ubuntu 12.04 support.

Via docker tests in travis.

Provide alternative to sync task when absible_ssh_user is defined

Audit the exports

Basically just check over the following:

• GOROOT declaration in shell exports
• GOPATH declaration in shell exports
• PATH=GOPATH declaration in shell exports
• PATH=GOPATH/bin declaration in shell exports

Allow the ability to scrap packages prior to installation.

go_reget: true

Something which performs the function listed above will purge out the contents of:

• $GOROOT/bin/bin
• $GOROOT/bin/src
• $GOROOT/bin/pkg

This will ensure a package is guaranteed to be re-fetched each time a play will run, which will get around an underlying problem I intend on investigating properly at a later date.

Do not reinstall golang when there is no version change.

Isolating the installation tasks will speed up provisioning time significantly.

Prevent the reinstallation of an existing static installation.

Reset file permissions post-install

Update default version to 1.8.1

Set default GOPATH to ~/go

Set system go to 1.4

For the sake of always having a compiler available for post 1.4 versions, we'll make 1.4 available always and set the system go to 1.4.

Remove binary linking from gopm files

Update to working-copy

There were some changes I made in my local PyCharm IDE, obviously some time ago now.
Review and commit those changes, which affect the default installation settings among other changes.