You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add and enforce a style guide (fixestoltec-dev#95)
* Define an automatically-enforceable style guide by adding an
.editorconfig file (configures shfmt).
* Replace Vim modelines by Bash shebangs so that shfmt can detect all
shell scripts as such, and update docs/package.md accordingly.
* Add `make lint` target to run `shellcheck` and report errors.
* Add `make format` target to run `shfmt` and report errors.
* Add `make format-fix` target to run `shfmt` and automatically fix
errors.
* Fix existing formatting errors.
* Check format and lint conformity in the `pr` workflow.
* Mention the style guide in docs/contributing.md
Co-authored-by: raisjn <[email protected]>
Copy file name to clipboardExpand all lines: README.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -52,10 +52,10 @@ This repository is automatically built and published every time that a commit is
52
52
Since all the packaged software in Toltec is free, you can also **build them from source yourself** instead of using the pre-built binaries.
53
53
The build process is fully [reproducible](https://reproducible-builds.org/), which means that you can verify that the published packages have not been tampered with during the automated build process.
54
54
55
-
[Learn how to build the repository from source →](docs/build.md)
55
+
[Learn how to build the repository from source →](docs/building.md)
56
56
57
57
### Improve it
58
58
59
59
Your contribution is welcome for adding new packages, updating existing ones or improving the build tooling.
60
60
61
-
[Learn how to contribute to Toltec →](docs/contribute.md)
61
+
[Learn how to contribute to Toltec →](docs/contributing.md)
Thank you for taking time to contribute to Toltec!
4
+
We welcome contributions from anyone, regarding for example [reporting bugs](#reporting-a-bug), [requesting](#request-a-package) or [adding new packages](#adding-a-new-package), [upgrading existing ones](#upgrading-a-package), [improving the docs](#improving-the-documentation), or other topics.
5
+
6
+
To make a request or report a bug, you simply need to [open a new issue](../../../issues/new/choose).
7
+
8
+
To directly propose changes, the basic procedure is to fork this repository, make the desired changes in your newly created local copy, and open a pull request.
9
+
When proposing changes, please make sure that you follow the [style guide](#style-guide).
10
+
After you submit your pull request, a maintainer will take time to review your changes, request modifications and then merge your changes into the repository if they fit.
11
+
12
+
### Common contributions
13
+
14
+
#### Requesting a package
15
+
16
+
**TODO**
17
+
18
+
#### Reporting a bug
19
+
20
+
**TODO**
21
+
22
+
#### Adding a new package
23
+
24
+
See [instructions for creating a package recipe](package.md).
25
+
26
+
* clone this repository
27
+
* switch to `testing` branch
28
+
* edit package/$PACKAGE/package, making sure to bump the version
29
+
* build the package (`make $PACKAGE`), making sure everything looks ok in artifacts/package/$PACKAGE/
30
+
* install the package to your tablet, verifying things work as expected
31
+
* for new packages, submit a pull request with the title: [$PACKAGE][$VERSION] - New Package
32
+
* for updating packages, submit a pull request with the title: [$PACKAGE][$VERSION] - Updated Package
33
+
34
+
#### Upgrading a package
35
+
36
+
**TODO**
37
+
38
+
#### Improving the documentation
39
+
40
+
**TODO**
41
+
42
+
### Style guide
43
+
44
+
All contributions must follow the project’s [style guide](../.editorconfig).
45
+
Shell scripts must also comply to [Shellcheck](https://github.com/koalaman/shellcheck).
46
+
Sticking to a common set of conventions makes it easier for everyone to read the source code and reduces the time spent reviewing little formatting details.
47
+
48
+
The code style for shell scripts will automatically be checked when you submit your pull request.
49
+
You may also check it manually by running `make format` (or `make format-fix` to automatically fix any issues) at the root of the repository (you need to have [shfmt](https://github.com/mvdan/sh) installed on your computer for this to work).
50
+
51
+
Compliance of shell scripts to Shellcheck will also automatically be checked.
52
+
To check it manually, run `make lint` at the root of the repository (you need to have Shellcheck installed on your computer for this to work).
Copy file name to clipboardExpand all lines: docs/package.md
+1-3
Original file line number
Diff line number
Diff line change
@@ -3,9 +3,7 @@
3
3
A **package recipe** is a Bash script containing metadata and instructions for building and installing a package.
4
4
This recipe is used by the packaging script to generate installable archives for the Opkg package manager.
5
5
6
-
> **Note:** A recipe is not executable and does not start with a shebang line (`#!/…`).
7
-
> It is not meant to be executed directly, but rather sourced by the packaging script.
8
-
> To enable syntax highlighting, the file should start with the following modeline: `# vim: set ft=sh:`.
6
+
> **Note:** Recipes should not be marked as executable because they are not meant to be executed directly, but rather to be sourced by the packaging script.
9
7
10
8
Sourcing a package recipe must have no side-effects, i.e. the metadata section can only execute commands which do not modify the system state, and stateful commands must be confined inside functions.
0 commit comments