Removed redundant Docker CI/CD workflow for the 'latest' tag and integrated its functionality into the existing tagging workflow. This change not only reduces the redundancy of having separate workflows for 'latest' and version-specific tags but also simplifies the CI/CD process by having a single, unified workflow for Docker image publications. Moving forward, every push will now ensure that the 'latest' tag is updated alongside the version-specific tags, maintaining a smoother and more predictable deployment and versioning flow.
- Updated the Docker CI/CD workflow to trigger on pushes to the main branch, aligning with standard Git flow practices for production deployment.
- Advanced project version to 0.3.9, marking a new release with consolidated features and bug fixes.
This adjustment ensures that the Docker images are built and deployed in a more streamlined manner, reflecting our shift towards a unified branching strategy for releases. The version bump signifies the stabilization of new functionalities and enhancements for broader usage.
Removed redundant internal Docker CI/CD workflow and unified naming for external Docker workflows to improve clarity and maintainability. Introduced a new workflow for tagging pushes, aligning deployments closer with best practices for version management and distribution. This change simplifies the CI/CD pipeline, reducing duplication and potential confusion, while ensuring that Docker images are built and pushed efficiently for both internal developments and tagged releases.
- Docker CI/CD internals were removed, focusing efforts on standardized workflows.
- Docker CI/CD workflow names were harmonized to reinforce their universal role across projects.
- A new tagging workflow supports better version control and facilitates automatic releases to Docker Hub, promoting consistency and reliability in image distribution.
This adjustment lays the groundwork for more streamlined and robust CI/CD operations, providing a solid framework for future enhancements and scalability.
Introduced a new CI/CD workflow specifically for building and pushing Docker images to the Forgejo Docker Registry, triggered by pushes to the 'docker' branch. This addition aims to streamline Docker image management and deployment within Forgejo's infrastructure, ensuring a more isolated and secure handling of images. Concurrently, the existing workflow for Docker Hub has been refined to clarify its purpose: it is now explicitly focused on pushing to Docker Hub, removing the overlap with Forgejo Docker Registry operations. This delineation enhances the clarity of our CI/CD processes and ensures a cleaner separation of concerns between public and internal image repositories.
Removed a duplicate and unnecessary line specifying the `latest` tag for the docker image in the workflow. This change simplifies the tag specification process, avoiding redundancy, and ensuring clear declaration of both the `latest` and SHA-specific tags for our docker images in CI/CD pipelines.
Migrated from direct GitHub context references to environment variables for GitHub SHA, actor, and token within the Docker build and push actions. This enhances portability and consistency across different execution environments, ensuring better compatibility and security when interfacing with GitHub and Forgejo Docker registries.
Enhanced Docker build workflows in `.forgejo/workflows/docker-latest.yml` to include dynamic tagging based on the GITHUB_SHA, alongside the existing 'latest' tag for both the kumitterer/matrix-gptbot and git.private.coffee/privatecoffee/matrix-gptbot images. This change allows for more precise versioning and traceability of images, facilitating rollback and specific version deployment. Also standardized authentication token variables for Docker login to the Forgejo Docker Registry, improving readability and consistency in CI/CD configurations.
Enhanced the CI pipeline for Docker images by supporting an additional push to the Forgejo Docker Registry alongside the existing push to Docker Hub. This change allows for better integration with private infrastructures and provides an alternative for users and systems that prefer or require images to be stored in a more controlled or private registry. It involves logging into both Docker Hub and Forgejo with respective credentials and pushing the built images to both, ensuring broader availability and redundancy of our Docker images.
Moved the installation of build-essential and libpython3-dev from the Docker workflow to the Dockerfile itself. This change optimizes the Docker setup process, ensuring that all necessary dependencies are encapsulated within the Docker build context. It simplifies the CI workflow by removing redundant steps and centralizes dependency management, making the build process more straightforward and maintainable.
This adjustment aids in achieving a cleaner division between CI setup and application-specific build requirements, potentially improving build times and reducing complexity for future updates or dependency changes.
Updated the docker-latest workflow to install additional critical build dependencies including build-essential and libpython3-dev, alongside docker.io. This enhancement is geared towards supporting a wider range of development scenarios and facilitating more complex build requirements directly within the CI pipeline.
Updated the Docker CI/CD pipeline in the `.forgejo/workflows/docker-latest.yml` to support better integration and efficiency. Key enhancements include setting a container environment with Node 20 on Debian Bookworm for consistency across builds, and installing Docker directly within the runner to streamline the process. This refinement simplifies the setup steps, reduces potential for errors, and possibly decreases pipeline execution time. These changes ensure that our Docker images are built and pushed in a more reliable and faster environment.
Removed the specific runner designation from the Docker workflow to allow for dynamic runner selection. This change aims to increase flexibility and compatibility across different CI environments. It reduces the dependency on a single OS version, potentially leading to better resource availability and efficiency in workflow execution.
Introduced a new Docker CI/CD workflow to automatically build and push images to Docker Hub on pushes to the 'docker' branch. This automation ensures that the latest version of the bot is readily available for deployment, facilitating easier distribution and deployment for users.
The README.md has been updated to improve clarity around installation methods, emphasizing PyPI as the recommended installation method while expanding on Docker usage. It now includes detailed instructions for Docker Hub images, local image building, and Docker Compose deployment, catering to a broader range of users and deployment scenarios. This update aims to make the bot more accessible and manageable by providing clear, step-by-step guidance for different deployment strategies.
Related to these changes, the documentation has been restructured to better organize information related to configuration and running the bot, ensuring users have a smoother experience setting up and deploying it in their environment.
These changes reflect our commitment to enhancing user experience and streamlining deployment processes, making it easier for users to adopt and maintain the matrix-gptbot in various environments.
Simplified the publishing to PyPI steps in the release workflow by consolidating the Python environment setup, tool installation, package building, and publishing into a single job. This change makes the workflow more efficient and reduces the number of steps required to publish a package. It ensures that the environment setup, dependencies installation, package building, and publishing are done in one go, which can help in minimizing potential issues arising from multiple, separate steps.
This approach leverages the existing Python and PyPI tools more effectively and could potentially shorten the release cycle time. It also makes the workflow file cleaner and easier to maintain.
Switched the virtual environment activation command to be compliant with POSIX shell syntax. The previous `source` command is replaced with `.`, making the script more broadly compatible with different shell environments without requiring bash specifically. This change ensures greater portability and compatibility of the release workflow across diverse CI/CD execution environments.
Updated the GitHub Actions workflow in `.forgejo/workflows/release.yml` to explicitly use `python3` instead of `python` for both version checking and virtual environment setup. This change ensures compatibility and clarity across environments where `python` might still point to Python 2.x, preventing potential conflicts and erasing ambiguity. The adjustment aligns with modern best practices, acknowledging the widespread transition to Python 3 and its tooling.
Updated the CI/CD pipeline in `.forgejo/workflows/release.yml` to utilize the `node:20-bookworm` image instead of `python:3.10`. This necessitated adding steps for installing Python dependencies, given the switch to a Node.js-based image. This change accommodates projects that require both Node.js and Python environments for their setup and publishing processes, ensuring better compatibility and flexibility in handling mixed-technology stacks.
This update enhances our pipeline's capability to manage dependencies more efficiently across different technologies, catering to the evolving needs of our projects.
Introduced a new CI/CD GitHub Actions workflow for automated testing and publishing to PyPI, targeting Python 3.10 containers. This setup ensures code is tested before release and automates the distribution process to PyPI whenever a new tag is pushed. Additionally, updated README.md to include a support badge from private.coffee, encouraging community support and visibility.
This enhancement simplifies the release process, improves code quality assurance, and fosters community engagement by providing a direct way to support the project.
