You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+12-4Lines changed: 12 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,8 @@ Within each subdirectory you should expect to have:
24
24
-`run.sh` -- A script that should handle any additional library installations and steps for executing the test suite. This script should not populate the Atlas database with any required test data.
25
25
-`config.env` - A file that defines the following environment variables:
26
26
-`REPO_NAME` -- The name of the AI/ML framework repository that will get cloned
27
-
-`CLONE_URL` -- The Github URL to clone into the specified `DIR`
27
+
-`REPO_ORG` -- The Github org of the repository
28
+
-`REPO_BRANCH` -- The optional branch to clone
28
29
-`DATABASE` -- The optional database where the Atlas CLI will load your index configs
29
30
-`database/` -- An optional directory used by `.evergreen/scaffold_atlas.py` to populate a MongoDB database with test data. Only provide this if your tests require pre-populated data.
30
31
-`database/{collection}.json` -- An optional JSON file containing one or more MongoDB documents that will be uploaded to `$DATABASE.{collection}` in the local Atlas instance. Only provide this if your tests require pre-populated data.
@@ -117,7 +118,7 @@ Test execution flow is defined in `.evergreen/config.yml`. The test pipeline's c
117
118
118
119
**[Functions](https://docs.devprod.prod.corp.mongodb.com/evergreen/Project-Configuration/Project-Configuration-Files#functions)** -- We've defined some common functions that will be used. See the `.evergreen/config.yml` for example cases. The standard procedure is to fetch the repository, provision Atlas as needed, and then execute the tests specified in the `run.sh` script you create. Ensure that the expansions are provided for these functions, otherwise the tests will run improperly and most likely fail.
119
120
120
-
-[`fetch repo`](https://github.com/mongodb-labs/ai-ml-pipeline-testing/blob/main/.evergreen/config.yml#L30) -- Clones the library's git repository; make sure to provide the expansion CLONE_URL
121
+
-[`fetch repo`](https://github.com/mongodb-labs/ai-ml-pipeline-testing/blob/main/.evergreen/config.yml#L30) -- Clones the library's git repository; make sure to provide the expansion REPO_ORG/REPO_NAME and REPO_BRANCH (optional)
121
122
-[`execute tests`](https://github.com/mongodb-labs/ai-ml-pipeline-testing/blob/main/.evergreen/config.yml#L51) -- Uses [subprocess.exec](https://docs.devprod.prod.corp.mongodb.com/evergreen/Project-Configuration/Project-Commands#subprocessexec) to run the provided `run.sh` file. `run.sh` must be within the specified `DIR` path.
122
123
-`fetch source` -- Retrieves the current (`ai-ml-pipeline-testing`) repo
123
124
-`setup atlas cli` -- Sets up the local Atlas deployment
@@ -137,8 +138,7 @@ At the start, we will hopefully add the integration tests themselves.
137
138
The bad news is that the maintainers of the AI/ML packages may take considerable
138
139
time to review and merge our changes. The good news is that we can begin testing
139
140
without pointing to the main branch of the upstream repo.
140
-
The parameter value of the `CLONE_URL` is very flexible.
141
-
We literally just call `git clone $CLONE_URL`.
141
+
We can use `REPO_ORG`, `REPO_NAME`, and an optional `REPO_BRANCH` to define which repo to clone.
142
142
As such, we can point to an arbitrary branch on an arbitrary repo.
143
143
While developing, we encourage developers to point to a feature branch
144
144
on their own fork, and add a TODO with the JIRA ticket to update the url
@@ -169,3 +169,11 @@ We realized that we could easily get this working without changing the upstream
169
169
simply by applying a git patch file.
170
170
This is a standard practice used by `conda package` maintainers,
171
171
as they often have to build for a more broad set of scenarios than the original authors intended.
172
+
173
+
### Running a patch build of a given PR
174
+
175
+
Rather than making a new branch and modifying a `config.env` file, you can run a patch build as follows:
0 commit comments