Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
G
goaljobs
Manage
Activity
Members
Labels
Plan
Issues
0
Issue boards
Milestones
Wiki
Code
Merge requests
0
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
OpenSource
goaljobs
Commits
3d473620
Commit
3d473620
authored
11 years ago
by
Richard W.M. Jones
Browse files
Options
Downloads
Patches
Plain Diff
Remove NOTES file, no longer up to date.
parent
c233ce39
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
NOTES
+0
-91
0 additions, 91 deletions
NOTES
with
0 additions
and
91 deletions
NOTES
deleted
100644 → 0
+
0
−
91
View file @
c233ce39
## NB ##
These notes reflect earlier thinking about the language and may not
necessarily accurately describe the current goaljobs language. Please
read the documentation instead.
## NB ##
Like 'make' except:
- Predicates can be based on arbitrary expressions, not just
"file X is older than file Y".
- Rules are more flexible and encourage structuring and reuse
through functions.
- Goals can be parameterized.
- Program can run continuously to implement business rules.
Differences from 'whenjobs':
- Goals instead of variables.
- Persistent (across session) variables exist, but are not central.
- Doesn't use <<..>> for shell scripts (has a function 'sh' instead).
- No daemon.
Similarities to 'whenjobs':
- Each shell script runs in its own temporary directory.
Example program:
let package = "foo"
let rec goal website_updated version =
let tarfile = sprintf "%s-%s.tar.gz" package version in
let tarpath = getenv "HOME" // "html" // tarfile in
let url = sprintf "http://example.com/%s" tarfile in
target (url_exists url);
require (tarball_exists version);
require (tarball_tested version);
sh "rsync %s example.com:/html/" tarpath
and goal tarball_tested version =
let tarfile = sprintf "%s-%s.tar.gz" package version in
let tarpath = getenv "HOME" // "html" // tarfile in
let memkey = package ^ "_tested_" ^ version in
target (memory_exists memkey);
require (tarball_exists version);
sh "
tar zxf %s
cd %s-%s
./configure
make
make check
" tarpath package version;
memory_set memkey "1"
and goal tarball_exists version =
let tarpath = getenv "HOME" // "html" // tarfile in
target (file_exists tarpath);
sh "
cd $HOME/repos/%s
git fetch
git archive --prefix %s-%s/ v%s | gzip > %s-t
mv %s-t %s
" package package version version tarpath tarpath tarpath
every 1 hour =
let version = shout "
cd $HOME/repos/%s
git fetch
git describe --tags --abbrev=0 --match='v*'
" package in
require (website_updated version)
This compiles down to a command line program that can be used like this:
./compile [-flags] [goals]
The goals are not enabled automatically. You have to do something
(simple) to publish a goal and specify how command line arguments get
mapped to goal arguments, since the mapping is not likely to be 1-1
strings. In the end you can do stuff like:
./compile all
./compile clean
./compile build program # program is a parameter
./compile -my-flag # custom flags can be defined
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment