this post was submitted on 24 Jun 2023
3 points (100.0% liked)

DevOps

1685 readers
3 users here now

DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.

Rules:

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
 

cross-posted from: https://programming.dev/post/196935

To be clear, this isn't my project. Just cross-posting the author's post from [email protected] .

Sometimes unused class or function manages to slip into code base. Static code checkers like ruff, flake8 does not have rules for detecting such globally unused code.

I tried using vulture, but it has too many false positives to have it as part of CI/CD pipeline.

I have tried to implement my own, more reliable check for global deadcode detection.

Please let me know what you think about it.

top 1 comments
sorted by: hot top controversial new old
[–] RandomDevOpsDude 1 points 1 year ago* (last edited 1 year ago)

This is an interesting option and probably pretty useful for python projects.

Although I generally push back against use of python usage as a build tool (it is not a build tool), I know tons of people still use python scripts in their CI (as a build tool), which, I think only makes sense if you are a python shop. Why install python to build java, for example? (pro-tip - don't)

Disclaimer: these opinions are mainly targeted toward closed source enterprise software.

People love using all sorts of fancy stuff in their CI, and I am personally a CI purist. If it can be done in bash, do it in bash. See scripts-to-rule-them-all by GitHub, which I personally think is still too little, but at least sets a good foundation.

CI purist examples:

I am of the opinion that if one feels like they need credentials for their cloud provider in CI (besides cloud provider as artifact host), the project probably needs better unit testing rather than integration tests requiring all sorts of real creds to be injected. Does it take some extra time, sure, but arguing against push back for "better testing" is not an easy path to go, trust me. ("No!!! My couple integration tests with bunches of dependencies injected are easy and get a lot of code coverage!!" -- code coverage != good tests)

I am also of the opinion that one shouldn't even be using things like 3rd party GitHub actions that one has no idea what they actually do, just that it works, and then auto bring in updates that one doesn't actually watch what is being updated. Sure it still works, but did it turn into malware, the project auto pulled in updates, and no one was watching? How does one know, if one isn't watching the upstream changes.

CI/CD is primetime for supply chain attacks. It is not an if, but a when. Prepare for the inevitable.