INFRA-526 and WEB-2064: Update to 5.3.2 and enable TagManager #25
Conversation
Why these changes are being introduced: There is a potential conflict between GITHUB_TOKEN permissions declared in a caller workflow (like this) and the shared workflow that is being called. After testing various combinations, the end result is as simple as setting the correct GITHUB_TOKEN permissions in the shared workflow and not declaring any permissions in the calling workflow. If there is some need to declare GITHUB_TOKEN permissions in the calling workflow, they MUST match the permissions in the shared workflow. Since checkov will throw a warning if no permissions are declared at all there is a checkov:skip comment in the caller workflow. Sadly, for an unknown reason, checkov doesn't register this skip comment and still shows a warning. How this addresses that need: * Remove all permissions declared in the caller workflows * Add a checkov:skip comment in the workflows, even though it doesn't properly work (this at least lets any future developer know that there is a good reason for not having a permissions statement in the yaml) Side effects of this change: None. Related Jira Tickets: * https://mitlibraries.atlassian.net/browse/IR-238
Why these changes are being introduced: We are using this docker-matomo repository to verify that the updates to the shared workflows for our automated deployment are working properly. Once this is all the way through to Prod, we'll merge the PR on the .github repo and then go through this again to clean up the workflows. How this addresses that need: * Update the workflows to point to a branch in the .github repository to use updated versions of our shared deployment workflows
Why these changes are being introduced: Along with the 5.3.3 upgrade, we are enabling the TagManager plugin. We just discovered that the TagManager plugin had been enabled via the Matomo UI in Prod, but since this was never captured in the container definition here, it did not persist. NOTE: The steps documented in the HOWTO have already been followed in Dev1, Stage-Workloads, and Prod-Workloads. How this addresses that need: * Create a HOWTO to document the difficulty in enabling the TagManager plugin in our environment * Update the config.ini.php file to reflect the activation of the TagManager plugin * Update the Dockerfile to update to the latest version of Matomo Side effects of this change: None. Relevant ticket(s): * https://mitlibraries.atlassian.net/browse/WEB-2064 * https://mitlibraries.atlassian.net/browse/INFRA-526
tim-rix
left a comment
tim-rix
left a comment
There was a problem hiding this comment.
Everything looks OK to me
dhrutibc
left a comment
dhrutibc
left a comment
There was a problem hiding this comment.
I see Tag Manager and I see Dev running 5.3.2, but I found it to be running very slow (tried a couple of times), and I found Prod Matomo to be running normally. I also saw this attached error message (I'm concerned about the second one that suggests the plugins are not compatible with 5.3.2)
@dhrutibc -- yeah, Dev is a little bit of a mess at the moment. We can only install the license key into two (2) Matomo instances, so Dev1 has the premium plugins installed, but not the license key. That's what generates those two warnings/errors in the UI. And, we undersize the Dev1 container since it never really does anything (hence, the slowness). When this deploys in Stage, you will have a much better experience for your testing. |
What does this PR do?
main)Helpful background context
The TagManager plugin had been enabled via the Matomo UI in the production instances, so this backfills the container definition with this update. At the same time, the 5.3.2 update is installed. The 5.3.2 update did not require any database changes.
Note 1: There were some issues when enabling the TagManager plugin in Dev1, so there is a new HOWTO document that outlines the fix to get it to work properly. This was necessary in both Dev1 and Stage-Workloads, but Prod-Workloads appeared to be ok.
Note 2: The last run through a Matomo update highlighted a problem with our shared deployment workflows. There is an approved PR that has not yet been merged in the .github repository that the workflows in this repo are using. Once this moves all the way through a tagged release, that PR will merge to
mainand then we'll quickly run through an update to this repo to re-point the caller workflows to themainbranch in the shared repo.How can a reviewer manually see the effects of these changes?
The container has been deployed to Dev1, so a review can check the Matomo UI and verify that TagManager is activated and that Matomo shows that it is running version 5.3.2.
Includes new or updated dependencies?
YES: TagManager is now active
What are the relevant tickets?
Developer
Code Reviewer
(not just this pull request message)