Currently we've got https://github.com/maidsafe/QA/blob/master/Bash%20Scripts/Travis/after_success.sh#L10-L15 which restricts docs/tag generation to destination branch "master". This ofc prevents any new version change patches going to branches from creating a corresponding tag/documentation for the patch version.

Probably needs a bit of thought to get this in place and also not end up triggering a duplicate docs/tag build when just creating a new branch / merging from master

I can browse the file by my own PC. I use SAFE Demo App and SAFE Launcher.
but how can I browse by another PC
Thanks.

In Jenkins there's a pipeline for build and release for safe-nd. This should be migrated to GH Actions and then removed from Jenkins.

safe-nd has a very simple process with just a build & test and deployment stage (though it should really be called publishing rather than deployment):

• Build on Linux
• Build on Windows
• Build on macOS
• Publish to crates.io on version change

The Jenkins mechanism is to use a Makefile, but this can probably be discarded now.

I'd suggest adding a new section to the style guide recommending using the thread helpers.

Something like the following:

Threads

Generally avoid detached threads. Give child threads meaningful names.

This can easily be achieved by preferring to create child threads using maidsafe_utilities::thread::named().

• it returns a Joiner which helps to avoid detached threads
• it requires that the child thread is given a name

The repo list has gotten even longer since I last saw it. There's already a separate table for "Android", we can also separate out Javascript and Rust and remove all the empty table cells (e.g. Azure for Rust projects).

In Jenkins there's a pipeline for build and release for safe_client_libs. This should be migrated to GH Actions and then removed from Jenkins.

safe_client_libs has a lot of different build configurations. Here is a description of the stages:

• Build & Test:
  • Build on Linux (dev and prod)
  • Build on Windows (dev and prod)
  • Build on macOS (dev and prod)
  • Build on iOS x86_64 (dev and prod)
  • Build on iOS aarch64 (dev and prod)
  • Build on Android x86_64 (dev and prod)
  • Build on Android armv7 (dev and prod)
  • Test on Linux
  • Integration tests on Linux
  • Binary compatibility tests
  • Test on macOS
  • Test on Windows
  • Run clippy on Linux
• Build universal iOS lib:
  • Retrieve x86_64 and aarch64 iOS artifacts
  • Run lipo to create the universal library
• Deployment (non version change):
  • Retrieve build artifacts
  • Package build artifacts for deploy
  • Upload artifacts to S3
• Deployment (version change):
  • Retrieve build artifacts
  • Package build artifacts for deploy
  • Create a tag
  • Create a GitHub release
• Publish:
  • Publish to crates.io

In the case of safe_client_libs, my advice would be to retain use of the Makefile and also the containers that are used for building the mobile stuff. That would mean all you would need to do would be to run the Makefile target that builds the mobile stuff and you wouldn't have to convert these into actions (though you could try it if you wanted to).

SCL had the requirement that we should be able to deploy and publish components individually. This will be a bit more clunky with a declarative model but it should be possible.

A nightly build could also be replicated using a cron trigger.

You should be able to copy the deployment stuff from safe-api once we have finished implementing that.

Currently seeing this issue when running create_linux_vault_package.sh

/usr/local/bin/fpm:9:in `require': no such file to load -- rubygems (LoadError)
    from /usr/local/bin/fpm:9

I am investigating it looks like an environment issue

In Jenkins there's a pipeline for build and release for safe-nd. This should be migrated to GH Actions and then removed from Jenkins.

safe_vault has a fairly simple build & test and deployment stage (though there really should have been a separate deployment and publish stage):

• Build & Test:
  • Build on Linux
  • Build on Windows
  • Build on macOS
  • Build with musl
  • Test on Linux
  • Test on macOS
  • Test on Windows
• Deployment (non version change):
  • Retrieve build artifacts
  • Package build artifacts for deploy
  • Upload artifacts to S3
• Deployment (version change):
  • Retrieve build artifacts
  • Package build artifacts for deploy
  • Create a tag
  • Create a GitHub release
  • Publish to crates.io

In the case of safe_vault, my advice would be to retain use of the Makefile, as for example, you'll be able to call make deploy-github-release and not have to convert the Makefile target into steps in an action. It will also help for building with musl. We have a container that's already setup for building with musl, so you can simply call the Makefile target to do this rather than having to do the setup again to build outside the container (though you could try it if you want).

You should be able to copy the deployment stuff from safe-api once we have finished implementing that.

For example config_file_manager (crust as well?) is unmaintained. I would say let's strikethrough the row in the table.

1. Switch all repos from Travis to GHA. This should be done after we figure out how to run parts of workflows on a schedule. Then, we can mostly copy the configuration from safe-nd, as it is simple and should easily extend to other repos with slight modifications (e.g. Routing has their own clippy script which should be called).
2. Update readmes and the QA page to point to the latest master build for each repo.

Currently we use a number of github access tokens almost one per lib in travis for gh-pages deploy.

Following the blog listing the setup process for Rust with Travis and Github Pages, we dont really need unique keys since the scope of the token is not per lib. We're also using different user-ids in different repos for these tokens and not a general bot such as MaidSafe-QA

Would be good to clean this up and have it setup with a single token for a bot-id.

There seems to be one commit which tries to run them without --release but it's removed in a subsequent commit with no commentary as to why.

Debug assertions includes various safety checks including overflow checks so it's worth running, or using the explicit types such as Wrapping<T>.

Two features may be worth making active while currently limited to one concurrent job:

• Rolling builds - only builds the latest commit from a given PR(maybe branch wise too)
• Skip building github tags

both features are available from the settings UI for each project: