feat: allow specifying nightly builds

[jedevc]

Warning

Needs testing!

The version field now accepts two additional fields:

• A sha1 git hash of a main commit
• The value "head" for the latest commit on main

This will allow users to put in nightly builds into their action.ymls, so that we can more easily allow testing with new versions of dagger.

[sagikazarmark]

/home/runner/work/_temp/8df93b16-410d-4bad-bb0e-b4276f155e09.sh: line 21: syntax error near unexpected token `else'

https://github.com/sagikazarmark/daggerverse/actions/runs/11281337948/job/31376343680

[jpadams]

@jedevc I tested this logic locally and it works well

# Determine the version to install
if [[ "$VERSION" == "latest" ]]; then
  # Get the latest version.
  #
  # Set the version back to an empty string. This allows the install
  # script to detect and install the latest version itself.
  VERSION=""
elif [[ "$VERSION" =~ ^v ]]; then
  # Get the specified version.
  #
  # No need to set anything.
  :
elif [[ "$VERSION" == "head" ]]; then
  # Get the latest nightly build from "main".
  #
  # Set the commit to "head".
  COMMIT="$VERSION"
  VERSION=""
elif [[ "$VERSION" =~ [a-z0-9]{40} ]]; then
  # Get the specified nightly build from "main".
  #
  # Set the commit to the specified commit sha.
  COMMIT="$VERSION"
  VERSION=""
else
  echo "Invalid version specified: $VERSION"
  exit 1
fi

TIL to use : as noop in bash

[sagikazarmark]

Run jedevc/dagger-for-github@259c2cdbc8915a3529d4f9c132208c597391104e
  with:
    verb: call
    module: github.com/sagikazarmark/daggerverse/apko/tests@refs/heads/main
    args:  all
    version: head
    dagger-flags: --progress plain
    workdir: .
    engine-stop: true
  env:
    GITHUB_TOKEN: ***

Invalid version specified:

[sagikazarmark]

Probably needs this line?

[sagikazarmark]

Works on my daggerverse: https://github.com/sagikazarmark/daggerverse/actions/runs/11300133297

[jedevc]

Tested that this works as desired using #153 (see https://github.com/jedevc/dagger-for-github/actions/runs/11331238930/job/31510817051).

[gerhard]

Some of this logic is already implemented in install.sh as well as install.ps1, e.g.

  if [ -n "$DAGGER_COMMIT" ]; then
    path="main/${DAGGER_COMMIT}"
  elif [ -n "$DAGGER_VERSION" ]; then
    path="releases/${DAGGER_VERSION}"
  else
    path="releases/$(latest_version)"
  fi

Instead of adding new behaviour to the version property, I would add a new property - maybe build - and pass it through as DAGGER_COMMIT which already has higher precedence than DAGGER_VERSION.

If we did that, this would become a much smaller change. We could also test those functions in isolation, rather than needing to test this GitHub Action.

[jedevc]

IMO it makes more sense to have a single combined field whenever possible - having multiple fields with precedence, etc, is confusing for end users.

Maybe we should put this logic into install.sh and install.ps1 and deprecate the old commit variable? That seems like a better interface than inheriting the separate variables that the install scripts do.

I also think we should add the tests regardless of what we do here - agreed it sucks not to be able to be able to test them outside of GitHub - but given the fragility of GitHub actions in general, having some sanity tests that just check it's working is still useful IMO. Especially if we go on to upstream more behavior from our custom "call" action in dagger/dagger.

[gerhard]

The best approach would be to pass both values as they are and trust install.sh to do the right thing.

head only makes sense in the context of COMMIT as in the HEAD commit for the main branch, i.e.

❯ curl -I https://dl.dagger.io/dagger/main/head/checksums.txt
HTTP/2 200
content-type: text/plain; charset=utf-8
content-length: 1838
date: Tue, 22 Oct 2024 15:09:24 GMT
last-modified: Tue, 22 Oct 2024 12:46:28 GMT
etag: "8b336b45f49a98e101aaa43ca402ae32"
x-amz-server-side-encryption: AES256
content-disposition: attachment;filename=checksums.txt
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 01c1372965efe3974af81a7941e07b0c.cloudfront.net (CloudFront)
x-amz-cf-pop: LHR5-P7
alt-svc: h3=":443"; ma=86400
x-amz-cf-id: kYBZp0pDrxYjecpPfJFjnAgNmxUTFZUQhHPXBNQ3qZujDOmjLdPWKw==

latest only makes sense in the context of VERSION as in the latest version, i.e.

❯ curl -I https://dl.dagger.io/dagger/versions/latest
HTTP/2 200
content-type: binary/octet-stream
content-length: 7
date: Tue, 22 Oct 2024 15:10:49 GMT
last-modified: Thu, 10 Oct 2024 22:27:36 GMT
etag: "818b6f96a7646a5e9e0ede3d9a27e78d"
x-amz-server-side-encryption: AES256
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 f5db953762dd20ad78d8b2c1e8d66550.cloudfront.net (CloudFront)
x-amz-cf-pop: LHR5-P7
alt-svc: h3=":443"; ma=86400
x-amz-cf-id: Dm3qHYxI8k6fqtsnIrBvV4ZuLGtrktmJWD6Bx_0y3DEveUt6ukbZpg==

Expected behaviour:

1. version defaults to a specific version
2. version can be set explicitly, e.g. 0.13.4
3. commit is empty by default
4. if commit is set, it takes precedence over version
5. commit can be set to a specific git sha
6. commit can be set to head

[jedevc]

head only makes sense in the context of COMMIT as in the HEAD commit for the main branch, i.e.

Done.

The best approach would be to pass both values as they are and trust install.sh to do the right thing.

We can't do this yet - we need to update install.sh to handle "latest" if we want to do this.

$ curl -fsSL https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=latest sh
sh debug downloading files into /tmp/tmp.gWarmHq8ep
sh debug http_download https://dl.dagger.io/dagger/releases/latest/dagger_vlatest_linux_amd64.tar.gz
sh debug http_download_curl received HTTP status 403

[gerhard]

LGTM!