To publish a new version of DAS AtomDB, the first step is to access the AtomDB repository.
Before starting to publish the version, it is crucial to ensure that the pyproject.toml file is updated with the number of the desired new version, locating and changing the version parameter in the [tool.poetry] section.
After this change, it is necessary to commit to the master branch to record the change.
It is important to note what the last version created was at https://github.com/singnet/das-atom-db/tags before creating a new version.
After the workflow execution, refresh the page and check if a new workflow is running. By clicking on it, you can track all jobs. At the end of the process, all jobs should have a green check mark. If there is an error in any job, it is possible to click on it to view the logs and identify the cause of the problem.
If everything goes as expected, the new version tag should be available at https://github.com/singnet/das-atom-db/tags and https://pypi.org/project/hyperon-das-atomdb/#history.
To publish a new version of DAS Query Engine, follow a process similarto the one described above for Das AtomDB. Access the repository athttps://github.com/singnet/das-query-engine
Make sure to update the version number in the pyproject.toml file. Additionally, it is necessary to update the version of hyperon-das-atomdb in the dependencies, as specified in the [tool.poetry.dependencies] section.
After this change, it is necessary to commit to the master branch to record the change.
It is important to note what the last version created was at https://github.com/singnet/das-query-engine/tags before creating a new version.
Initiate the ‘Publish to PyPI’ Workflow Manually via the ‘Actions’ Tab in the Repository. Click ‘Run workflow’ and proceed with the provided instructions, ensuring the master branch is selected. Enter the desired version number in the format 1.0.0, then click ‘Run workflow’ to proceed.
Just like in the case of DAS AtomDB, refresh the page and check if a new workflow is running. By clicking on it, you can track all jobs. At the end of the process, all jobs should have a green check mark. If there is an error in any job, it is possible to click on it to view the logs and identify the cause of the problem.
If everything goes as expected, the new version tag should be available at https://github.com/singnet/das-query-engine/tags and https://pypi.org/project/hyperon-das/#history.
Update the version of the hyperon-das in the das-query-engine/requirements.txt file. This ensures that the correct version is used during the workflow build.
After this change, it is necessary to commit to the master branch to record the change.
It is important to note what the last version created was at https://github.com/singnet/das-serverless-functions/tags before creating a new version.
Manually trigger the ‘Vultr Build’ workflow via the ‘Actions’ tab in the repository. Ensure the master branch is selected, then input the desired version number following the format 1.0.0. Next, choose ‘das-query-engine’ from the dropdown menu, and finally, click ‘Run workflow’ to proceed.
After the workflow execution, refresh the page and check if a new workflow is running. By clicking on it, you can track all jobs. At the end of the process, all jobs should have a green check mark. If there is an error in any job, it is possible to click on it to view the logs and identify the cause of the problem.
It is important to note that this pipeline should generate an img on Docker Hub, following the format 1.0.0-queryengine. Make sure that the img is generated correctly and available at https://hub.docker.com/r/trueagi/das/tags. After the workflow execution, verify if all jobs were successfully completed. The new version tag should be available at https://github.com/singnet/das-serverless-functions/tags.
The publication process of the img generated in the production and development environments is carried out in the das-infra-stack-vultr repository.
Before starting the deployment, it is necessary to update the version of hyperon-das in the requirements.txt file, ensuring that the correct version is used during integration tests. Before committing the changes to a branch, make the necessary changes in the das-function.yml file, updating the image version to the one generated earlier.
Commit your changes to the ‘develop’ branch or merge them into the ‘develop’ branch for deployment to the development environment. Following the merge, the ‘Vultr Deployment’ pipeline will initiate automatically. Verify the successful completion of all jobs with the ‘develop’ suffix to ensure the development environment is accurately updated.
After verification, make a PR from develop to master. After the merge to master, check if all jobs were successfully completed, ensuring that the production environment is correctly updated. If errors occur during tests, they are likely related to the response format, which may have been changed due to previously published libraries. In case of problems, it is possible to rollback the version by reverting the commit to return to the previous version.
To publish a new version of DAS Metta Parser, access the repository athttps://github.com/singnet/das-metta-parser
It is important to note what the last version created was at https://github.com/singnet/das-metta-parser/tags before creating a new version.
Initiate the ‘DAS Metta Parser Build’ Workflow Manually via the ‘Actions’ Tab in the Repository. Click ‘Run workflow’ and proceed with the provided instructions, ensuring the master branch is selected. Enter the desired version number in the format 1.0.0, then click ‘Run workflow’ to proceed.
Refresh the page and check if a new workflow is running. By clicking on it, you can track all jobs. At the end of the process, all jobs should have a green check mark. If there is an error in any job, it is possible to click on it to view the logs and identify the cause of the problem.
It is important to note that this pipeline should generate an image on Docker Hub, following the format 1.0.0-toolbox. Make sure that the image is generated correctly and available at https://hub.docker.com/r/trueagi/das/tags. After the workflow execution, verify if all jobs were successfully completed. The new version tag should be available at https://github.com/singnet/das-metta-parser/tags.
To publish a new version of DAS Toolbox, access the repository at https://github.com/singnet/das-toolbox/.
Before continue with the release process, update the VERSION
constant in the src/common/config.py
file. This file holds the version displayed when running das-cli --version
. It is important to keep this version in sync with the version generated by the pipeline to avoid mismatches.
After this change, it is necessary to commit to the master branch to record the change.
It is important to note what the last version created was at https://github.com/singnet/das-toolbox/tags before creating a new version.
Manually execute the “DAS CLI Build” workflow through the “Actions” tab in the repository. Click ‘Run workflow’ and proceed with the provided instructions, ensuring the master branch is selected. Enter the desired version number in the format 1.0.0, then click ‘Run workflow’ to proceed.
After the workflow execution, refresh the page and check if a new workflow is running. By clicking on it, you can track all jobs. At the end of the process, all jobs should have a green check mark. If there is an error in any job, it is possible to click on it to view the logs and identify the cause of the problem.
After the workflow execution, verify if all jobs were successfully completed. The new version tag should be available at https://github.com/singnet/das-toolbox/tags. Additionally, the CLI file generated by the pipeline will be available for download in the workflow artifacts, allowing its use locally.