-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assorted build system and plugin metadata improvements #54
Assorted build system and plugin metadata improvements #54
Conversation
While at it, correct version number to follow the convention all Tier 1 plugins use (X.Y.Z not vX.Y.Z).
* Use COPY and wildcards instead of ADD in Dockerfile as it's a recommended best practice * Use 3.7.7 in Docker images * Move this plugin's targets to the bottom of the file
Thanks! When I do fresh builds (without deps populated) I always see this:
no matter master or tag. Despite this build goes ok. Would be cool to get rid of this while we are on it. Any idea? Or this PR solves it already? |
@deadtrickster that's because it assumes that This PR doesn't solve this as the logic comes from |
We can modify |
imo throwing everything to /dev/null is too much. it could just discard output of first network-local clone. or store it somewhere and present iff all cloning attempts failed. |
after merging I have this error:
I'm on master and git log for deps/rabbit:
|
@deadtrickster I'll ask around how we solve this for other plugins. Worst case we can drop the requirement. IIRC server version of 0.0.0 should be accepted by any requirements string. |
It turns out in the 3.7.x series we switched to using Git tag objects (instead of lightweight tags that are references), so |
I commented it already :-) |
Assorted build system and plugin metadata improvements
This started as a small PR that only added
rabbit
as a dependency but ended up being a bunch of build system improvements that I had to make to build the plugin from source against the tip of RabbitMQ3.7.x
.