GitLab hosted avatars don't load in the Jira Development Panel
Summary
Premium customer highlighted (internal links) that Avatars shown against commits in the Jira Development panel fail to load because the path to the avatar is not qualified with the GitLab server address.
It appears that the GitLab API (that Jira is consuming) serves up what GitLab knows/stores/uses verbatim. So if it's a GitLab stored image, just a path (eg: /uploads/-/system/user/avatar/1/avatar.png
) which Jira then returns to the client as if that path is available on the Jira server. The image therefore fails to load.
Similarly, if an account is set with a Gravatar image instead, the URL is fully qualified with the hostname when it's passed over to Jira, and the URL presented by Jira can be loaded by clients.
Workaround: use Gravatar for avatars.
Steps to reproduce
- Self Managed GitLab instance, GitLab Premium or GitLab Ultimate (Tested on 13.1.4-ee)
- Self Managed Jira software instance (I reproduced it using 8.10.1) and a test project
- Set up Jira integration
- Set up DVCS
- Set up a test project in each application
- Set your account using an avatar which you upload into GitLab
(Jira seems to cache the avatars to use for each account, so it's quicker set this before letting Jira see the account)
- Push commits to the GitLab repo referencing an issue in the Jira project
- View the commits via the development panel in Jira.
What is the current bug behavior?
Only a file/directory path is returned via the API to Jira when GitLab is serving up the avatar.
What is the expected correct behavior?
Like when the developer is using Gravatar, serve up a full URL via the API.
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
System information System: Proxy: no Current User: git Using RVM: no Ruby Version: 2.6.6p146 Gem Version: 2.7.10 Bundler Version:1.17.3 Rake Version: 12.3.3 Redis Version: 5.0.9 Git Version: 2.27.0 Sidekiq Version:5.2.7 Go Version: unknown GitLab information Version: 13.1.4-ee Revision: 66acdb3d3e9 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 11.7 URL: https://gitlab-gltest1.watertower HTTP Clone URL: https://gitlab-gltest1.watertower/some-group/some-project.git SSH Clone URL: git@gitlab-gltest1.watertower:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 13.3.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
Expand for output related to the GitLab application check
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 13.3.0 ? ... OK (13.3.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) Projects have namespace: ... 5/1 ... yes 5/2 ... yes 5/3 ... yes 5/4 ... yes 6/5 ... yes 6/6 ... yes 6/7 ... yes 6/8 ... yes 4/9 ... yes 6/10 ... yes 4/11 ... yes 6/14 ... yes 4/15 ... yes 4/16 ... yes 8/17 ... yes Redis version >= 4.0.0? ... yes Ruby version >= 2.5.3 ? ... yes (2.6.6) Git version >= 2.22.0 ? ... yes (2.27.0) Git user has default SSH configuration? ... yes Active users: ... 2 Is authorized keys file accessible? ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes Elasticsearch version 5.6 - 6.x? ... skipped (elasticsearch is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
(If you can, link to the line of code that might be responsible for the problem)