Secure Your Repo: Purge AI Test Files & Git History

Hey everyone! Today, we're diving into a super important topic that all developers, especially you guys working on projects like ismail-kattakath/jsonresume-to-everything, need to pay close attention to: security in your codebase. We're talking about removing specific AI API test files from our project root and, more critically, purging them from our entire git history. Why is this so crucial? Because sensitive data exposure is a real and present danger, and we want to make sure our project is locked down tight. This isn't just about deleting a few files; it's about safeguarding our project's integrity and preventing potential security breaches that could expose private API keys, tokens, and test data. Let's walk through why this is a high-priority cleanup and how we can achieve a truly secure repository.

The High-Priority Security Risk of Exposed AI Test Files

Security is paramount, and the presence of AI API test files directly in the project's root directory and, more alarmingly, embedded within its git history, presents a significant security vulnerability. Guys, we're talking about a HIGH priority risk here. These specific test-*.mjs files, designed for testing various AI API functionalities, often inadvertently contain or have contained extremely sensitive information. Think about it: API keys, authentication tokens, snippets of sensitive test data, references to internal API endpoints, and potentially even personal information used during development or testing. If these credentials or data points are hardcoded into these files and then committed, even if they're later removed from the current working directory, they remain accessible in the project's git history. Anyone with access to the repository's full history can simply dig back through past commits and find these hidden treasures, which is obviously a massive no-go.

What could happen if this data gets out? Well, unauthorized access to our AI services, potential financial costs from API overuse by malicious actors, data breaches that compromise user privacy, and significant reputational damage to the project and its contributors. For a project like jsonresume-to-everything, which might interact with various data sources, maintaining a pristine and secure environment is non-negotiable. Imagine an attacker getting their hands on an API key that grants access to a powerful AI model – they could misuse it, incur huge costs, or even exploit it for other nefarious purposes. This kind of exposure isn't just a minor oversight; it's a direct doorway for potential exploitation. That's why we need to be incredibly diligent and use robust tools to thoroughly purge this data, ensuring that every trace of sensitive information is eradicated from our repository's past. This comprehensive cleanup isn't just about reactive damage control; it's a proactive step towards building a more resilient and trustworthy codebase for everyone involved. We simply cannot afford to leave these vulnerabilities lingering in our past commits.

Affected Files: What We're Targeting for Removal

To proactively address this security concern, we need to meticulously identify and remove a specific set of AI API test files. These files are currently residing in the project's root directory, and their presence is what poses the risk. Guys, here's the crucial list of files that absolutely need to go:

test-achievements.mjs
test-high-token-limits.mjs
test-ui-scenario.mjs
test-gemini-raw.mjs
test-ai-sorting.mjs
test-real-data.mjs
test-providers-real.mjs
test-openrouter-api.mjs
test-max-output-tokens.mjs
test-gemini-api.mjs
test-openrouter-gemini.mjs
test-gemini-client-manual.mjs

These test-*.mjs files are specifically linked to our AI API testing efforts. While testing is essential, placing these files directly in the root and potentially embedding sensitive information within them (or their history) is a major oversight we're correcting now. It's imperative that all instances of these files, both from the current working directory and their entire commit history, are completely removed. This ensures no future or past version of our repository can expose any previously committed secrets. On the flip side, it's equally important to know what not to touch. There are legitimate configuration files that use a similar .mjs extension, and these should absolutely remain untouched. These include eslint.config.mjs, commitlint.config.mjs, postcss.config.mjs, and scripts/generate-password-hash.mjs. We're being surgical here, folks, targeting only the problematic test scripts to prevent any unintended disruptions to our project's configuration or build process. Understanding this distinction is key to a successful and clean removal process without breaking anything essential. We're focusing on precise execution to enhance our project's overall security posture without collateral damage.

Understanding Git History Exposure: Where the Secrets Hide

Git history is a powerful tool, but it can also be a security Achilles' heel if not managed carefully. The problem with our test-*.mjs files isn't just their current presence; it's the fact that they've been committed, even if temporarily, into our repository's past. Our git history analysis shows these files landed in several key commits, specifically: 14f9acc (feat: Add native Google Gemini API support), 913af1a (fix: increase maxOutputTokens for Gemini), f346044 (docs: add comprehensive Gemini thinking mode research), fe50988 (fix: route AI generation through provider-aware functions), c2d8925 (feat: Add Gemini API support via OpenRouter), and 0fc359d (fix: resolve test failures). Even if you delete a file and commit that deletion, git remembers everything. That sensitive API key or token, if it was ever part of one of these committed test files, is still living in the shadows of those past commits, waiting to be discovered by anyone who clones the repository and knows how to dig. This means that a simple git log or git checkout to a past commit can bring those old, exposed secrets right back into view. Therefore, a complete git history purge isn't just recommended; it's essential to truly secure the project and ensure that any potential sensitive data is gone for good, eliminating this lingering security risk entirely. We need to actively rewrite our past to protect our future, ensuring that our jsonresume-to-everything project remains robust and secure.

