Open jordanpadams opened 3 months ago
Quick question:
In this comment @eddiesarevalo suggests using npm publish --tag unstable
, but @jordanpadams writes (in the issue description ↑) npm publish --tag beta
.
I have no feelings either way. What would you prefer? @anilnatha, do you have a preference?
I believe this pull request will close the following issues
📆 03/2024 status: In work. On schedule
📆 04/2024 status: Updated end date to better reflect the work needed to complete continuous deployment for these applications. No impact on delivery.
📆 05/2024 status: In work. On track for 6/20 delivery.
This epic talks about using GitHub Actions for CI and CD.
I've indentified the following repositories as using Node.js (based on presence of the package.json
file). These repositories need the Roundup's newest support for Node packaging and artifact hosting plus branch testing—the "CI" part (2 open PRs):
archive-viewer
atlas
doi-ui
s3-browser-awssdk
s3-browser-cloudfront
template-repo-nodejs
wds
wds-react
wds-react-legacy
These repositories are using Terraform (based on the presence of .tf
files)—the "CD" part:
data-upload-manager
nucleus
pds-thin-egress-app
registry-api
registry-ref-data
registry-sweepers
updart
Note: there is no overlap.
The Node.js projects don't have Terraform files, and the Terraform projects aren't Node.js.
Question: do you want me to provide the GitHub Actions for "CD" for the Node.js projects even though they don't have any Terraform files, or provide the GitHub Actions for "CD" for the Terraform projects even though they're not Node.js? Or both?
@nutjob4life to query @anilnatha which of the above "CI" repositories is ripest for CD and to provide the Terraform files + the GitHub Action to run them for CD.
@anilnatha consider this your official query: of the repositories under "CI Part" in this comment, which one would you like me to ① create some Terraform files for and ② add GitHub Actions to use those Terraform files to make an automatic dev-tier deployment?
@nutjob4life None of the wds-*
repos require terraform, and atlas
is the repo for the PDS IMG Atlas Product Search tool that is hosted by PDS IMG so don't need to create terraform for it either. I can't speak for the other repos.
I would imagine that we need terraform for the s3-browser-*
repos. 🤷🏽
@eddiesarevalo ?
@anilnatha to rephrase the question, if we wanted to be able to view and/or test what you and Eddie are currently working on, what repository would benefit from continuous deployment and/or containerization? Note: This may change in the future once we get wordpress in the loop.
I think it's in our best interest to focus on flushing out the cloud architecture I initially proposed and building out the portal-wp
repo. We don't have to have the wordpress architecture solidified right now, but if we could at least resolve the issues with building out the portals frontend containers and getting those served through CI/CD, it would be a big step forward.
Okay so is the idea to make portal-wp be like a template repo that you duplicate so you can stand-up Wordpress sites easily or more as just a "model", as in, "here's how you'd do it as a fully-fleshed example"?
@nutjob4life this will be the one and only. we don't care about other wordpress sites and how to deploy this. this can be as application specific as needed.
💡 Description
Follow on to https://github.com/NASA-PDS/devops/issues/67
Laying the groundwork for a future roundup requirement, let's create a new GitHub Action in a repo using NPM and test our what we want/need in order to support it.
For now, let's just build out the branch testing, unstable, and stable deliveries:
branch-cicd.yaml - install dependencies, build, verify success:
unstable-cicd.yaml - install dependencies, build, deploy to dev npm (NOTE: requires package.json to already be updated as indicated in README):
npm publish --tag beta
stable-cicd.yaml - install dependencies, build, deploy to dev npm (NOTE: requires package.json to already be updated as indicated in README):
npm publish
Sub-tasks