Research Basic Implementation Decisions

Iris Lightshard commented

2023-08-26 03:12:14 +00:00

Owner

Things like:

what languages/libraries should we use?
what types of jobs should we support?
what does data interchange and state look like?

Things like: - what languages/libraries should we use? - what types of jobs should we support? - what does data interchange and state look like?

Iris Lightshard added this to the Memnarch Flow project 2023-08-26 03:12:14 +00:00

Iris Lightshard commented

2023-08-26 04:30:31 +00:00

Author

Owner

Perhaps obviously, the main server will be written in Go with quartzgun; I will be testing some basic POC in the next few days

Iris Lightshard commented

2023-08-26 05:27:28 +00:00

Author

Owner

parameters like job type and specific job should be encoded in the route; then on checkout of the repo, use that info to run certain files in .memnarch directory...

parameters like job type and specific job should be encoded in the route; then on checkout of the repo, use that info to run certain files in `.memnarch` directory...

Iris Lightshard commented

2023-08-27 03:14:44 +00:00

Author

Owner

flows:

local|container -> build artifact -> publish
remote -> deployment
local|container -> lint/compile check

what information do we need for each of these flows where:

they remain scoped enough to warrant being separate flows
they have enough power to be able to function with multiple types of projects

flows: - local|container -> build artifact -> publish - remote -> deployment - local|container -> lint/compile check what information do we need for each of these flows where: 1. they remain scoped enough to warrant being separate flows 2. they have enough power to be able to function with multiple types of projects

Iris Lightshard commented

2023-08-27 03:22:36 +00:00

Author

Owner

perhaps these three basic use cases can be defined as one process (lint/compile check being just the build step)

necessary info:

build:
- how,
- success
- failure
deployment:
- what host
- what files
- to where (some kind of map of between locations and files, maybe just map[location][]file)
- what extra steps before moving files
- what extra steps after moving files

perhaps these three basic use cases can be defined as one process (lint/compile check being just the build step) necessary info: - build: - how, - success - failure - deployment: - what host - what files - to where (some kind of map of between locations and files, maybe just `map[location][]file`) - what extra steps before moving files - what extra steps after moving files

Iris Lightshard commented

2023-08-27 05:10:28 +00:00

Author

Owner

possible structure of a memnarch file (YAML):

build:
  cmd: buildCmd
  failure:
  - msg1: condition1
  - msg2: condition2

deploy:
  hosts:
    - host1
    - host2
  artifacts:
    - target/dir/1:
      - artifact1
      - artifact2
    - target/dir/2:
      - artifact3
  before:
    - step1: cmd1
    - step2: cmd2
  after:
    - step3: cmd3

build or deploy can be used independently or together. deploy.before or deploy.after can be omitted

syntax for failure conditions will need to be refined; maybe we don't even need them if we can just capture stderr and exit code

possible structure of a memnarch file (YAML): ``` build: cmd: buildCmd failure: - msg1: condition1 - msg2: condition2 deploy: hosts: - host1 - host2 artifacts: - target/dir/1: - artifact1 - artifact2 - target/dir/2: - artifact3 before: - step1: cmd1 - step2: cmd2 after: - step3: cmd3 ``` `build` or `deploy` can be used independently or together. `deploy.before` or `deploy.after` can be omitted syntax for failure conditions will need to be refined; maybe we don't even need them if we can just capture stderr and exit code

Iris Lightshard commented

2023-08-27 05:28:23 +00:00

Author

Owner

Could have multiple files for different jobs, eg:

.memnarch/lint.yml run on opening a PR
.memnarch/deploy.yml run on merging to main
.memnarch/package.yml run on creating a tag

and specifying the file in the route somehow

Could have multiple files for different jobs, eg: - `.memnarch/lint.yml` run on opening a PR - `.memnarch/deploy.yml` run on merging to main - `.memnarch/package.yml` run on creating a tag and specifying the file in the route somehow

Iris Lightshard commented

2023-08-28 04:30:00 +00:00

Author

Owner

We can inject a simple widget in the UI to retrieve the status of the latest jobs for a particular branch or object.

Job status can be stored based on repo and object
map[repo]map[object]struct { name, status, msg, start, end }

We can inject a simple widget in the UI to retrieve the status of the latest jobs for a particular branch or object. Job status can be stored based on repo and object `map[repo]map[object]struct { name, status, msg, start, end }`

Iris Lightshard commented

2024-04-06 17:56:47 +00:00

Author

Owner

Actions need to be sandboxed...

If we specify a container and copy the repo contents into it at a unified location (/opt/memnarch or something), then we can have our build process export some files back into the host filesystem, and buffer ourselves from nefarious actions in the build process.

Actions need to be sandboxed... If we specify a container and copy the repo contents into it at a unified location (/opt/memnarch or something), then we can have our build process export some files back into the host filesystem, and buffer ourselves from nefarious actions in the build process.

Research Basic Implementation Decisions #1