Get rust toolchain to stable for all builds #58
Conversation
|
Went ahead and also updated |
|
@leifwalsh @geofft can you make a decision about this, either here or in #54? Happy to rebase my PR once this has landed. |
|
I think this looks reasonable, but I need Geoff to weigh in, in terms of how we'd import/build it after merging this. He's very busy right now on some other internal work so I'm trying not to bother him too much. Hopefully some time in the next couple weeks we'll be able to make a decision. |
|
@leifwalsh: if you would like the Debian 10 deb package as an artifact, that would be trivial to add and then the possibility opens up of having an pre-built installable package from every merge to main. Im happy to continue work on this (I selfishly want an RPM for RHEL and Deb for Ubuntu latest available as artifacts too, but that isnt a problem you all need to solve for us). |
|
Just checking in. Has any bandwidth freed up? |
|
My apologies, no, not yet. I promise we want to make this happen and keep collaborating with you all :) @geofft or someone from his team will do the checks we need to some time in April, and I'll do my best to make sure we stick to that. Once we get this or something like it merged and have our internal stuff set up to deploy it, I think that unblocks all the other work the other folks are trying to upstream, or at least, I can review those without as much blocking on Geoff's team. In the meantime, yes, I think getting debs and RPMs published as artifacts sounds ideal. I can probably take a look at that too. |
|
I will take a look at getting debs and rpms published for this at some point soon. |
|
Ok we're fine with deploying debs built in CI here. So it's just up to one of us to make that happen. |
|
Started getting a little bit somewhere #59 |
|
Ok, publishing debs works, feel free to rebase this and make whatever additional change you wanted here. Did we already ask you to sign and send in the CLA? |
|
I sent in a signed CLA before I started work on this. I got an Out of Office response from the receiver (I can find out who if necessary), but didn't follow up after that. I assumed that the CLA in someone's inbox was probably enough :P I've gone ahead and simply rebased these changes forward. I'll have to get to using cargo plugins for rpm/deb building when I have a bit more free time. I will open a new PR for that work. |
|
I am unsure why the codecov report is failing to upload and I'm not entirely sure it's this PR's fault? |
|
Looking at the error again - I think this is either a problem with codecov's servers or with the api token that's stored as a secret in the config for this repo. I can fix neither. My hands are tied until someone can resolve this for me :/ |
|
@leifwalsh with #59 and #60 in, can you take a look at this? Maybe code coverage must be special-cased for external PRs? |
|
Yeah, sorry, we're fighting glibc compat stuff in #61. Once we get that sorted out I think we can merge this and take a look at the others again. I don't think we care about coverage for these, it's probably just a codecov misconfiguration and we can deal with that separately. |
|
@bbenne10 I think you can rebase this now, to just include the dependency version changes, and we can see how that goes. |
|
Done. Took the liberty of rewriting the history of this branch a bit too. Just squashed everything into a single commit that updates the dependency versions rather than keeping the cargo.lock updates in their own commit. |
|
@bbenne10 thanks for sticking it out with us :) |
I believe that this is the minimum required changeset to get CI builds passing with modern Rust toolchains.
Developers working on nsncd should use rustup (or some other method) to get a modern stable toochain (but I have not made documentation changes speaking to this).
No new artifacts are pushed.
No changes to the running of
ci/test.shhave been made.I have updated slog-term simply to test that the msrv is new enough to build the newer version.
Feel free to revert that change, if you so desire.