-
Notifications
You must be signed in to change notification settings - Fork 32
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
Tracking exactly what is installed on ospc.org and when #581
Comments
@PeterDSteinberg said:
Yes, I agree completely. It seems to me we want a record of the releases being used by TaxBrain for the following repos: webapp-public, Tax-Calculator (taxcalc package), OG-USA (ogusa package), and B-Tax (btax package). This information should appear in two places that can be viewed by the public. First, the current release numbers should be a the bottom of the TaxBrain page that appears when you click on
And second, a history of this release information should be added to a new webapp-public I think your suggestion of storing this historical information in a google doc is a very bad idea. This is an open source project. This basic information should be public. @MattHJensen @PeterDSteinberg @brittainhard @jbcrail @hdoupe |
I agree with @martinholmer that these documents should be public. I don't think that
is too cryptic except for the "d79abf" part. I think "Version 0.9.0" is fine. However, while checking this out, I noticed that the link you select when you click
when I think it should be this |
@hdoupe said in #581 he thought only the commit number I agree. The commit number adds no extra information, it just adds potential confusion for TaxBrain users who are not knowledgeable about git and version control. Good catch on the need to have the link be something like:
|
I would also like to know what installed on ospc.org and when it was installed. However, I think it would be better to keep track of this in a container registry or something like that. This would be better addressed in a comprehensive issue on deployment strategy. |
Closed #581 |
Related to the #560 discussion on the release process we discussed, among other things, tagging the webapp-public master commits we are releasing. This will help better track what is installed. We also can do the following activities to better track the exactly what we install on ospc.org and its backend workers over time. TODO:
conda env export
on a backend or frontend worker after a deployment* [ ] It would be good to have this as a reusable script, but even if the script is not done in time for the next deploy, we can go ahead and do
conda env export
manually.The text was updated successfully, but these errors were encountered: