I manage a Morse Code website that is hosted through a deployment workflow connected to a Gitea repository, and the site contains a JavaScript-based translator that converts text into Morse code and decodes Morse messages in real time. The application also includes audio playback, copy-to-clipboard functionality, responsive interface components, and several static assets that are updated regularly as I improve the project. The repository itself appears to receive commits correctly, and the files shown in Gitea contain the latest changes that I expect to deploy. However, the production website occasionally continues serving an older version of the application even after the corresponding commit has been pushed successfully.
The problem becomes especially noticeable when I modify the JavaScript responsible for the actual Morse Code translation logic, because the deployed page sometimes behaves as though the previous version of the script is still being used. For example, I can add a new character mapping or modify the way spaces and punctuation are handled, verify that the change works locally, commit it, and push it to the Gitea repository. The commit appears normally in the repository history and the deployment process reports success, but visiting the live website can still show the previous behavior. In some cases a hard refresh eventually displays the new functionality, which makes me suspect that an older build artifact or cached asset may be involved.
I have already checked the repository branches and deployment configuration to make sure that the production process is using the intended branch rather than an outdated development branch. I have also compared the timestamps and contents of the JavaScript files in the repository with the files being served by the website, but the behavior is not always consistent between deployments. The problem does not occur with every commit, which makes it more difficult to identify a specific configuration mistake. I am particularly interested in knowing whether there are recommended Gitea workflows for ensuring that a deployment always consumes the exact commit that triggered the build.
Another complication is that the website consists of multiple frontend assets that need to remain compatible with one another, including HTML, JavaScript, CSS, and audio-related resources. If the HTML from one version is combined with JavaScript from another version, the translator can appear partially functional while some buttons or newer features stop working. This makes the issue more serious than simply displaying an outdated page because users can receive a mixture of application versions without any obvious indication that this has happened. I would like to find a deployment approach that guarantees all related assets originate from the same repository revision.
I have considered using hashed filenames or adding explicit version identifiers to the JavaScript and CSS assets so that every deployment generates unique URLs, but I am not sure whether this is the best solution or whether the underlying problem is actually somewhere in my Gitea-based deployment workflow. I also want to avoid disabling caching entirely because the Morse Code website benefits considerably from browser and CDN caching when users visit the site repeatedly. Ideally, I would like to retain those performance benefits while ensuring that a newly deployed application version cannot accidentally reference stale assets from an earlier release.
Has anyone experienced similar behavior when using Gitea as part of a deployment workflow for a JavaScript-heavy website? I would appreciate recommendations for diagnosing whether the stale version is being introduced during the Gitea checkout, build process, artifact generation, deployment step, or subsequent browser/CDN caching. In particular, I would like to know what deployment and asset-versioning practices the Gitea community recommends for ensuring that every production release serves a consistent set of files from exactly one repository commit. Sorry for long post!