[users at bb.net] steps.Git(): pass in a revision?

[Linus Arver]

Hello all,

I would like to respond to my earlier email. Maybe it can help others.

I have played around more with the multiple-codebases approach, and it
seems to work the way I want it to. My original problem of Bar depending
on Foo maps exactly to having multiple codebases. I.e., it is a solved
problem for my use case. So, in my AnyBranchScheduler I have

    "codebases": {
        "Bar": {
            "revision": None,
            },
        "Foo": {
            "branch": "known-good-branch",
            },
        },

and whenever Bar changes, I can pull the latest "known-good-branch" for
Foo by specifying "codebase='Foo'" in steps.Git() (source checkout
step). AFAICS the "revision" key for a codebase cannot be a callable (it
would be perfect for me if it was, so that I could find the revision to
sync to on each build), so I have to specify the branch with the
"desired_commit_hash" as "known-good-branch".

I effectively said in my earlier email (point (2)) that I do not have
automation yet to make "known-good-branch" update whenever
"desired_commit_hash" changes --- but it is a simple problem (on every
successful build of Foo, I will just add a step that updates
"known-good-branch").

My original assumption (point (1)) that using multiple codebases would
always result in builds to Bar whenever Foo changed is false. As long as
the change sources do not talk about Foo, changes to Foo never get to
generate a Change object and nothing happens to Bar (which is what I
want).

Linus

On Thu, May 25, 2017 at 09:23:57PM -0700, Linus Arver wrote:
> Hello,
> 
> I have project Bar that depends on another project Foo (uses git). In
> the build steps of Bar, I need to check out a particular known commit of
> Foo, using a commit hash. I would like to use something like
> 
>     steps.Git(repourl=url_of_Foo, revision=desired_commit_hash)
> 
> but steps.Git() only gives branch-level granularity with the "branch="
> keyword.
> 
> What is the recommended course of action? I'm thinking of just using a
> ShellCommand step to invoke `git reset --hard desired_commit_hash` but I
> would like to hear other people's thoughts.
> 
> Here are some thoughts I've had already:
> 
> (1) I am not sure if I want to use a multiple-codebases approach as
> described in [1] because I don't want changes to Foo's repo to trigger
> builds to Bar.
> 
> (2) I could just make a branch on Foo that tracks the
> desired_commit_hash, and check out this branch. But, I do not yet have
> automation to make such a branch update on its own, should the
> desired_commit_hash change.
> 
> Best,
> Linus
> 
> [1]: http://docs.buildbot.net/latest/manual/concepts.html#multiple-codebase-builds