Closed thomashoneyman closed 1 year ago
@JordanMartinez and I tested a deployed version of this PR and it worked: https://github.com/purescript/registry/commit/f255411eb1c67549cd0907fa53ae1e6b1a312e74
Logs are a bit noisy:
Calling registry at https: //registry.purescript.org/api/v1/jobs/b618c773-4bad-424f-84a9-50da541b506c?since=2023-07-20T22%3A41%3A48.843Z&level=DEBUG
Calling registry at https: //registry.purescript.org/api/v1/jobs/b618c773-4bad-424f-84a9-50da541b506c?since=2023-07-20T22%3A41%3A48.843Z&level=DEBUG
2023-07-20T22: 42: 26.443Z Pushing to Pursuit...
2023-07-20T22: 42: 26.577Z Received 201 status, which indicates the upload was successful.
2023-07-20T22: 42: 26.579Z [NOTIFY
] Successfully uploaded package docs to Pursuit! 🎉 🚀
2023-07-20T22: 42: 26.580Z Mirroring package node-zlib to location {
"githubOwner": "JordanMartinez",
"githubRepo": "purescript-node-zlib"
}
2023-07-20T22: 42: 26.582Z Reading legacy registry from scratch/registry
Calling registry at https: //registry.purescript.org/api/v1/jobs/b618c773-4bad-424f-84a9-50da541b506c?since=2023-07-20T22%3A42%3A26.582Z&level=DEBUG
2023-07-20T22: 42: 27.349Z Fetching repo at path scratch/registry
2023-07-20T22: 42: 27.350Z Found repo at path scratch/registry, pulling latest.
2023-07-20T22: 42: 27.350Z Found the purescript/registry repo locally at scratch/registry, fetching latest changes...
2023-07-20T22: 42: 27.629Z Local checkout of purescript/registry has no untracked or dirty files, it is safe to pull the latest.
2023-07-20T22: 42: 27.630Z Local checkout of purescript/registry is up to date, not pulling.
2023-07-20T22: 42: 27.638Z Committing to the purescript/registry repo at scratch/registry with message Sync node-zlib with legacy registry.
Calling registry at https: //registry.purescript.org/api/v1/jobs/b618c773-4bad-424f-84a9-50da541b506c?since=2023-07-20T22%3A42%3A27.638Z&level=DEBUG
2023-07-20T22: 42: 29.099Z Wrote and committed legacy registry files.
2023-07-20T22: 42: 29.100Z [NOTIFY
] Mirrored registry operation to the legacy registry.
Job: {
"createdAt": "2023-07-20T22:39:48.494Z",
"finishedAt": "2023-07-20T22:42:29.101Z",
"jobId": "b618c773-4bad-424f-84a9-50da541b506c",
"jobType": "publish",
"logs": [
{
"jobId": "b618c773-4bad-424f-84a9-50da541b506c",
"level": "INFO",
"message": "Wrote and committed legacy registry files.",
"timestamp": "2023-07-20T22:42:29.099Z"
},
{
"jobId": "b618c773-4bad-424f-84a9-50da541b506c",
"level": "INFO",
"message": "[NOTIFY] Mirrored registry operation to the legacy registry.",
"timestamp": "2023-07-20T22:42:29.100Z"
}
],
"packageName": "node-zlib",
"ref": "v0.2.1",
"success": true
}
✅ Registry finished processing the package. Your package was published successfully!
Reverted that last commit because the new Spago (0.93.8) fails to run the tests. Went back to the prior version.
Logs are a bit noisy:
Yes, debug logs are supposed to be noisy, or they would be useless 😄
This is deployed.
Would it be complicated to set up a deploy-on-merge with colmena+garnix?
I don't think so — we'd do it with a GitHub workflow that runs on master
on push
when all checks are successful and uses one of our SSH keys (or maybe the pacchettibotti key) to run colmena apply
.
We historically have included a relative path to the
./types
directory, assuming that scripts will be executed from the root of the repository. However, now that we've packaged the server for deployment, we no longer run the server from a git checkout of this repository and need to configure where the Dhall type specifications are located on the file system.This PR makes the directory configurable and puts it into the publishing environment, as well as setting that environment variable where appropriate. For the Nix builds that means reading it from the store; for tests and the Nix shell, that means a local path to the repository itself.