# Blade Client

>  The current update is based on `cura 5.7.0`

Blade is a state of the art slicer based upon [Cura](https://github.com/Ultimaker/Cura). Blade contains customizations and specialised profiles to optimize it for BigRep's large format FDM printers. The original cura readme is still available [here](docs/index.md). However custom topics, that have not being upstreamed will be stored [here](docs/blade_index.md).

To run a test build use the below command:

```powershell
.\venv\Scripts\Activate.ps1; python cura_app.py; .\venv\Scripts\deactivate_Activate.ps1
```

## License

![License](https://img.shields.io/github/license/ultimaker/libarcus?style=flat)  
Arcus is released under terms of the AGPLv3 License. Terms of the license can be found in the LICENSE file. Or at
http://www.gnu.org/licenses/agpl.html

> But in general it boils down to:  
> **You need to share the source of any Cura modifications if you make an application with Cura.**

# Changelog

The client changelog is located in `resources/texts/change_log_client.md`. The format is as follows:

```
# version 
> materials version (major.minor) other materials versions
- updates
## internal
- private updates

```

Empty lines are ignored, all other formatting will cause an error (unit testing is present). The `process_changelog.py` script will read the client and materials changelogs during the build step and output the changes from the most recent `major`.`minor `versions to `change_log.txt` in the texts folder. Do not manually input data into `change_log.txt` it will be replaced during build time.
Each materials version should be added to the client changelog after the `>` symbol so they can be mapped to the correct client release.

# Developer tools

The software can be built in both release and debug. To download packages or to upload the build results you must also have the gitlab remote set up for conan with an authorized user (see [conan configuration](https://gitlab.bigrep.com/blade/conan-configuration-blade-5)). Most commands are accessed though a single python file called `client_scripts.py` with a simple command line interface.

To work with the client it is required that the conan install is run. This automates the procedure of fetching all the dependencies, setting up virtual environments etc.  `--udpate` replaces existing packages with newer ones if present. Client is only build with the release profile. `-g VirtualPythonEnv` creates the new python venv, this can be skipped if the venv is already present and it will not change. `-o devtools=True` is typically not used in a pipeline build and ensures that `requirements-dev.txt` is installed.

```powershell
$project = client/<version>@bigrep/<channel>
conan install  --update -pr blade_release.jinja --build=missing -g VirtualPythonEnv conanfile.py $project
```

Next the project is built. at present this step takes no action as the client is simply a collection of other projects. however it is left here for completeness. All options are determined in the previous step.

```powershell
conan build conanfile.py
```

Conan is then used to move the completed package to the local cache and then upload to gitlab. the `--all` indicates that the source code and package should be uploaded not that every version should be uploaded.

```powershell
conan export-pkg --force conanfile.py $project
conan upload --all --remote=gitlab $project
```

## Checking the stack

```python
from UM.Settings.ContainerRegistry import ContainerRegistry
# free floating collections of data in the cache based on files in resources
ContainerRegistry.getInstance().findContainers()
#filtered results
ContainerRegistry.getInstance().findContainers(type="variant")

# see the actual tree of current information
from cura.Machines.ContainerTree import ContainerTree
ContainerTree.getInstance()
```

## Release Procedure

Work through the steps if any steps are failed the release should be stopped. If making a patch release use an existing branch and cherry pick the changes across from main.

1. Create a sprint ticket and name it the Release Version. 
   * Determine the version number to use. This is by team agreement, but in general see [here](https://wiki.bigrep.com/display/BLAD/Blade+Versioning). Once a version number is decided, double-check the ticket name
2. Jira work:
   * Create new [release in jira](https://projects.bigrep.com/projects/SLIC?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=no-filter) if not already present
   * Check all tickets with the release version are complete. For non complete tickets determine if they are required. Move to next version if not required
   * Add the release verison to the corresponding Jira issues if not already present. Ideally issues are tagged while working on them. This can be done by searching tickets over a date range : `AFTER "2019/10/23" AND project = Slicer`
   * Close the current release (set the release date!), Ensure that any tickets not complete are moved to another release version
   * Create the next release version if not already present
3. Check release version and notes:
   -  Update the version number in the .gitlab-ci.yml file. It must be a full version number with a major, minor, and patch.
   -  Update the `resources/texts/change_log_client.md` and ensure the materials reference is up to date. Check against Jira from step 2
   -  Any notes under the internal header are automatically hidden in release
   -  Merge back into main, if required.
4. Check the following in the UI:
   * The visibility of settings.
   * Check all printers etc are visible
   * Check at least the main materials are present
   * Check the release notes are up to date
   * Slice at least 1 part
5. GCode Regression Check
   * Create GCode with last official version of Blade
   * Create GCode with this version 
   * Perform a diff. Esp. test on header/footer
6. Create a branch with the following format: release/version_number without the patch number. For example:
   -  `release/5.4`
   -  `release/6.0`
7. Begin the freeze procedure:
   -  Create tag build for [engine](https://gitlab.bigrep.com/blade/engine) and [blade-materials](https://gitlab.bigrep.com/blade/blade-materials)
   -  Freeze version, do not use latest packages as release, see [freeze procedure](#creating-a-frozen-version)
8. In Gitlab [create a tag](https://gitlab.bigrep.com/blade/blade-client/-/tags) the same as the release version. The release is created automatically by the pipeline. Once complete you will see it in the [release page](https://gitlab.bigrep.com/blade/blade-client/-/releases)
9. Download and install the executable and recheck step 4
10. In the installed location `%appdata%\Blade <version>` Ensure that all license files are present and that no extra files (tests, etc.) are present
11. Contact someone at #blade_web. Here is the guide which used for publishing the [latest release](https://wiki.bigrep.com/display/MAR/New+BLADE+version+step+by+step)
    1. Internal releases can be manually added to the server via ftp. Upload the alpha and fleet versions to their respective folders
    2. TEMPORARY FIX: until blade 5.X.X becomes the public version change latest.json so that the BigRep Blade field says `3.12.3`
    4. NOT YET: once blade 5.x.x becomes the public version also upload this.
    5. replace the latest.json
12. Back on the main branch: Increment the version in `.gitlab-ci.yml` and the `change_log_client.md`. If the changelog was updated apply these changes here as well.

### Maybe to do in the future

-  Blade analytics update. Add this to release procedure once updated. Add the new build number in blade-analytics-service / analytics / json_collector.py and then update blade analytics
-  Once working add benchmarking to the release procedure

### Creating a frozen version

The build process will not allow you to create a release without first creating a frozen version in the `conandata.yml` file. This process is automated using `scripts/freeze_release.py`. First create a "loose" set of requirements for your desired version in `conandata.yml` This can just be a copy of the any section `any`. Next run `scripts/freeze_release.py` with the specific version and it will change requirements to their specific concrete versions. For example `engine/(latest)@bigrep/stable` would change to `engine/2.1.4@bigrep/stable` . It is required to run the conan install on the main project first to fetch the latest relevant packages, otherwise your freeze may be out of date.

```
python scripts/freeze_release.py --version <version> --channel <channel>
```

# Technical specifications for release

Tagged version does not save packages, so when building a tagged version and a package it uses is deleted, packages must be rebuilt to rebuild the release.

TODO: need some way of checking regressions (ex: file size increase)

`latest.json` is made in the build_release step, which is triggered on tag.