Budget: 700 UAH Deadline: 1 day
Готов помочь! Могу настроить автоматизированные тесты для CI/CD на GitHub Actions и обеспечить их интеграцию с WordPress проектом.
Good morning.
Configured YML so that Docker and clean WP are already successfully deploying.
(confirmation screenshot from GitHub Action)
At the stage of installing the custom theme, where the site is built and deployed directly, a white screen appears immediately after the build.
Goal:
New code "pull", "merge request", and to have GitHub Action check the new code "on the fly".
That is, emulate the site with the proposed changes.
Already configured:
1. YML, which is proposed in the "merge request", is automatically tested
2. WP through Composer and Docker are successfully launched
What needs to be "tweaked":
1. Actual passing of tests = according to logs, theme and plugins are NOT installed.
Budget: 700 UAH Deadline: 1 day
Готов помочь! Могу настроить автоматизированные тесты для CI/CD на GitHub Actions и обеспечить их интеграцию с WordPress проектом.
Budget: 1200 UAH Deadline: 2 days
Good day! I have experience with GitHub Actions. I will gladly set up a workflow so that this pipeline is triggered on pull or merge requests. Based on the description, WordPress is already running in a Docker container, but there is a problem at the stage of installing a custom theme. I am ready to understand the logic of installing themes/plugins and to debug the process so that automated tests pass successfully, and changes can be emulated in the CI environment. I would also like to clarify a few details. Write to me, I will be happy to cooperate!
Who can help set up such a setup: I plan to deploy a server that will work in parallel with 4–5 different AI models for programming tasks. The key requirement is multi-user access: several developers will be able to use the server simultaneously, each in an isolated session with their own agents. Models Claude / GPT / Kimi k3
As part of enhancing the cybersecurity level of our infrastructure, we need to abandon the practice of storing "eternal" and static API keys, passwords, and integration tokens in the configuration files (.env, appsettings.json, config.yaml) of our microservices. Business Goal: Create a single secure storage point for confidential data (secrets) with a mechanism for their automatic updating (rotation) in external systems on a schedule. Our other services will request current tokens "on the fly" via API, which will minimize damage in case of compromise of any system component.Security Model and Encryption (Crypto Core) No secret should be stored in plaintext in the database. Upon application startup, a Master Key is passed to the environment variables. If the key is missing or has an invalid length, the service should fail at the initialization stage with a clear error in the logs. Each secret is encrypted before being written to the database using this Master Key. Upon request, it is decrypted in memory and returned in the response body.Audit Logging (Audit Trail) Any action with secrets (creation, reading by the service, successful or unsuccessful rotation) must be recorded in a separate log file audit.log (or a separate table in the database). Strict Taboo: It is strictly prohibited to record the actual values of secrets in the audit log (neither in plaintext nor in encrypted form).
We have a dedicated server on Hetzner with a website on Docker (+ Laravel framework) Contact with the developers has been lost Need to: - restore and change server access (probably SSH) - recommend a storage location and set up a full server backup with easy recovery, probably not on Hetzner for security - fix the logo that is not displaying for some reason (it's unclear why the file has become inaccessible) Important - there is no website backup, and there is no room for error. We will only consider experienced specialists.