Ticket #100 (closed enhancement: fixed)

Opened 2 years ago

Last modified 14 months ago

Builder should be able to take a 'env' argument that applies to all BuildSteps

Reported by: bhearsum Owned by: bhearsum
Priority: minor Milestone: 0.8.+
Version: Keywords:
Cc: dustin, dwlocks

Description

I think it's a fairly common use case that all of a Builder's BuildSteps? require the same environment variables. I propose that the Builder 'setup' should be able to take in a dict of environment variables and pass it along to all BuildSteps? that require/support it (ie. it wouldn't pass it to something like FileDownload?).

I'd be happy to code this up myself assuming it is wanted.

Attachments

builderWideEnvironnment.diff Download (1.5 KB) - added by bhearsum 23 months ago.
builder-wide environment
builderWideEnvironnment-v2.diff Download (1.5 KB) - added by bhearsum 23 months ago.
same as before, fix stupid error (setup.get(env?) -> setup.get('env'))
builderWideEnvironnment-with-tests.diff Download (6.6 KB) - added by bhearsum 22 months ago.
again, with tests + clarified ShellCommand?.setupEnviornment
builderEnv-docs.diff Download (1.1 KB) - added by bhearsum 22 months ago.
docs
builderEnv-full.diff Download (8.0 KB) - added by bhearsum 15 months ago.
builder env, better docs, supports properties

Change History

Changed 23 months ago by warner

yeah, that sounds reasonable. I frequently do this by setting up the environment of the buildslave, but I can see where you'd want to do it per-Builder instead. Let's make env= an argument to the Builder __init__ that we should build for ticket #10 .

Changed 23 months ago by bhearsum

Sounds good.

Changed 23 months ago by dustin

  • cc dustin, dwlocks added

+1

Changed 23 months ago by bhearsum

builder-wide environment

Changed 23 months ago by bhearsum

This first patch is as-of-yet untested but I'm pretty sure it'll work. ShellCommands? automatically pull in the Build.slaveEnvironment dictionary.

I'll do some testing today/tomorrow and see how it goes.

Changed 23 months ago by bhearsum

  • status changed from new to assigned

Changed 23 months ago by bhearsum

same as before, fix stupid error (setup.get(env?) -> setup.get('env'))

Changed 23 months ago by bhearsum

  • milestone changed from undecided to 0.7.8

I tested this one and it works as intended and passes unit tests.

Changed 22 months ago by dustin

Looks good .. needs tests, though, and it would be *great* to get rid of:

    def setupEnvironment(self, cmd):
        # XXX is this used? documented? replaced by properties?
        # merge in anything from Build.slaveEnvironment . Earlier steps
        # (perhaps ones which compile libraries or sub-projects that need to
        # be referenced by later steps) can add keys to
        # self.build.slaveEnvironment to affect later steps.

Changed 22 months ago by bhearsum

You're absolutely right about the tests.

Let me do some thinking and tinkering about setupEnvironment() before I comment on that.

Changed 22 months ago by bhearsum

OK, I'm not clear on what you want to get rid of? The function, or the 'XXX' comment..?

Changed 22 months ago by dustin

I'd like to resolve the concerns in the comment -- the function can stay, if it's still in use.

It's part of my "leave it cleaner than when you came" patch policy :)

Changed 22 months ago by bhearsum

Okay, it seems clear that my patch depends on ShellCommand?.setupEnvironment(). After looking at it closer I realized that in its current form, the builder-wide environment will override anything in the BuildStep? environment. I would consider this incorrect. However, if a BuildStep? were to set something in slaveEnvironment it would make sense for it to override the BuildStep? environment (IMHO). Therefore, I propose that a BuildStep? setting something in slaveEnvironment be superceded by BuildProperties?, as suggested by the documentation. I'm pretty sure you can use WithProperties? with env vars, so I don't see any reason to support that operation.

If that makes sense, I can make the following changes to my patch: * Add tests * Make the BuildStep?-environment override the Builder environment * Add documentation that describes the Builder environment, and makes clear exactly how BuildStep? environment setting works.

Changed 22 months ago by dustin

sounds good!

Changed 22 months ago by bhearsum

again, with tests + clarified ShellCommand?.setupEnviornment

Changed 22 months ago by bhearsum

Oops, I forgot to write docs for this. I'll add them shortly.

Changed 22 months ago by bhearsum

docs

Changed 20 months ago by bhearsum

Is this going to get landed for 0.7.8?

Changed 20 months ago by warner

some thoughts:

  • I suspect somebody will eventually complain that WithProperties aren't accepted in the builder-wide settings like they are in the per-step settings.. you might want to merge in the builder-wide dict first, *then* do the properties.render() call
  • if you do that, the docs should be updated to mention this feature
  • the docs should probably have an example of what you might want to use this for. They should also mention the possibility of setting environment variables in the buildslave's startup environment, since variables like that are sometimes slave-specific

Otherwise, it looks good to me.

Changed 19 months ago by dustin

bhearsum, what do you think of warner's suggestions? We can break those out into separate tickets, or fix them here.

Changed 15 months ago by bhearsum

(4 months later)

Yeah, that makes total sense. I'll work that into this patch.

Changed 15 months ago by bhearsum

builder env, better docs, supports properties

Changed 15 months ago by bhearsum

  • keywords review added

Alright, this patch is updated to support properties in both Builder and ShellCommand? environments. I've also added to the docs as per Brian's comments.

Changed 15 months ago by dustin

  • keywords review removed
  • status changed from assigned to closed
  • resolution set to fixed

Changed 14 months ago by dustin

  • milestone changed from 0.8.0 to 0.7.+
Note: See TracTickets for help on using tickets.