-
Bug
-
Resolution: Cannot Reproduce
-
Medium (View bug fix roadmap)
-
None
-
8.0.0, (108)
8.1.0, 8.0.1, 8.0.2, 8.0.3, 8.2.0, 8.1.1, 8.4.3, 8.1.2, 8.2.1, 8.3.0, 8.2.2, 8.2.3, 8.4.0, 8.3.1, 8.2.4, 8.2.5, 8.3.2, 8.3.3, 8.1.3, 8.3.4, 8.4.1, 8.4.2, 8.5.0, 8.5.1, 8.5.2, 8.6.0, 8.2.6, 8.3.5, 8.7.0, 8.6.1, 8.5.3, 8.5.4, 8.8.0, 8.7.1, 8.7.2, 8.5.5, 8.9.0, 8.8.1, 8.7.3, 8.8.2, 8.10.0, 8.9.1, 8.11.0, 8.12.0, 8.5.6, 8.5.7, 8.9.2, 8.10.1, 8.5.8, 8.11.1, 8.10.2, 8.12.1, 8.12.2, 8.13.0, 8.12.3, 8.5.9, 8.13.1, 8.14.0, 8.5.10, 8.13.2, 8.5.11, 8.13.3, 8.14.1, 8.15.0, 8.13.4, 8.5.12, 8.13.5, 8.15.1, 8.16.0, 8.5.14, 8.13.6, 8.16.1, 8.17.0, 8.5.15, 8.13.7, 8.16.2, 8.5.16, 8.13.8, 8.17.1, 8.18.0, 8.5.17, 8.13.9, 8.5.18, 8.13.10, 8.18.1, 8.18.2, 8.19.0, 8.5.19, 8.13.11, 8.19.1, 8.13.12, 8.20.0, 8.13.13, 8.20.1, 8.13.14, 8.20.2, 8.21.0, 8.13.15, 8.20.3, 8.13.16, 8.20.4, 8.22.0, 8.13.17, 8.20.5, 8.13.18, 8.20.6, 8.13.19, 8.13.20
-
8
-
12
-
Severity 3 - Minor
-
8
-
Issue Summary
When upgrading Jira 8 between minor versions (8.6 > 8.8 for example, or 8.10 > 8.11 as another upgrade example), after the upgrade is complete, the admin will see a warning page that explains that some configuration/settings files that contained customizations could not be copied over. This is expected for any startup/installation file where the admin might have made changes. However in this case, the $JIRAINSTALL/bin/setenv.sh file will always appear on this list, even when the admin has made no changes at all to that file.
Steps to Reproduce
- install Jira Software/Core 8.10.0 (other 8 versions likely affected)
- Complete the setup and make sure Jira works
- Make no changes to setenv.sh
- upgrade that existing installation directory to a newer version, such as 8.11.0
- start Jira after upgrade
Expected Results
Expecting that there are no actual changes to that setenv.sh file and the initial startup would not indicate there are when you first start Jira after the upgrade.
Actual Results
Admins will always see that the setenv.sh file as having had customized changes to it that have not been applied to the upgraded install
The listed configuration files contain custom changes. To keep your current configuration, re-apply these custom changes to the new version of the files during upgrade.
bin/setenv.sh
Workaround
- The warning page does not prevent upgrades to Jira in this case. This is just a warning message that appears to be a false positive in most cases. You can still dismiss this and complete the upgrade.
- You can use -Djira.startup.warnings.disable=true startup flag, (see Setting properties and options on startup) which disables Johnson warnings page entirely:
Disables the page (johnson) that displays errors after starting Jira if there are only dismissible warnings. The page will appear if there are any important errors.
- is related to
-
-
- Closed
-
-
-
- Closed
-
- is caused by
-
FLASH-1193 You do not have permission to view this issue
[JRASERVER-71338] Upgrading Jira 8 between minor versions will always indicate that setenv.sh has customizations that are not applied
I just upgraded to Jira 8.17.0 and got, for the first time, this error - the previous update, from 8.13.1 to 8.15.0 went fine.
What's annoying is that the warning does not go away. I press "Ignore all warnings and continue", the page reloads without the button, without any possibility to continue.
Please advise, we would like to know when this issue is going to be fixed.
TIL about the -Djira.startup.warnings.disable startup flag (via JRASERVER-67809, its linked issues, and this doc on CAC), which disables that Johnson warnings page entirely:
Disables the page (johnson) that displays errors after starting Jira if there are only dismissible warnings. The page will appear if there are any important errors.
This is a sufficient workaround for us, and I imagine for customers who automate their deployment with ansible/puppet/etc as well. It doesn't address the root issue though (that these "custom changes" upgrade warnings are flagging changes introduced by the product upgrade itself), so I wouldn't consider it a true "fix" for this issue.
It's also super annoying that the Post Upgrade Landing Page itself ist using a 50x HTTP status code... If you catch every 50x with a custom error page you can't confirm the page without bypassing the reverse proxy itself...
Please fix this and add a switch to globally disable it. I understand that this page should guide unexperienced user to keep their undocumented changed in these files... But for every one who have automated or have defined upgrade processes this is annoying!
In my current case it complains about jira-application.properties... Which every knows just contain the jira.home... Which is set otherwise I won't seeing the dialog without a home directory...
We're impacted by this issue, and with a multi node DC cluster, you need to ignore these warnings on each node. To get around this issue for now, we've disabled the Post Upgrade Landing Page (PULP) module itself, but that means there may be warnings we should be caring about that we're not getting notified of, so would prefer a proper fix to this issue.
Looking at the contents of our /customisations/ directories, we can see we have the following tracked:
./atlassian-jira/WEB-INF/classes
./atlassian-jira/WEB-INF/classes/jira-application.properties
./atlassian-jira/WEB-INF/classes/email-template-id-mappings.xml
./atlassian-jira/WEB-INF/classes/seraph-config.xml
./atlassian-jira/WEB-INF/classes/log4j.properties
But we also have customisations to the below files that don't seem to get tracked:
./bin/setenv.sh (what JRASERVER-71338 is about)
./conf/server.xml
./atlassian-jira/WEB-INF/classes/crowd.properties
We use Puppet to enforce configuration of all these files, so we have confidence that any customisations are re-applied during any upgrade,
CCM
Closed because can't reproduce bug.
Tested Jira upgrade between versions 8.10.0, 8.11.0, 8.17.0 on osx and on docker - works as expected.