Phase 1: Immediate Cleanup – The Working Directory

Alright, guys, let's kick off this security cleanup with the first, most straightforward step: getting those problematic test-*.mjs files out of our current working directory. While this alone doesn't fix the git history problem, it's an essential immediate action to prevent any further accidental exposure or commits of these files. First and foremost, you need to remove all of these test-*.mjs files from your project's root. You can do this manually by simply deleting them, or you can use a command line for efficiency. Once those files are gone, the next critical step in this immediate phase is to update our .gitignore file. This isn't just good practice; it's a preventative measure that tells Git to completely ignore these file patterns moving forward, ensuring they never accidentally get committed again, even if they somehow reappear in the working directory. Adding test-*.mjs to .gitignore is a small but mighty step in reinforcing our security posture. After both removal and the .gitignore update, you must commit these changes to your current branch. This action documents that the files have been removed from the current state of the repository and that .gitignore has been updated to prevent their return. Remember, this step only addresses the present and future commits on your current branch; the past history still needs our attention in Phase 2. However, getting this initial cleanup done correctly sets the stage for the deeper, more impactful git history purge that will truly resolve our sensitive data exposure concerns. This focused first phase ensures we immediately stop the bleeding and prepare for the surgical strike on our commit history.

Phase 2: Purging Git History – The Big Clean-Up

Now, guys, this is where the real heavy lifting happens for our security cleanup: purging these files from our entire git history. This isn't a task to take lightly; it's a destructive operation that rewrites the past of our repository. The goal is to eradicate every trace of those test-*.mjs files, and any sensitive data they might contain, from every single commit, on every single branch. This is vital to ensure that even if someone digs deep into our project's past, they won't find any exposed API keys or tokens. We've got a few powerful tools at our disposal for this, each with its own strengths. I'll walk you through the most recommended options to perform this critical git history rewrite, emphasizing the necessary precautions and coordination required for such a significant change. Remember, due to the nature of this operation, force pushing will be required, so team coordination is absolutely non-negotiable. This phase truly cements our security improvements by making sure no old skeletons are hiding in our jsonresume-to-everything codebase.

Option A: Using BFG Repo-Cleaner (Our Top Pick!)

For most of us, especially when dealing with large repositories or complex histories, the BFG Repo-Cleaner is the go-to tool for purging sensitive data and unwanted files. It's significantly faster and, arguably, easier to use than git filter-branch for many common cleanup tasks. Why is BFG our top pick? Because it's designed specifically for this kind of scenario – a quick, powerful way to rewrite history and remove large files or sensitive information without too much fuss. Think of it as a specialized, high-performance vacuum cleaner for your git repo. Before you even think about running any commands, guys, you need to create a fresh clone of your repository – a mirror clone is best here – and treat it as a sacred backup. Do not run BFG directly on your original working copy. A mistake here can be catastrophic, so backup first, always! Once you've got your fresh clone, you can install BFG (e.g., brew install bfg on macOS or download from their site). Then, you'll use a simple command like bfg --delete-files test-*.mjs jsonresume-to-everything.git to tell BFG to go through every single commit in that mirrored repository and remove any file matching test-*.mjs. After BFG does its magic, you'll step into the cleaned repository (cd jsonresume-to-everything.git) and run git reflog expire --expire=now --all and git gc --prune=now --aggressive to clean up old references and actually shrink the repository size. Finally, and this is where the DANGEROUS part comes in, you'll git push --force. This command overwrites the remote history, which means every single team member will need to re-clone the repository. This is why team coordination is absolutely crucial before you execute this final force push. A quick chat with the team can save a lot of headaches and ensure everyone is on the same page for this critical security update.

Option B: Using git-filter-repo (For Precision Lovers)

If you prefer a more modern, python-based, and highly precise tool for git history manipulation, then git-filter-repo is an excellent choice. It's seen as the spiritual successor to git filter-branch and offers a lot more flexibility and safety features. This tool is fantastic for when you need surgical precision in removing specific files or modifying content throughout your history. Like with BFG, your first step should always be to create a full backup of your repository (git clone https://github.com/ismail-kattakath/jsonresume-to-everything.git backup-repo). Once you have your backup, you'll need to install git-filter-repo (e.g., brew install git-filter-repo or pip3 install git-filter-repo). The command to remove our specific test-*.mjs files is a bit more verbose, as you're explicitly listing each file with --path <filename> --invert-paths, which means