#git checkouts

1 messages · Page 1 of 1 (latest)

mossy parcel
#

I have the following and am seeing a potential bug with multiple branches named similarly and a question about some behavior in the git checkout:

        c, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stderr))
        if err != nil {
                panic(err)
        }
        repo := c.Git(os.ExpandEnv("https://testing:$DAGGER_TOKEN@gitlab.private/code/repo"),
                dagger.GitOpts{KeepGitDir: true})
        checkout := repo.Branch("py3")
        ckout := checkout.Tree()
        CommitID, err := checkout.Commit(ctx)
        if err != nil {
                panic(err)
        }
        fmt.Println(CommitID)

        alp := c.Container().From("alpine").
                WithDirectory("/checkout", ckout)
        alp.Export(ctx, "alp.tar")
#

so I want to checkout the py3 branch but the repo has two branches that contain "py3":

#

but you can see that I print out the commit ID which is the latest commit on the other "foo/py3" branch

#

then, when I load up the container, something is being done to the checkout such that it is no longer on any branch:

Not currently on any branch.
nothing to commit, working tree clean
# git branch
* (no branch)
  py3       
# git log -1
commit 67f207a9599444fc1f3c1a42781cbc4d59546386 (grafted, HEAD, tag: py3, py3)

I don't see any local changes compared to the branch and there is a tag that was created but not defined in this repo.
because of the tag, now I get warnings when switching back to the branch:

warning: refname 'py3' is ambiguous.
Switched to branch 'py3'
#

I ask because I'd like to put up some guardrails to make sure that the local repo checkout is indeed on the right branch.

zenith harbor
#

in the meantime you can use the full ref with refs/heads/$branch_name

mossy parcel
#

ah, I also wondered what was responsible for masking the git credentials in .git. the build process that I work with really wants to inspect git state with commands like "git rev-parse --abbrev-ref HEAD" but checking out refs/heads/branch kind of breaks that, but also it doesn't work regardless with the detached HEAD state that buildkit is putting the checkout into. (that isn't being address by the PR, is it?)

zenith harbor
#

the build process that I work with really wants to inspect git state with commands like "git rev-parse --abbrev-ref HEAD" but checking out refs/heads/branch kind of breaks that

I think this will be the case regardless if you use the branch name directly or refs/heads/$branch_name since the way buildkit clones the repository is through a git fetch -u and then git checkout FETCH_HEAD

zenith harbor
#

it should be safe to change the --abbrev-ref command with this one

mossy parcel
#

yes, name-rev works!
also, I am able to fetch large files from Git LFS enabled repos with the git-lfs package installed and checking for .gitattributes in the repo, followed by git remote set-url origin to reestablish the secrets that buildkit is masking and 'git lfs fetch'

zenith harbor
#

that's awesome! is there anything else we can help with or can I go ahead and close this support request?

mossy parcel
#

well, I'm not sure if this is good or bad, but I probably should understand it because I'm bound to get questions about it. I'm pulling down a bunch of repos in parallel, you see.., is there anything to read that explains the UI for this?:

zenith harbor
#

well that's a visualization that displays concurrent progress of inter-dependent steps in the dagger execution graph.

#

so it seems like you're running a bunch of stuff in parallel that depends on that purple step. Can't really see what that step is about

mossy parcel
#

that's probably the flatten step. I guess I can tinker with the with{,out}Focus and try creating Pipelines. thanks

zenith harbor
#

you can always change the --progress to plain if you prefer a non-TUI output

zenith harbor
#

hey @mossy parcel just checking if there's anything else we can help you with 🙏

mossy parcel
#

as far as functionality around git goes, I have some more I want to do with generating release notes by looking at the git history but dagger seems limited by buildkit's checkout depth of 1 and out of scope maybe. and I'm looking forward to evaluating attestation if that is implemented

zenith harbor
mossy parcel
#

I don't know, something about the detached head state and "grafted" state isn't making that easy. I can probably just use the gitlab API. thanks, though.