Release 0.3 (#7)

ci: switch to the paritytech repo

* docs: update documentation
* ci: name the second checkout for more clarity

- the default image is now paritytech/srtool
- the latest version is now fetch from the repo described by the "image" input

fix #5, fix #6

.github/workflows/bridges.yml

@@ -29,7 +29,8 @@ jobs:
         with:
           path: action
 
-      - uses: actions/checkout@v2
+      - name: Checkout repo under test
+        uses: actions/checkout@v2
         with:
           repository: paritytech/parity-bridges-common
           fetch-depth: 0

.github/workflows/cumulus.yml

@@ -29,7 +29,8 @@ jobs:
         with:
           path: action
 
-      - uses: actions/checkout@v2
+      - name: Checkout repo under test
+        uses: actions/checkout@v2
         with:
           repository: paritytech/cumulus
           fetch-depth: 0

.github/workflows/polkadot.yml

@@ -29,17 +29,13 @@ jobs:
         with:
           path: action
 
-      - uses: actions/checkout@v2
+      - name: Checkout repo under test
+        uses: actions/checkout@v2
         with:
           repository: paritytech/polkadot
           fetch-depth: 0
           path: repo
 
-      - name: debug
-        run: |
-          ls -al
-          pwd
-
       - name: Srtool build
         id: srtool_build
         uses: ./action

README.md

@@ -17,7 +17,7 @@
 
 ## Introduction
 
-[srtool](https://gitlab.com/chevdor/srtool) is a docker image that allows building Substrate WASM Runtimes in a deterministic manner. It ensures that all `srtool` users (and tooling), using the same/latest tag, will produce 100% exactly the same runtime. It enables further trustless verifications.
+[srtool](https://github.com/chevdor/srtool) is a docker image that allows building Substrate WASM Runtimes in a deterministic manner. It ensures that all `srtool` users (and tooling), using the same/latest tag, will produce 100% exactly the same runtime. It enables further trustless verifications.
 
 ![srtool gh action 512px](resources/logo/srtool-gh-action_512px.png)
 
@@ -29,11 +29,11 @@ Gitlab users are not left behind and can use the 2 first options mentioned below
 
 There are now several ways to use `srtool` in your project:
 
--   using `srtool` [via alias](https://gitlab.com/chevdor/srtool#user-content-using-an-alias): powerful but very verbose and prone to errors. This is for developers. This option is being deprecated and not recommended.
+-   using `srtool` [via alias](https://github.com/chevdor/srtool#user-content-using-an-alias): powerful but very verbose and prone to errors. This is for developers. This option is being deprecated and not recommended.
 
--   using the [srtool-cli](https://gitlab.com/chevdor/srtool-cli): much easier to use and removes a whole bunch of potential user’s mistakes. This is for developers.
+-   using the [srtool-cli](https://github.com/chevdor/srtool-cli): much easier to use and removes a whole bunch of potential user’s mistakes. This is for developers.
 
--   using the [srtool-app](https://gitlab.com/chevdor/srtool-app): the easiest option of all thanks to its GUI. This is good for non-developers.
+-   using the [srtool-app](https://github.com/chevdor/srtool-app): the easiest option of all thanks to its GUI. This is good for non-developers.
 
 -   using the Github actions from [this repo](https://github.com/chevdor/srtool-actions). This is for your automatic CI.
 

README_src.adoc

@@ -13,7 +13,7 @@ a| image::https://github.com/chevdor/srtool-actions/actions/workflows/polkadot.y
 
 == Introduction
 
-https://gitlab.com/chevdor/srtool[srtool] is a docker image that allows building Substrate WASM Runtimes in a deterministic manner. It ensures that all `srtool` users (and tooling), using the same/latest tag, will produce 100% exactly the same runtime. It enables further trustless verifications.
+https://github.com/chevdor/srtool[srtool] is a docker image that allows building Substrate WASM Runtimes in a deterministic manner. It ensures that all `srtool` users (and tooling), using the same/latest tag, will produce 100% exactly the same runtime. It enables further trustless verifications.
 
 image::resources/logo/srtool-gh-action_512px.png[align=center, width=25%]
 
@@ -25,9 +25,9 @@ NOTE: Gitlab users are not left behind and can use the 2 first options mentioned
 
 There are now several ways to use `srtool` in your project:
 
-- using `srtool` https://gitlab.com/chevdor/srtool#user-content-using-an-alias[via alias]: powerful but very verbose and prone to errors. This is for developers. This option is being deprecated and not recommended.
-- using the https://gitlab.com/chevdor/srtool-cli[srtool-cli]: much easier to use and removes a whole bunch of potential user's mistakes. This is for developers.
-- using the https://gitlab.com/chevdor/srtool-app[srtool-app]: the easiest option of all thanks to its GUI. This is good for non-developers.
+- using `srtool` https://github.com/chevdor/srtool#user-content-using-an-alias[via alias]: powerful but very verbose and prone to errors. This is for developers. This option is being deprecated and not recommended.
+- using the https://github.com/chevdor/srtool-cli[srtool-cli]: much easier to use and removes a whole bunch of potential user's mistakes. This is for developers.
+- using the https://github.com/chevdor/srtool-app[srtool-app]: the easiest option of all thanks to its GUI. This is good for non-developers.
 - using the Github actions from https://github.com/chevdor/srtool-actions[this repo]. This is for your automatic CI.
 
 == Requirements

justfile

@@ -1,4 +1,4 @@
-DEV_IMAGE := "nightly-2021-02-25-dev"
+DEV_IMAGE := "1.53.0"
 
 # List available commands
 default: