Compare commits

...

2 Commits

7 changed files with 72 additions and 59 deletions

View File

@ -11,6 +11,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
* Migrated codebase to V 0.3.2
* Cron expression parser now uses bitfields instead of bool arrays
* Added option to deploy using agent-server architecture instead of cron daemon
### Fixed
@ -19,6 +20,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
* CLI no longer exits with non-zero status code when removing/patching
target
* Allow NULL values for branch in database
* Endpoint for adding targets now returns the correct id
## [0.4.0](https://git.rustybever.be/vieter-v/vieter/src/tag/0.4.0)

View File

@ -21,7 +21,8 @@ quicker.
I chose [V](https://vlang.io/) as I've been very intrigued by this language for
a while now. I wanted a fast language that I could code while relaxing, without
having to exert too much mental effort & V seemed like the right choice for
that.
that. Sadly, this didn't quite turn out the way I expected, but I'm sticking
with it anyways ;p
## Features
@ -49,7 +50,7 @@ update`.
I used to maintain a mirror that tracked the latest master, but nowadays, I
maintain a Docker image containing the specific compiler version that Vieter
builds with. Currently, this is V 0.3.
builds with. Currently, this is V 0.3.2.
## Contributing

View File

@ -17,7 +17,7 @@ If a variable is both present in the config file & as an environment variable,
the value in the environment variable is used.
{{< hint info >}}
**Note**
**Note**
All environment variables can also be provided from a file by appending them
with `_FILE`. This for example allows you to provide the API key from a Docker
secrets file.
@ -97,3 +97,25 @@ configuration variable required for each command.
build`.
* Default: `archlinux:base-devel`
### `vieter agent`
* `log_level`: log verbosity level. Value should be one of `FATAL`, `ERROR`,
`WARN`, `INFO` or `DEBUG`.
* Default: `WARN`
* `address`: *public* URL of the Vieter repository server to build for. From
this server jobs are retrieved. All built packages are published to this
server.
* `api_key`: API key of the above server.
* `data_dir`: directory to store log file in.
* `max_concurrent_builds`: how many builds to run at the same time.
* Default: `1`
* `polling_frequency`: how often (in seconds) to poll the server for new
builds. Note that the agent might poll more frequently when it's actively
processing builds.
* `image_rebuild_frequency`: Vieter periodically builds images that are then
used as a basis for running build containers. This is to prevent each build
from downloading an entire repository worth of dependencies. This setting
defines how frequently (in minutes) to rebuild these images.
* Default: `1440` (every 24 hours)
* `arch`: architecture for which this agent should pull down builds (e.g.
`x86_64`)

View File

@ -21,7 +21,7 @@ branch. This branch will be the most up to date, but does not give any
guarantees about stability, so beware!
Thanks to the single-binary design of Vieter, this image can be used both for
the repository server & the cron daemon.
the repository server, the cron daemon and the agent.
Below is an example compose file to set up both the repository server & the
cron daemon:
@ -76,7 +76,7 @@ architectures will build on both.
## Binary
On the
[releases](https://git.rustybever.be/vieter/vieter/releases)
[releases](https://git.rustybever.be/vieter-v/vieter/releases)
page, you can find statically compiled binaries for all
released versions. This is the same binary as used inside
the Docker images.
@ -106,5 +106,5 @@ guarantee that a compiler update won't temporarily break them.
## Building from source
The project [README](https://git.rustybever.be/vieter/vieter#building) contains
instructions for building Vieter from source.
The project [README](https://git.rustybever.be/vieter-v/vieter#building)
contains instructions for building Vieter from source.

View File

@ -37,6 +37,6 @@ Each section can consist of as many of these parts as necessary.
## CLI tool
The Vieter binary contains a command that shows you the next matching times for
a given expression. This can be useful to understand the syntax. For more
a given expression. This can be useful for understanding the syntax. For more
information, see
[vieter-schedule(1)](https://rustybever.be/man/vieter/vieter-schedule.1.html).

View File

@ -32,7 +32,7 @@ fn agent_init(logger log.Log, conf Config) AgentDaemon {
logger: logger
client: client.new(conf.address, conf.api_key)
conf: conf
images: new_image_manager(conf.image_rebuild_frequency)
images: new_image_manager(conf.image_rebuild_frequency * 60)
builds: []BuildConfig{len: conf.max_concurrent_builds}
atomics: []u64{len: conf.max_concurrent_builds}
}

View File

@ -110,6 +110,21 @@ fn (mut q BuildJobQueue) reschedule(job BuildJob, arch string) ! {
q.queues[arch].insert(new_job)
}
// pop_invalid pops all invalid jobs.
fn (mut q BuildJobQueue) pop_invalid(arch string) {
for {
job := q.queues[arch].peek() or { return }
if job.config.target_id in q.invalidated
&& job.created < q.invalidated[job.config.target_id] {
// This pop *should* never fail according to the source code
q.queues[arch].pop() or {}
} else {
break
}
}
}
// peek shows the first job for the given architecture that's ready to be
// executed, if present.
pub fn (mut q BuildJobQueue) peek(arch string) ?BuildJob {
@ -118,20 +133,11 @@ pub fn (mut q BuildJobQueue) peek(arch string) ?BuildJob {
return none
}
for {
job := q.queues[arch].peek() or { return none }
q.pop_invalid(arch)
job := q.queues[arch].peek()?
// Skip any invalidated jobs
if job.config.target_id in q.invalidated
&& job.created < q.invalidated[job.config.target_id] {
// This pop *should* never fail according to the source code
q.queues[arch].pop() or { return none }
continue
}
if job.timestamp < time.now() {
return job
}
if job.timestamp < time.now() {
return job
}
}
@ -146,27 +152,18 @@ pub fn (mut q BuildJobQueue) pop(arch string) ?BuildJob {
return none
}
for {
mut job := q.queues[arch].peek() or { return none }
q.pop_invalid(arch)
mut job := q.queues[arch].peek()?
// Skip any invalidated jobs
if job.config.target_id in q.invalidated
&& job.created < q.invalidated[job.config.target_id] {
// This pop *should* never fail according to the source code
q.queues[arch].pop() or { return none }
continue
}
if job.timestamp < time.now() {
job = q.queues[arch].pop()?
if job.timestamp < time.now() {
job = q.queues[arch].pop()?
// TODO how do we handle this properly? Is it even possible for a
// cron expression to not return a next time if it's already been
// used before?
q.reschedule(job, arch) or {}
// TODO how do we handle this properly? Is it even possible for a
// cron expression to not return a next time if it's already been
// used before?
q.reschedule(job, arch) or {}
return job
}
return job
}
}
@ -182,28 +179,19 @@ pub fn (mut q BuildJobQueue) pop_n(arch string, n int) []BuildJob {
mut out := []BuildJob{}
outer: for out.len < n {
for {
mut job := q.queues[arch].peek() or { break outer }
for out.len < n {
q.pop_invalid(arch)
mut job := q.queues[arch].peek() or { break }
// Skip any invalidated jobs
if job.config.target_id in q.invalidated
&& job.created < q.invalidated[job.config.target_id] {
// This pop *should* never fail according to the source code
q.queues[arch].pop() or { break outer }
continue
}
if job.timestamp < time.now() {
job = q.queues[arch].pop() or { break }
if job.timestamp < time.now() {
job = q.queues[arch].pop() or { break outer }
// TODO idem
q.reschedule(job, arch) or {}
// TODO idem
q.reschedule(job, arch) or {}
out << job
} else {
break outer
}
out << job
} else {
break
}
}