search

ucsdlib / damsrepo

DAMS Repository
Other
4 stars 2 forks source link

Release 4.43 #84

Closed gamontoya closed 5 years ago

gamontoya commented 5 years ago

Descriptive Summary

lsitu commented 5 years ago

@rstanonik I've created the new release 4.43 for damsrepo and it was deployed to staging by the Jenkins plan. However, I am seeing the same error as what I'd seen in QA last week:

java.lang.NoSuchFieldError: CONTENT_TYPE_OVERRIDE
    org.apache.tika.detect.OverrideDetector.detect(OverrideDetector.java:34)
    org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)

Could you delete the /usr/local/tomcat/webapps/dams folder from staging tomcat and redeploy it again? Thanks.

lsitu commented 5 years ago

@rstanonik Have you got a chance to take a look at the deployment issue on staging? As what we observed in QA, I think the Jenkins plan didn't make a clean deployment and the stale jars are still there in /usr/local/tomcat/webapps/dams/WEB-INF/lib. We may need to delete the dams folder in tomcat /usr/local/tomcat/webapps/dams. Thanks.

rstanonik commented 5 years ago

@lsitu I thought the problem in QA was that the branch had the stale jars. The content of WEB-INF/lib contained only the jar which came in the war. I'll check staging to see if the same thing happened.

rstanonik commented 5 years ago

@lsitu I just checked staging. WEB-INF/lib only contains jars which were in dams.war. It seems to have built using refs/tags/4.43. Which branch or tag should jenkins have used for staging?

rstanonik commented 5 years ago

@lsitu I think the problem was that jenkins had the stale jars. I change the jenkins plan to "Delete the workspace before the build starts" and I deployed again to staging. There are now fewer jars in WEB-INF/lib. Let me know if that fixed it.

lsitu commented 5 years ago

I see it works now. Thanks @rstanonik.

rstanonik commented 5 years ago

I chnaged all of the jenkins plans to now "Delete the workspace before build starts". Buillds will be a little slower, but this problem shouldn't occur for anymore for any build.

lsitu commented 5 years ago

@gamontoya I think damsrepo release 4.43 is ready for review on staging now. This will fix the PDF problem we seem eariler. @mdpeters Would you test it to see whether it works for your PDF files or not? Thank you.

mdpeters commented 5 years ago

@lsitu it looks like the PDF problem is fixed, at least the process we thought was being hung up by Tika isn't hanging anymore.

lsitu commented 5 years ago

Thanks @mdpeters for testing it out. @gamontoya It seems like we are ready to move the new release to prod. What do you think?

gamontoya commented 5 years ago

@lsitu I think it's fine to push this to prod.

lsitu commented 5 years ago

@gamontoya Thanks. We'll move it to prod once @mcritchlow confirms the test result of ticket https://github.com/ucsdlib/damsrepo/issues/85 on staging.

mcritchlow commented 5 years ago

@lsitu - From the testing @mdpeters has done so far I think the fix from #85 is having a very positive effect. It's possible something else might arise in the VRR context, but I don't think you need to have that work block your deployment anymore.

lsitu commented 5 years ago

@mcritchlow Okay, let's move it forward to prod then. Thanks.

lsitu commented 5 years ago

@rstanonik All code changes for damsrepo release 4.43 are already in master branch and I think it's ready for prod now. Thanks.

lsitu commented 5 years ago

@rstanonik Have you got a chance to deploy damsrepo release 4.43 to prod? Thanks.

rstanonik commented 5 years ago

Sorry, didn't notice it earlier. Deployed to prod now

lsitu commented 5 years ago

Thanks @rstanonik .