4 ms·
Reasons not to use something like this: 1. Want to run a build from a version from a few months ago, well things are fixed at the head of the main branch, but
by Laremere 5y ago
Reasons not to use something like this:
1. Want to run a build from a version from a few months ago, well things are fixed at the head of the main branch, but a todo in the old version are now bad and break the build. No binary searching for where a bug was introduced, or doing a patch of a previous release.
2. Github is down or you don't have internet access, now one of the key strengths of git (distributed, works offline) no longer works.
3. You have a large team, now nobody can get any work done for the length of time it takes a single person to fix the problem.
4. Your automatic cut for the weekly release runs at 3am, but a todo expired at midnight. Now the person in charge of the push to prod needs to do manual work, probably slowing down the cadence of testing the release.
5. Rust has bad compile times, this will only make it worse.
- zaarn 5y agoFor 1-2, the todo panic stacktrace should tell you exactly what went wrong. For 3-4 you can set TODO_OR_DIE_SKIP, as documented for the crate, to disable all the todo checks at compile time. 5 is getting better over time.
- YetAnotherNick 5y agoMaybe it could be opt out when compiling. Error message could be `todo has been expired, failing compilation. To ignore this, use -DIGNORE_TODO`
- rat87 5y agohttps://github.com/davidpdrsn/todo-or-die/blob/main/src/lib.rs#L20 https://github.com/davidpdrsn/todo-or-die/blob/main/src/lib.... //! # Skipping checks //! //! If the environment variable `TODO_OR_DIE_SKIP` is set all macros will do nothing and //! immediately succeed. This can for example be used to skip checks locally and only perform them //! on CI.
- wheybags 5y agoThis makes me think a nicer (and simpler) implementation could be just special comments that have a shell command in them. Then your ci script recursive greps for commands, and runs them. That way you get enforcement in ci, not for devs, and also a super simple system with no complex compiler magic. Bonus point: it will work in any language.
- IshKebab 5y agoYeah the fact that someone closing a GitHub issue can break your build for everyone kind of sucks. But I still like the idea. Maybe it should emit a warning when the issue is closed and then only error if it has been closed for a year. Should probably be opt-in, enabled in CI.
- deleted 5y ago[deleted]
- SamBam 5y agoA gentler reminder could be that the CI automatically creates a GitHub issue on Todo failure.
- nextaccountic 5y agoThis should be an external tool, like clippy. Because it's effectively a linter, it shouldn't block the build. Call it cargo todo-or-die or something.