a
/
agola
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
agola/internal/config/config_test.go

468 lines
14 KiB
Go
Raw Normal View History

Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
// Copyright 2019 Sorint.lab
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied
// See the License for the specific language governing permissions and
// limitations under the License.
package config
import (
"fmt"
"testing"
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
"github.com/sorintlab/agola/internal/services/types"
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
"github.com/sorintlab/agola/internal/util"
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
"github.com/google/go-cmp/cmp"
"github.com/pkg/errors"
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
)
func TestParseConfig(t *testing.T) {
tests := []struct {
name string
in string
err error
}{
{
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
name: "test no runs 1",
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
in: ``,
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
err: fmt.Errorf(`no runs defined`),
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
},
{
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
name: "test no runs 2",
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
in: `
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
runs:
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
`,
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
err: fmt.Errorf(`no runs defined`),
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
},
{
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
name: "test empty run",
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
in: `
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
runs:
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
-
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
`,
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
err: fmt.Errorf(`run at index 0 is empty`),
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
},
{
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
name: "test empty task",
in: `
runs:
- name: run01
tasks:
-
`,
err: fmt.Errorf(`run "run01": task at index 0 is empty`),
},
config: check Runtime.Arch
2019-04-17 13:24:37 +00:00
{
name: "test empty runtime arch",
in: `
runs:
- name: run01
tasks:
- name: task01
runtime:
type: pod
containers:
- image: busybox
`,
},
{
name: "test invalid runtime arch",
in: `
runs:
- name: run01
tasks:
- name: task01
runtime:
type: pod
arch: invalidarch
containers:
- image: busybox
`,
err: fmt.Errorf(`task "task01" runtime: invalid arch "invalidarch"`),
},
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
{
name: "test missing task dependency",
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
in: `
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
runs:
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
- name: run01
tasks:
- name: task01
runtime:
type: pod
containers:
- image: busybox
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
depends:
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
- task02
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
`,
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
err: fmt.Errorf(`run task "task02" needed by task "task01" doesn't exist`),
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
},
{
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
name: "test circular dependency between 2 tasks a -> b -> a",
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
in: `
runservice: rename config pipeline(s) to run(s) No need for different names. We are always talking about a run. In the config it's the run definition, in the service is the run execution.
2019-04-15 21:42:10 +00:00
runs:
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
- name: run01
tasks:
- name: task01
runtime:
type: pod
containers:
- image: busybox
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
depends:
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
- task02
- name: task02
runtime:
type: pod
containers:
- image: busybox
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
depends:
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
- task01
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
`,
err: &util.Errors{
Errs: []error{
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
errors.Errorf("circular dependency between task %q and tasks %q", "task01", "task02"),
errors.Errorf("circular dependency between task %q and tasks %q", "task02", "task01"),
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
},
},
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
runservice: handle jsonnet and json config files Handle config files with name `config.jsonnet`, `config.json` and `config.yml` and take the first from the repository in this order For a jsonnet file execute it and use the generated output as the config
2019-04-16 13:00:37 +00:00
if _, err := ParseConfig([]byte(tt.in), ConfigFormatJSON); err != nil {
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
if tt.err == nil {
t.Fatalf("got error: %v, expected no error", err)
}
if errs, ok := err.(*util.Errors); ok {
if !errs.Equal(tt.err) {
t.Fatalf("got error: %v, want error: %v", err, tt.err)
}
} else {
if err.Error() != tt.err.Error() {
t.Fatalf("got error: %v, want error: %v", err, tt.err)
}
}
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
} else {
if tt.err != nil {
t.Fatalf("got nil error, want error: %v", tt.err)
}
}
})
}
}
func TestParseOutput(t *testing.T) {
tests := []struct {
name string
in string
out *Config
}{
{
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
name: "test task all options",
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
in: `
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
runs:
- name: run01
runservice: update docker registry auth
2019-04-22 12:38:25 +00:00
docker_registries_auth:
index.docker.io:
username: username
password:
from_variable: password
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
tasks:
- name: task01
runservice: update docker registry auth
2019-04-22 12:38:25 +00:00
docker_registries_auth:
index.docker.io:
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
username: username
password:
from_variable: password
runservice: update docker registry auth
2019-04-22 12:38:25 +00:00
runtime:
type: pod
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
containers:
- image: image01
auth:
username:
from_variable: username2
password: password2
environment:
ENV01: ENV01
ENVFROMVARIABLE01:
from_variable: variable01
config environment from variable
2019-03-18 14:02:32 +00:00
environment:
ENV01: ENV01
ENVFROMVARIABLE01:
from_variable: variable01
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
steps:
# normal step definition
- type: clone
- type: run
command: command01
- type: run
name: name different than command
command: command02
- type: run
command: command03
environment:
ENV01: ENV01
ENVFROMVARIABLE01:
from_variable: variable01
- type: save_cache
key: cache-{{ arch }}
contents:
- source_dir: /go/pkg/mod/cache
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
# simpler (for yaml not for json) steps definition
- clone:
- run: command01
- run:
name: name different than command
command: command02
- run:
command: command03
environment:
ENV01: ENV01
ENVFROMVARIABLE01:
from_variable: variable01
- save_cache:
key: cache-{{ arch }}
contents:
- source_dir: /go/pkg/mod/cache
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
when:
branch: master
tag:
- v1.x
- v2.x
ref:
include: master
exclude: [ /branch01/ , branch02 ]
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
depends:
- task: task02
conditions:
- on_success
- on_failure
- task03
- task04:
- on_success
- name: task02
runtime:
type: pod
containers:
- image: image01
- name: task03
runtime:
type: pod
containers:
- image: image01
- name: task04
runtime:
type: pod
containers:
- image: image01
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
`,
out: &Config{
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Runs: []*Run{
&Run{
Name: "run01",
runservice: update docker registry auth
2019-04-22 12:38:25 +00:00
DockerRegistriesAuth: map[string]*DockerRegistryAuth{
"index.docker.io": {
Type: DockerRegistryAuthTypeBasic,
Username: Value{Type: ValueTypeString, Value: "username"},
Password: Value{Type: ValueTypeFromVariable, Value: "password"},
},
},
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Tasks: []*Task{
&Task{
Name: "task01",
runservice: update docker registry auth
2019-04-22 12:38:25 +00:00
DockerRegistriesAuth: map[string]*DockerRegistryAuth{
"index.docker.io": {
Type: DockerRegistryAuthTypeBasic,
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Username: Value{Type: ValueTypeString, Value: "username"},
Password: Value{Type: ValueTypeFromVariable, Value: "password"},
},
runservice: update docker registry auth
2019-04-22 12:38:25 +00:00
},
Runtime: &Runtime{
Type: "pod",
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Arch: "",
Containers: []*Container{
&Container{
Image: "image01",
Environment: map[string]Value{
"ENV01": Value{Type: ValueTypeString, Value: "ENV01"},
"ENVFROMVARIABLE01": Value{Type: ValueTypeFromVariable, Value: "variable01"},
},
User: "",
},
},
runservice: implement docker registry auth By now just support default username/password login In future also support additional container registries with their own credential helpers
2019-04-10 15:13:51 +00:00
},
config: generalize and simplify value string/from_variable parsing
2019-04-10 15:12:39 +00:00
Environment: map[string]Value{
"ENV01": Value{Type: ValueTypeString, Value: "ENV01"},
"ENVFROMVARIABLE01": Value{Type: ValueTypeFromVariable, Value: "variable01"},
config environment from variable
2019-03-18 14:02:32 +00:00
},
runservice: set default config task working_dir Set default task working_dir to ~/project
2019-04-16 13:20:45 +00:00
WorkingDir: defaultWorkingDir,
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Shell: "",
User: "",
Steps: []interface{}{
&CloneStep{Step: Step{Type: "clone"}},
&RunStep{
Step: Step{
Type: "run",
Name: "command01",
},
Command: "command01",
},
&RunStep{
Step: Step{
Type: "run",
Name: "name different than command",
},
Command: "command02",
},
&RunStep{
Step: Step{
Type: "run",
Name: "command03",
},
Command: "command03",
Environment: map[string]Value{
"ENV01": Value{Type: ValueTypeString, Value: "ENV01"},
"ENVFROMVARIABLE01": Value{Type: ValueTypeFromVariable, Value: "variable01"},
},
},
&SaveCacheStep{
Step: Step{Type: "save_cache"},
Key: "cache-{{ arch }}",
Contents: []*SaveContent{&SaveContent{SourceDir: "/go/pkg/mod/cache", Paths: []string{"**"}}},
},
&CloneStep{Step: Step{Type: "clone"}},
&RunStep{
Step: Step{
Type: "run",
Name: "command01",
},
Command: "command01",
},
&RunStep{
Step: Step{
Type: "run",
Name: "name different than command",
},
Command: "command02",
},
&RunStep{
Step: Step{
Type: "run",
Name: "command03",
},
Command: "command03",
Environment: map[string]Value{
"ENV01": Value{Type: ValueTypeString, Value: "ENV01"},
"ENVFROMVARIABLE01": Value{Type: ValueTypeFromVariable, Value: "variable01"},
},
},
&SaveCacheStep{
Step: Step{Type: "save_cache"},
Key: "cache-{{ arch }}",
Contents: []*SaveContent{&SaveContent{SourceDir: "/go/pkg/mod/cache", Paths: []string{"**"}}},
},
config environment from variable
2019-03-18 14:02:32 +00:00
},
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
IgnoreFailure: false,
Approval: false,
When: &types.When{
Branch: &types.WhenConditions{
Include: []types.WhenCondition{
{Type: types.WhenConditionTypeSimple, Match: "master"},
},
},
Tag: &types.WhenConditions{
Include: []types.WhenCondition{
{Type: types.WhenConditionTypeSimple, Match: "v1.x"},
{Type: types.WhenConditionTypeSimple, Match: "v2.x"},
},
},
Ref: &types.WhenConditions{
Include: []types.WhenCondition{
{Type: types.WhenConditionTypeSimple, Match: "master"},
},
Exclude: []types.WhenCondition{
{Type: types.WhenConditionTypeRegExp, Match: "branch01"},
{Type: types.WhenConditionTypeSimple, Match: "branch02"},
},
},
},
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Depends: []*Depend{
&Depend{TaskName: "task02", Conditions: []DependCondition{DependConditionOnSuccess, DependConditionOnFailure}},
&Depend{TaskName: "task03", Conditions: nil},
&Depend{TaskName: "task04", Conditions: []DependCondition{DependConditionOnSuccess}},
},
},
&Task{
Name: "task02",
Runtime: &Runtime{
Type: "pod",
Arch: "",
Containers: []*Container{
&Container{
Image: "image01",
},
},
},
runservice: set default config task working_dir Set default task working_dir to ~/project
2019-04-16 13:20:45 +00:00
WorkingDir: defaultWorkingDir,
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Steps: []interface{}{},
Depends: []*Depend{},
},
&Task{
Name: "task03",
Runtime: &Runtime{
Type: "pod",
Arch: "",
Containers: []*Container{
&Container{
Image: "image01",
},
},
},
runservice: set default config task working_dir Set default task working_dir to ~/project
2019-04-16 13:20:45 +00:00
WorkingDir: defaultWorkingDir,
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Steps: []interface{}{},
Depends: []*Depend{},
},
&Task{
Name: "task04",
Runtime: &Runtime{
Type: "pod",
Arch: "",
Containers: []*Container{
&Container{
Image: "image01",
},
},
},
runservice: set default config task working_dir Set default task working_dir to ~/project
2019-04-16 13:20:45 +00:00
WorkingDir: defaultWorkingDir,
runservice: rework config format The current config format was thought for future extensions for reusing runtimes and job definitions adding some parameters. After a lot of thoughts this looks like a complex approach: the final result will be a sort of templating without a lot of powers. Other approach like external templating should be an alternative but I really don't think templating yaml is the way to go. A much better approach will to just use jsonnet when we need to create matrix runs and a lot of other use cases. So just make the config a simple yaml/json. User can generate their config using any preferred tool and in future we'll leverage jsonnet automated parsing and provide a lot of jsonnet based examples for most use cases. Main changes: * Runs are now an array and not a map. The run name is in the Name field * Tasks are now an array and not a map. The task name is in the Name field * Use https://github.com/ghodss/yaml so we'll use json struct tags and unmarshall functions
2019-04-16 09:01:02 +00:00
Steps: []interface{}{},
Depends: []*Depend{},
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
},
},
},
},
},
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
runservice: handle jsonnet and json config files Handle config files with name `config.jsonnet`, `config.json` and `config.yml` and take the first from the repository in this order For a jsonnet file execute it and use the generated output as the config
2019-04-16 13:00:37 +00:00
out, err := ParseConfig([]byte(tt.in), ConfigFormatJSON)
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
if err != nil {
t.Fatalf("unexpected error: %v", err)
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
}
*: initial implementation of when conditions
2019-03-07 17:01:34 +00:00
if diff := cmp.Diff(tt.out, out); diff != "" {
t.Error(diff)
Add initial agola config format and handling
2019-03-07 13:42:32 +00:00
}
})
}
}