[JENKINS-31437] attach properties to resources, inject properties at build time

[McFoggy]

This PR allows to define properties, a list of key/value pairs, attached to each resource. On the project then you can decide to receive (as build parameters) the properties of the elected resources.

I use this feature to define named pools of resources that I can then use at build time. Especially, by product family (named pool) I am able to define resources and for each I define for example the host name, host ip, communication ports, ...

[McFoggy]

I created JENKINS-31437 to track and ask for inclusion of this PR.

[prediktorn]

This would be great!

[nick-rumyantsev]

Should this be updated to comply with Pipeline step?

[McFoggy]

@izzekil do you have pointers/link to plugins code/repos to comply to that?

[ajithhub]

Very excited about this. Lockable resources with relevant properties is exactly what I'm looking for.

[aneesh-joseph]

this would be super awesome, waiting for this to be released :smile:

[itsamenathan]

Any news on when or if this will be released?

[aldialimucaj]

OP any thoughts about merging?

[lachiemurray]

Would like this too

[jimklimov]

Looks neat, but has to be rebased/re-merged against current master branch.

On a side note: would it be a big further leap to also publish the resource instance's assigned labels, the labels which matched for the current selection, and the description (all as string variables, perhaps named with the base-name user requested for storing the name of the resource instance plus some suffix?) I guess not, after all the work done here? It would nicely address several open issues/feature requests...

[jimklimov]

FWIW, I posted https://github.com/McFoggy/lockable-resources-plugin/pull/2 against @McFoggy 's branch to bring this codebase up to date against master. The best test of the update I could do is for it to be compilable and successful with mvn test; conflicts were resolved in a way which made sense to me by logic - but not sure how correct the resulting Java is (ain't my native tongue).

[McFoggy]

Hi there, as it was long requested I reworked this PR to rebase it, add pipeline support and introduce some integration tests.

You can now, additionally to standard usage, use properties inside a pipeline job:

echo 'Starting'
lock(label: 'RES', quantity: 1, injectProperties: true) {
  echo 'injected id: ' + env.id
}
echo 'Finish'

added parameters:

• injectProperties: true/false, controls if resource properties are merged inside the step environment variables
• prefixProperties: true/false, if true and if variable parameter exist then injected properties will be prefixed with the value of the variable followed by an underscore.
  • given the resource r1 {label: 'RES', properties: {'id':'prod'}
  • defining step lock(label: 'RES', quantity: 1, variable: 'kind', injectProperties: true, prefixProperties: true)
  • will make the injected id property accessible under: env.kind_id
• uppercaseProperties: true/false, controls if resource properties keys are put upper case

Even for standard builds I added the possibility to prefix & uppercase the injected properties.

[McFoggy]

I need some more time to review what makes the tests fail.

[McFoggy]

tests are fixed.

[McFoggy]

@amuniz any chance to get a review?

[McFoggy]

@amuniz @abayer may I please request some feedback (positive or negative) on this 2.5 years old PR?

[kddubb]

:+1: Would love to see this get merged...anything I can do to help?

[McFoggy]

anything I can do to help?

provide some help to keep it up to date? I am a bit out of time to keep the PR aligned with master until it got merged.

[jimklimov]

I tried to give the resync a shot in updating my PR https://github.com/McFoggy/lockable-resources-plugin/pull/2 but there are quite a few conflicts I'm not qualified to make heads or tails of and resolve logically properly :)

Although it seems you've rebased your commits with newer pipeline-compatible code, so my earlier PR actually grows from a different revision of your work that's no longer in the current branch's git tree, right?

Currently the branch my PR is made from is your older codebase synced up with current upstream/master.

[McFoggy]

there are quite a few conflicts I'm not qualified to make heads or tails of and resolve logically properly :)

That's why I also can't maintain unmerged by myself my PR in synch with upstream that is constantly evolving (which is normal).

that's no longer in the current branch's git tree, right?

you're right. Thanks for the trial anyway.

[theearthwanderer]

when is it going to be merged? thank you

[gaspardpetit]

I will be taking a look at this merge request. It's quite old and cannot easily be rebased so I'll submit it as a new branch based on this one.

[mPokornyETM]

close as it is trimmed to a lot of other PRs and this one will be no more possible to merge (due many of conflicts)