September 2018 - ick-discuss - listmaster.pepperfish.net

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, 5 months

2
1
0 / 0

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, 5 months

2
1
0 / 0

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.

4 years, 6 months

2
2
0 / 0

2023

2022

2021

2020

2019

2018

ick-discuss September 2018