Quite quiet here today :)

Hmm...

I was trying to work out if this is perception, my impression was there was a core of 10 or so.

Well, no matter what, multiple answers are almost always a good thing

Indeed

Nice answer @RichardSlater

To the "Q: Specific Contributors driving away Community Expansion" or the "Q: Git & Jenkins: get latest green commit on branch" ?

The meta one

I don't think you updated the bitbucket one, did you ?

Aww, missed it. I assume this doesn't fit in one answer, right ?

(Got it, I had the question filter on newest instead of active)

It might do, I wanted to give the community the chance to up/downvote both answers. Both answers are still answers. I'm half expecting the OP to come back and say, "great - how do I do it in node".

Nope, I think you missed OP's goal is to consume bitbucket API from within Jenkins

So Jenkins job checkout the green commit instead of the HEAD one

But maybe it's me who misunderstood it

I disagree, the OP is searching for a solution to a problem which in general doesn't exist, countless clients have started trying to do CI/CD in the way the OP originally describes it but have refactored it out because of the very limitations the OP describes.

I'm still wondering why the build job is not chained from the test job in fact, I assume I missed something

Ping @Alex to cut this :)

"updating a stack with the latest green develop once every couple of hours" - there is no such thing as a "Green develop". develop is source code, something being green can only get that way if you build it when you build it you create artefacts that were tested to prove that the artefacts were working as expected.

@RichardSlater fairly disagree, therés a bunch of language not needing a ´build' to run unit tests

Ruby, Php, Javascript

i.e. interpreted languages, even those languages are reliant upon underlying software versions - typically the build outputs stored in a artefact repo include the specific environments they are tested to work within.

more or less, all interpreted languages, even R just need a checkout to be tested

not quite, you need a checkout and a working interpreter ;-)

@RichardSlater you are biased toward containers here :)

container?

The environment has not to be part of the artifact

Container as in Docker?

For example yes, could be a VM created for the tests also

I've not done very much with containers, of the two pipelines I build I did use an artefact repository yes. However I also have used the same patterns with Java, .NET, Ruby and Node.

I don't get your point then

@RichardSlater this one.

It's not simply enough to say that Product X at commit fe453ea passed all unit tests, you need to make some assumptions - Product X at commit fe453ea will pass all unit tests assuming runtime version 1.2, dependencies are pinned to x, y or z. Once you have made those assumptions (in the case of node I rewrite the package.json to reference the specific runtime and package dependency versions) you can have a high degree of confidence that they will continue to work.

if between two runs of the fe453ea commit you have upgraded from Node 0.8 to 0.9 on your build servers you could well end up with a failing build. Defining those assumptions at a technical level, i.e. through package.json as an example, increases the probability of deliverying working software.

Indeed, but the ugly way is to have a controlled environment. Not assuming, but knowing the needed environment is already setup by anothe mean and taking the (highly debatable) path it is not the application responsibility

Let's let the voters decide, happy if my first answer falls to the bottom. As it stands the first answer has two upvotes and no downvotes.

Or in another point of view: I'm running on a PAAS with this characteristics, I've no control over them, no reason the app should handle the versions of dependencies

Of course, just sharing my thoughts :)

(And playing devil's advocate a little)

PaaS you do actually have control over the dependencies, on Azure it's called OsFamily and OsVersion - that dictates the underlying SDK and thus API that is the interface between your application and Azure.

Similarly exists for AWS Lambda in that you choose what runtime the function is to be written in and AWS Guarentee that this will be available for at least 12 months.

That's it, you choose at deploy which runtime you want

provisioning actually

I won't say provisioning for lambda, but well, side case

you can't transition a lambda function between NodeJS and Java you have to delete and reprovision

you can deploy NodeJS to a lambda function multiple times

Can we agree this is out of the point I was trying to make ?

Sum up counselor.

By that I mean summarize the point you were trying to make.

That the target env is know and not mutable out of control, so there is less reason for the app to embed this information

Yes, there is a risk/reward - or law of diminishing returns that is applied to this technique.

why I said less answer not No reasons :)

For php for example it is not rare to have no control over the underlying version and modules in shared hosting (dangerous by themselves), so you just have to ensure your test node is in line with your hosting node. That's far from ideal, but there is few reasons to handle the modules versions when you have no control over them

I still agree the proper path is to make an aterfact whatever it is (even a simple tarball) with a version bump or just Snapshot when the tests pass and deploy from this artefact instead

Ha! Continuous Deployment into Shared Hosting - now that is a job that takes a solid constitution.

Don't laugh, I've one :(

Kind of ugly, but works as the product owner wish ...

Gtg for now

my commiserations