- raises PRs for security fixes immediately, regardless of cooldown configs
- flags the PRs as security fixes
- does the above when actions are pinned by commit SHA
? If so, mind sharing some documentation and examples please? I don't mind being proven wrong, but I genuinely couldn't find anything that demonstrates this happens. Dependabot docs actually point to the contrary (see my blog posts).
Glad to hear you're enjoying Renovate - I'm biased, but I agree that the SHA pinning PR updates are a very nice feature
We recently found (in Renovate) some edge cases with how tags work in GitHub Actions which was fun (https://news.ycombinator.com/item?id=47892740) and there's a few things in there Dependabot doesn't seem to support too
Very much looking forward to getting this on Renovate - we require squash-merge via Merge Queue (with no per-PR override available in GitHub, despite asking) and so when I've got multiple changes, it's a lot of wrangling and rebasing
If this works as smoothly as it sounds, that'll significantly reduce the overhead!
>legally speaking.. if you're not sure of the risk- you don't document it.
Ah, so you kinda maybe sorta absolve yourself of culpability (but not really — "I didn't know this was copyrighted material" didn't grant you copyright), and simultaneously make fixing the potentially compromised codebase (someone else's job, hopefully) 100x harder because the history of which bits might've been copied was never kept.
Solid advice! As ethical as it is practical.
By the same measure, junkyards should avoid keeping receipts on the off chance that the catalytic converters some randos bring in after midnight are stolen property.
Better not document it.
One little trick the legal folks don't want you to know!
Yep, we had to do this recently with Renovate, where we had too many releases, and new publishing hit a size limit on the registry, so we needed support to help us unpublish a load of old releases
interesting post thanks for sharing! It does indeed complicate things if you want access control. For me personally I don't have a strong argument to provide sharing, a post can either be read by anyone or only by me, the middle ground doesn't really earn the level of complexity it adds for me personally.
I'm really not sure how I would solve it if I had to, git-crypt only makes sense because I only need access to the private posts locally and I would lose the added bonus of the encryption/decryption going on in the background and in a git-native way.
The thing I was trying to illustrate with the post was how amazingly some things just come together once you strip away all the extra functionality and what hidden bonuses can appear. Thinking about a possible solution that is still minimal though I would lose git-crypt and probably handle encryption/decryption manually, add a key for each of the people I wanted to give private access and have my email notifications automatically append their keys whenever i notify of new posts, but again the beauty/coherence gets lost.
reply