-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration test cleanup workflow #138
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
name: 'Cleanup test resources' | ||
|
||
on: | ||
workflow_dispatch: {} | ||
schedule: | ||
- cron: '0 0 * * *' | ||
|
||
jobs: | ||
cleanup: | ||
name: Delete all indexes and collections in sdk-node-testing project | ||
runs-on: ubuntu-latest | ||
steps: | ||
- name: Checkout | ||
uses: actions/checkout@v3 | ||
- name: Setup | ||
uses: ./.github/actions/setup | ||
- name: Cleanup | ||
run: npm run test:integration:cleanup |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
var dotenv = require('dotenv'); | ||
dotenv.config(); | ||
|
||
for (const envVar of ['PINECONE_ENVIRONMENT', 'PINECONE_API_KEY']) { | ||
if (!process.env[envVar]) { | ||
console.warn(`WARNING Missing environment variable ${envVar} in .env file`); | ||
} else { | ||
console.log(`INFO Found environment variable ${envVar} in .env file`); | ||
} | ||
} | ||
|
||
var pinecone = require('../dist'); | ||
|
||
(async () => { | ||
const p = new pinecone.Pinecone(); | ||
|
||
const collections = await p.listCollections(); | ||
for (const collection of collections) { | ||
await p.deleteCollection(collection.name); | ||
} | ||
|
||
const indexes = await p.listIndexes(); | ||
for (const index of indexes) { | ||
await p.deleteIndex(index.name); | ||
} | ||
})(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: Would it be useful to log anything out here if there were resources to clean up? Was thinking it might be nice to have some sort of indication of that either when running in the CLI or triggered via workflows. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great idea, I'll add some log output. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: This may be a minor issue, but if you run this locally outside CI where we're using secrets, I'd imagine this will just wipe things for whatever environment values you have configured, would that be an issue? Not sure if there's a good way around that as we don't want to embed the integration testing stuff in the repo itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it would run for whatever environment you are currently pointing at in your
.env
. Not ideal I suppose if you have a lot of test index data you're worried about accidentally deleting, but how likely are you to accidentally runnpm run integration:test:cleanup
from local? By wrapping this into a github actions workflow, we shouldn't ever really be running this locally.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose I could remove the
dotenv
invocation since that is only used locally. But I actually do want the ability to run this locally sometimes when developing new tests that throw off a lot of unintended indexes.I think a more advanced version of this workflow would have us adopt a standardized naming scheme for indexes and collections (e.g. one that starts with a build number), and then trigger a cleanup job immediately after every CI run that deletes resources tied to that build number only. But that's more work / somewhat error prone. This quick and dirty approach gives most of the benefits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I ultimately think this is fine, it would be very unlikely somewhat would run the integration cleanup step by accident or without knowing what it does.