[PATCH] ick.liw.fi: Fix typos
by Teemu Hukkanen
>From 0d6ace13433e49d23fc1ea086bf2d2bc1224ea9a Mon Sep 17 00:00:00 2001
From: Teemu Hukkanen <tjhukkan(a)iki.fi>
Date: Sat, 29 Sep 2018 00:29:29 +0200
Subject: [PATCH] Fix typos
---
architecture.mdwn | 66 +++++++++++++++++++++++------------------------
ick_files.mdwn | 10 +++----
newuser.mdwn | 2 +-
patches.mdwn | 6 ++---
roadmap.mdwn | 12 ++++-----
5 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/architecture.mdwn b/architecture.mdwn
index a04bb61..159966a 100644
--- a/architecture.mdwn
+++ b/architecture.mdwn
@@ -11,14 +11,14 @@ evolve into also being a tool for also doing continuous deployment
This document describes the technical architecture of ick.
Specifically, the architecture for the upcoming ALPHA-6 release, but
-not further than that. ALPHA-6 is meant to usable by people other than
-the primary developer.
+not further than that. ALPHA-6 is meant to be usable by people other
+than the primary developer.
What is continuous integration?
-----------------------------------------------------------------------------
-Continuous integration is a style software development where changes
-get integrated to the main line of development freuqently. It is
+Continuous integration is a software development style where changes
+get integrated to the main line of development frequently. It is
contrasted with a style where features get developed in their own,
long-living branches and only get integrated when finished, often
after weeks or months of development. The latter often results in an
@@ -53,11 +53,11 @@ architecture that among other things only allowed running one build at
a time, and did not work well as a service.
The second (current) generation of ick is a re-design from scratch,
-keeping nothing of the first genearation. It is explicitly aimed to
+keeping nothing of the first generation. It is explicitly aimed to
become a "hostable" system: to allow an ick instance to be a CI system
to a number of independent users.
-The name "ick" was suggestd by Daniel Silverstone in an IRC
+The name "ick" was suggested by Daniel Silverstone in an IRC
discussion. He said "all CI systems are icky", and this prompted Lars
to name the first generation "ick".
@@ -68,7 +68,7 @@ Overview
A continuous integration system is, at its most simple core, an
automated system that reacts to changes in a program's source code by
doing a build of the program, running any of its automated tests, and
-then publishing the results somewhere. A continuoues deployment system
+then publishing the results somewhere. A continuous deployment system
continues from there to also installing the new version of the program
on all relevant computers. If any step in the process fails, the
system notifies the relevant parties.
@@ -77,7 +77,7 @@ Ick aims to be a CI system. It deals with a small number of concepts:
* **projects**, which consist of **source code** in a version control
system
-* **pipelines**, which are reuseable sequences of actions aiming to
+* **pipelines**, which are reusable sequences of actions aiming to
achieve some task (build program source code, run tests, etc)
* **workers**, which do all the actual work by executing pipeline
actions
@@ -244,9 +244,9 @@ how they are used individually and together.
hopefully happen not too far in the future.)
* The **icktool** command line tool provides the ick user interface.
- It get an access token from the identity provider, and uses the
+ It gets an access token from the identity provider, and uses the
controller and artifact store APIs to manage project and pipeline
- descriptions, build artfifacts, trigger builds, and view build
+ descriptions, build artifacts, trigger builds, and view build
status.
[Qvisqve]: http://qvarn.org/qvisqve
@@ -384,7 +384,7 @@ every API client. There are three exceptions:
the IDP.
* Triggering a project to build. This is temporarily un-authenticated,
to avoid having to distribute API credential to git server. This
- willl be fided later.
+ will be fixed later.
Getting an access token: ickui and OpenID Connect
@@ -397,12 +397,12 @@ than the client credentials grant for non-interactive use.
[OpenID Connect]: https://openid.net/specs/openid-connect-core-1_0.html
-In summary, there are five entitities involved:
+In summary, there are five entities involved:
* the end-user who owns (in a legal meaning) the resources involved
* the "resource server" where the resources technically are: this
means the controller and artifact store, and possibly other ick
- compontents that hold data on behalf of the end-user
+ components that hold data on behalf of the end-user
* the IDP (Qvisqve), which authenticates the end-user and gives out
access tokens that allow the bearer of the access token to do things
with the user's resources
@@ -411,7 +411,7 @@ In summary, there are five entitities involved:
* a "facade" that sits between the browser and the resource servers
The facade is necessary for security. We do not trust the browser to
-be keep an access token secure from malware running on the end-user's
+keep an access token secure from malware running on the end-user's
machine or device, including in the browser. The facade runs on what
is assumed to be a more secure machine, and can thus be trusted with
the access token. The facade can also provide a more convenient API
@@ -423,8 +423,8 @@ front-end, and includes the access token to those.
* User initiates login, by clicking on a "login" link in the front-end
UI. Or else the facade initiates this, when its access token
- expires. Either way, the browser makes a request the facade's login
- endpoint.
+ expires. Either way, the browser makes a request to the facade's
+ login endpoint.
* Facade redirects user's browser to Qvisqve.
* This is called the "authorization request". It includes some
data that's needed to prevent various security intrusions.
@@ -498,21 +498,21 @@ parameters. If it looks OK, Qvisqve creates an "authorization attempt
object", and stores `CLIENTID`, `RANDOMSTRING`, and `CALLBACKURI` in
it. It also generates an object id (a UUID4).
-Qvisvqe returns to the browser a login form, asking for username and
+Qvisqve returns to the browser a login form, asking for username and
password, plus a hidden form field with the authorization attempt
object id.
The user fills in the login form, and submits it. The submitted form
-includes the authorization attempt object id field. Qvisqve checks the
-id value corresponds to an existing authorization attempt object, and
-that the credentials are valid. If so, it creates an authorization
-code, stores that into the authorization object, and responds the form
-submission with:
+includes the authorization attempt object id field. Qvisqve checks
+that the id value corresponds to an existing authorization attempt
+object, and that the credentials are valid. If so, it creates an
+authorization code, stores that into the authorization object, and
+responds to the form submission with:
HTTP/1.1 302 Found
Location: CALLBACKURI?code=AUTHZCODE&state=RANDOMSTRING
-Here, `CALLBACKURI` and `RANDOMSTRING` are the retrieved from the
+Here, `CALLBACKURI` and `RANDOMSTRING` are the ones retrieved from the
authorization object.
Browser follows the redirect to the facade. The facade checks that
@@ -536,9 +536,9 @@ Qvisqve. The client id must be the same as given in the initial
authorization request.
Qvisqve checks the client's credentials (`Authorization` header), and
-the `AUTHZCODE` is one it has generated and that hasn't yet been used,
-and that `CALLBACKURI` is registered with the facade. If all is well,
-it responds the facade's token request:
+that the `AUTHZCODE` is one it has generated and that hasn't yet been
+used, and that `CALLBACKURI` is registered with the facade. If all is
+well, it responds to the facade's token request:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
@@ -630,14 +630,14 @@ diagram.
deactivate resources
facade -> browser : some thing
deactivate facade
- broser -> enduser : show thing to user
+ browser -> enduser : show thing to user
deactivate browser
end
@enduml
-(This should be the same protocol as descibed in prose above.)
+(This should be the same protocol as described in prose above.)
The worker-manager
-----------------------------------------------------------------------------
@@ -866,16 +866,16 @@ Ick controller resources and API
See the example project for examples. Each item in the `projects` and
`pipelines` lists is a resource. The example is in YAML syntax, but is
-trivially converted to JSON, which the API talks. (The exampel is
+trivially converted to JSON, which the API talks. (The example is
input to the `icktool` command and is meant to be human-editable. YAML
is better for that, than JSON.)
For a fuller description of the APIs, see the [yarn][] scenario tests
in the ick source code: <http://git.liw.fi/ick2/tree/yarns>
-A build resource is created automatically, when a project is triggerd,
-at `/builds/BUILDID`, a pipeline is triggered. It can't be changed via
-the API.
+A build resource is created automatically, when a project is
+triggered, at `/builds/BUILDID`, a pipeline is triggered. It can't be
+changed via the API.
{
"project": "liw.fi",
@@ -899,7 +899,7 @@ for now we'll have just the name.
"worker": "bartholomew"
}
-A work resource resource tells a worker what to do next:
+A work resource tells a worker what to do next:
{
"project": "liw.fi",
diff --git a/ick_files.mdwn b/ick_files.mdwn
index 55bb586..7313706 100644
--- a/ick_files.mdwn
+++ b/ick_files.mdwn
@@ -10,7 +10,7 @@ of pipelines.
A project has a name, optionally defines some parameters, and lists
one or more pipelines. A pipeline is a re-useable sequence of build
-actions to achieve a goal, such a checking out code from version
+actions to achieve a goal, such as checking out code from version
control, or building binaries from source code.
You can roughly think of a pipeline as a subroutine that the project
@@ -54,7 +54,7 @@ three possibilities:
* `container` – in a container using a defined system tree
(systree) and workspace bind-mounted at /workspace
-You should strive to run all actions in conatiners, since that makes
+You should strive to run all actions in containers, since that makes
it hardest to mess up the worker host.
Actions are run as root in the container, and in a chroot. On the
@@ -90,7 +90,7 @@ The worker manager defines (at least) the following actions:
* `archive: workspace`
Take the current content of the workspace, put it in a compressed
- tar archive, and uplad it to the artifact store. Get the name of
+ tar archive, and upload it to the artifact store. Get the name of
the artifact from the parameter named in the `name_from` field, if
given, and the`artifact_name` parameter if not.
@@ -173,7 +173,7 @@ The worker manager defines (at least) the following actions:
.mirror/$name && git remote update --prune`).
Ick provides a pipeline that uses the `git_mirror` action and
- addtional `shell` or `python` actions to do the checkout.
+ additional `shell` or `python` actions to do the checkout.
* `action: rsync`
@@ -233,7 +233,7 @@ Build one for each target Debian release: `jessie`, `stretch`,
store with systree artifacts. Each actual project should use one of
the artifacts to do the build in a container.
-You can use the `ick/build_debian_systree` pipeline to build systreees
+You can use the `ick/build_debian_systree` pipeline to build systrees
with Debian.
When building in a container, you can install more things inside the
diff --git a/newuser.mdwn b/newuser.mdwn
index 5531e50..2788568 100644
--- a/newuser.mdwn
+++ b/newuser.mdwn
@@ -7,7 +7,7 @@ This page has instructions for using it. Thank you for helping me with
ick.
Ick is ALPHA level software, and keeps changing. Sorry about that. As
-part of process, the way ick is accessed is currently changing.
+part of that process, the way ick is accessed is currently changing.
Everything in this page is likely to change in the coming weeks. Be
prepared to learn new things, although we will try to avoid breaking
things.
diff --git a/patches.mdwn b/patches.mdwn
index 54d99be..c69fb56 100644
--- a/patches.mdwn
+++ b/patches.mdwn
@@ -40,13 +40,13 @@ Here's a few ways you can send us changes:
ick-discuss mailing list. (Using "git send-email" is good, too.)
If you're sending a patch series consisting of several patches,
- add a "cover letter" that expolains what the whole series is about.
+ add a "cover letter" that explains what the whole series is about.
* Make the changes available on a different git server, and send us a
URL we can pull from. You can use GitHub or any other server that's
convenient for you. You can even create a pull request and send a
URL to that. We prefer you send us the URL over e-mail to the
- ick-dicusss mailing list, as that gets automatically tracked
+ ick-discuss mailing list, as that gets automatically tracked
# On patches (and pull requests)
@@ -55,7 +55,7 @@ We prefer a patch series and pull request to tell a story of the
change that is easy to follow and review and understand.
* Each patch/commit should have a clear commit message. The commit
- message should explain why the change is made, and not just repharse
+ message should explain why the change is made, and not just rephrase
the diff. The commit message should stand on its own, as it will be
read on its own in the future, when someone is debugging the
program, possibly with "git bisect".
diff --git a/roadmap.mdwn b/roadmap.mdwn
index 065238a..79b126b 100644
--- a/roadmap.mdwn
+++ b/roadmap.mdwn
@@ -8,17 +8,17 @@ Ick is now usable by others. If you try ick and have problems, do tell
us, see the [[contact]] page for contact information.
Ick is by no means an abandoned project, but we're taking a breather
-while waiting for other developments. Most imporantly, ick will want a
+while waiting for other developments. Most importantly, ick will want a
web UI, and that and other features will require end-user
authentication. The Qvisqve software ick uses for authentication will
-be getting that support in 2018. Once it does, ick start adding
+be getting that support in 2018. Once it does, ick will start adding
support for that.
Until then, the plan is to make small, incremental improvements to
-ick, fix bugs, improve documentation, smooth rought corners, and
+ick, fix bugs, improve documentation, smooth rough corners, and
gather experience on using ick.
-The long-term goal is to develp ick into a hosted service, which can
+The long-term goal is to develop ick into a hosted service, which can
be run on a commercial basis, without compromising on software
freedom.
@@ -51,7 +51,7 @@ freedom.
label: |
Ick supports building
for multiple
- architecturs.
+ architectures.
depends:
- worker_tags
- concurrency
@@ -127,7 +127,7 @@ freedom.
a git repo changes,
or when an ick build
finishes, or after
- some time has psssed
+ some time has passed
isolation:
label: |
--
2.19.0
4 years, 12 months
Npm/node.js installation
by Ivan Dolgov
Here's how I've installed a recent enough version of npm on Stretch machines.
Looks like Buster comes with Node.js v8, but I'm not sure if its npm is
usable, I've used 9 or 10 for a long time now. If using upstream APT repo is
not an opiton, I can spend some time testing the older version of npm.
In the ansible playbook I use sane_debian_system role to add the node.js repo:
sources_lists:
- repo: "deb https://deb.nodesource.com/node_10.x stretch main"
signing_key: "{{ nodesource_signing_key }}"
The signing key is here:
https://deb.nodesource.com/gpgkey/nodesource.gpg.key
Then I just install build-essential and nodejs packages. After that running
`make install` in ickui repo will install dependencies locally into
ickui/node_packages dir and `make build` will create a static bundle in
ickui/dist.
Ivan
4 years, 12 months
Ick planning: what next?
by Lars Wirzenius
Ick has been a little on the backburner lately, while I sort out some
personal and work stuff. However, it would be good to have a little
discussion about where we should take ick next.
Current status is that the controller works and builds happen. There is
_very_ rudimentary web application.
It is clear to me, after talking to various people, that a web interface
for ick should be a high priority. I'm not good with front-end web stuff,
so that's something I'd really like help with.
A pre-requisite for an ick web application is to make end-user
authentication more sensible. At the moment, the web application allows the
user to log in, and that works. However, the command line application,
icktool, requires a different set of credential.
Technically, the web application uses the OpenID Connect authorization code
flow for login, and ickdtool uses the OAuth2 client credentials grant. I
think this needs to be handled so that the web application is changed to
allow the user to create an "API token", which icktool can use to access
the controller. This allows the user to only have one set of credentials,
which is much more sane.
The API token will be an extension to OIDC, and will allow icktool to
retreive a standard access token, for actually accessing the controller
API. The access token will identify the user.
When all API use identifies the user, we can change ick to assign an owner
to each resource (project, pipeline, build, build log, artifact), and
restrict users to only see, create, modify, and delete their own artifacts.
This, in turn, will take ick much closer to being a "hostable service",
where different users are more or less safe from each other.
What do you all think about this? Is there something you'd really like to
see in ick, before or after the above? Please say, the floor is open for
dreams, fantasies, and wishes.
The ick web application will be using the RESTful HTTP APIs of the various
ick components, but can otherwise be separate from them. It can be
implemented in any language and way, as long as the user is happy to use it
and it uses Qvisqve for end-user authenticattion and the ick APIs for drive
ick. I'd like the web application to be free software, built using tools in
Debian, and have no dependencies outside what is packaged in Debian.
However, I realise that's a difficult request in the modern world of web
development, so I'm willing to discuss the build and runtime dependencies,
though not the freedom.
If web application front-ends are something you like working on, please say
so. I'd really appreciate any help with the front-end.
5 years