Support tip? #21
Comments
|
Supporting it still makes sense, though. Given that some Go versions are already installed by default, the support could simply be: |
|
I would like being able to use it in |
|
For now, I've done the following: - name: Install Go
if: matrix.go != 'tip'
uses: actions/setup-go@v2
with:
go-version: ${{ matrix.go }}
- name: Install gotip
if: matrix.go == 'tip'
run: |
git clone --depth=1 https://go.googlesource.com/go $HOME/gotip
cd $HOME/gotip/src
./make.bash
echo "GOROOT=$HOME/gotip" >> $GITHUB_ENV
echo "$HOME/gotip/bin:$PATH" >> $GITHUB_PATH
I haven't tested this with anything but a Linux host. It probably needs a (EDIT: updated 2021-10-17 for new versions and GHA changes 😄) |
|
I've updated my comment above to just build from a clone. It's better than effectively cloning and building two repos to save a line. 🙂 |
|
@zikaeroh, I’d suggest downloading zip archive from - name: Install Go
if: matrix.go != 'tip'
uses: actions/setup-go@master
with:
go-version: ${{ matrix.go }}
- name: Install Go
if: matrix.go == 'tip'
run: |
export GOROOT_BOOTSTRAP=`go env GOROOT`
export GOROOT_FINAL=/go
export GOROOT=$HOME/gotip
mkdir $HOME/gotip
cd $HOME/gotip
curl -s 'https://go.googlesource.com/go/+/refs/heads/master?format=JSON' | awk '/"commit"/{print substr($2,2,40);exit}' >HEAD
awk '{printf("gotip-%s",substr($0,0,7))}' <HEAD >VERSION
curl -s -o go.tar.gz https://go.googlesource.com/go/+archive/`cat HEAD`.tar.gz
tar xfz go.tar.gz
cd src
bash make.bash
echo "::set-env name=GOROOT::$GOROOT"
echo "::add-path::$GOROOT/bin" |
|
Go is actually hosted on googlesource/gerrit, where changes are made; the Github repo is a mirror that is automatically updated by gopherbot (really, something in |
|
@zikaeroh OK, updated the comment to use .tar.gz archive from googlesource. See https://gerrit-review.googlesource.com/c/gitiles/+/47141/ Edit: Download speed from Google’s server seems to be faster than from GitHub. |
|
Using an archive doesn't work, actually. Since Go builds encode a version, they expect to be in a git clone. Downloading the linked tarball: I think a |
|
@zikaeroh oops, forgot about this file. Updated to write
Edit: updated to use |
|
One big asterisk on running tip is the fact that GitHub actions do not support allowed failures. There is no current way to allow a job to fail entirely and still have the rest of the workflow pass. This really defeats the idea of having jobs that test against development releases of languages, as you can't really have them in your normal workflow without complicating things. This is a big bummer for me; I like to have tip running in my pipelines so I can report issues upstream. So far, I can't do this without a lot of extra work (and I may just stick with Travis until there's feature/performance parity). |
|
@zikaeroh isn’t it the
|
|
Not equivalent; that just makes the step skipped and the job continue moving on as though nothing had broken. If compilation or something were to fail and I had that option enabled, then:
Travis does this right, and displays that a job is allowed to fail (even moving them to their own section). GitHub even displays Travis's info. For example, before I fixed a bug in another library that was found in tip's new checkptr option, a build may have looked like: |
|
@zikaeroh then
Cheers. |
|
That is also not the same thing. Fail-fast set to false prevents GitHub from not immediately cancelling every currently running job when one of them fails. It doesn't mean that dependent jobs (or the entire workflow) don't fail. I already use this so I don't lose the output of every other build I run concurrently when one of them fails, as that's what happens. I'm looking for |
|
Ah, I get what you want now. That doesn’t seem hard to implement, have you tried contacting GitHub support? |
|
There is feedback on the GitHub Actions community page, but submitting/upvoting things there feels comparable to firing feedback into deep space. https://github.community/t5/GitHub-Actions/continue-on-error-allow-failure-UI-indication/m-p/37033 Either way, it's not relevant for |
|
Have a look at https://github.com/maxatome/install-go to support any go version including tip. |
This builds the latest Go version by checking out the code and building it. The steps are based on actions/setup-go#21 (comment).
The steps are based on actions/setup-go#21 (comment).
|
@maxatome I suspect this isn't officially supported but in practice it's been stable for a long time. You'd need to combine this with a "soft fail" mechanism, but you should be doing that for tip builds anyway. There are some libraries to help with this. The https://pkg.go.dev/golang.org/x/build/buildenv#Environment.SnapshotURL See an example of using it here: Note from that interface that the I used this as part of a Go benchmarking system that I never finished, but I suspect you could use these functions to write a faster version of the |
|
I did some tests with List of builder types |
|
I was assuming that you could pick any of the builder types for a given GOOS/GOARCH pair. The code I sent you picks the shortest builder name. Here's the list I get, with the GOOS-GOARCH printed too. package main
import (
"fmt"
"golang.org/x/build/dashboard"
)
func main() {
for name, conf := range dashboard.Builders {
fmt.Printf("%s-%s\t%s\n", conf.GOOS(), conf.GOARCH(), name)
}
}List of builder types |
|
Still, seems like a decent number of them don't always have snapshots available. Updated the script a bit and used package main
import (
"fmt"
"golang.org/x/build/buildenv"
"golang.org/x/build/dashboard"
)
const rev = "5d6d9f5610066584374c2dfe7624fa9f251089a0"
func main() {
for name, conf := range dashboard.Builders {
if conf.IsRace() || conf.SkipSnapshot || conf.KnownIssue != 0 {
continue
}
url := buildenv.Production.SnapshotURL(name, rev)
fmt.Printf("%s-%s\t%s\t%s\n", conf.GOOS(), conf.GOARCH(), name, url)
}
} |
|
@mmcloughlin done, you can now use: on my last tip test on go-testdeep it took 5 secs to setup go vs more than 3 mins before:
Example of use: https://github.com/maxatome/go-testdeep/blob/master/.github/workflows/ci.yml#L24-L25 Thanks for your help! |
|
@maxatome Nice! I'm curious why you didn't choose Go for the installer? I was thinking you could fork this: https://github.com/golang/dl/blob/master/gotip/main.go You could make a Anyway, if it's Go you can use the |
|
@mmcloughlin perl executable is available almost everywhere. A go compiler is not. |
|
@maxatome Got it, yeah Perl is ubiquitous. Don't the Github Actions runners have preinstalled versions of Go? It says they have the last three versions cached but I don't know if https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu1804-README.md#go |
|
Go is definitely on PATH, that's what my #21 (comment) uses to avoid running setup-go. Perl is less ubiquitous when it comes to Windows, but GHA images have perl too. IMO there's really no difference between using the two at that point, if GHA images are guaranteed to have Go anyway. You can fairly easily just do Best case, this code is stuck into setup-go and supported, if the Go team is actually okay with a mass of people grabbing these snapshots when they were intended for the Go builders. They could get cached, but that's going to be one huge cache. |
|
@zikaeroh That's good, yeah I was thinking it would be fine if you could just use the pre-installed Go. It doesn't need to be a specific version, just not ancient. Right, I should say I definitely don't speak for the Go team. I just discovered these snapshots once when I saw a post from Brad Fitzpatrick. He used the snapshots to produce a graph of the tarball size over time. If people on here want to use it for their own projects that's probably fine. If we actually want this in Also would the cache need to be huge? Installs would only need the latest snapshot, you could expire the older ones. |
I guess that depends on the definition of huge. I was thinking that big list of potential snapshots cached for a few versions by the big size of the download, but I guess that's not "huge" for the likes of GitHub or Google; they've probably forgotten how to count that low. 😃 |
I think asking golang-dev sounds right. Assuming they are OK with it, I think the logic should be to try downloading a prebuilt archive, and fall back to a source download and build. |
|
Thank you for helpful discussion. strategy:
matrix:
go-version: [ 1.16.x, 1.17.x, tip ]
runs-on: ubuntu-latest
steps:
- name: Install Go stable
if: matrix.go-version != 'tip'
uses: actions/setup-go@master
with:
go-version: ${{ matrix.go-version }}
- name: Install Go tip
if: matrix.go-version == 'tip'
run: |
curl -sL https://storage.googleapis.com/go-build-snap/go/linux-amd64/$(git ls-remote https://github.com/golang/go.git HEAD | awk '{print $1;}').tar.gz -o gotip.tar.gz
ls -lah gotip.tar.gz
mkdir -p ~/sdk/gotip
tar -C ~/sdk/gotip -xzf gotip.tar.gz
~/sdk/gotip/bin/go version
echo "PATH=$HOME/go/bin:$HOME/sdk/gotip/bin/:$PATH" >> $GITHUB_ENV |
dsame
added
needs eyes
wontfix
|
Building the go from source impacts the action performance while not being useful for most of users. Since this advanced use case has a workaround with the custom build step the request it rejected. |
|
I'm sorry but that doesn't make sense. Building Go is quick - it takes a minute on a slim laptop, and it can be cached on your side easily since the build is fully reproducible. This is not a niche or advanced use case either. Testing on Go pre-releases and development versions is crucial to spot any upstream issues or incompatibilities early. |
|
@dsame In addition to @mvdan's reply I wanna say you don't even have to build tip from source, it will be helpful even if setup-go will implement same thing as in #21 (comment) and thus became a complete solution which doesn't need extra steps/workarounds to run tests on tip. |
|
Active discussion in #439. Suggesting to upvote there. |
That link is dead. I've been using the manual download solution from #21 (comment), but recently it started failing on the latest commit. It does not seem like https://storage.googleapis.com/go-build-snap has that snapshot anymore. Does anyone know of an alternate location to download gotip bundle? |
I wonder if it's related to golang/go#63471. |
Travis CI no longer works for ogórek and https://travis-ci.org/kisielk/og-rek returns "not found". -> Switch to GitHub Actions to fix CI. We loose CI coverage for "go tip" as specifying "tip" Go version in actions/setup-go is not supported out of the box: actions/setup-go#21 Maybe in 201x it was relevant to test wrt go tip, but nowdays I think this is no longer much needed.
* Switch from Travis CI to GitHub Actions Travis CI no longer works for ogórek and https://travis-ci.org/kisielk/og-rek returns "not found". -> Switch to GitHub Actions to fix CI. We loose CI coverage for "go tip" as specifying "tip" Go version in actions/setup-go is not supported out of the box: actions/setup-go#21 Maybe in 201x it was relevant to test wrt go tip, but nowdays I think this is no longer much needed. * CI += go1.16 - go1.22 Add CI coverage for all releases past go1.15 that we had before.
and others
I looked through the installer.js script and it looked to me like only tags from https://github.com/golang/go/tags are supported as valid versions to install.
I would imagine that some users would also want to test their Go programs against
tipto ensure that upcoming language changes/additions don't break.Go even provides a way to install
tipvia https://godoc.org/golang.org/dl/gotip (once you have a single Go version installed that is).What do you think?
The text was updated successfully, but these errors were encountered: