Libtaskotron - allow non-cli data input
by Josef Skladanka
Chaps,
we were discussing this many times in the past, and as with the
type-restriction, I think this is the right time to get this done, actually.
It sure ties to the fact, that I'm trying to put together
Taskotron-continuously-testing-Taskotron together - the idea here being
that on each commit to a devel branch on any of the Taskotron components,
we will spin-up a testing instance of the whole stack, and run some
integration tests.
To do this, I added a new consumer to Trigger (
https://phab.qa.fedoraproject.org/D1110) that eats Pagure.io commits, and
spins jobs based on that.
This means, that I want to have the repo, branch and commit id as input for
the job, thus making yet-another-nasty-hack to pass the combined data into
the job (https://phab.qa.fedoraproject.org/D1110#C16697NL18) so I can hack
it apart later on either in the formula or in the task itself.
It would be very helpfull to be able to pass some structured data into the
task instead.
I kind of remember that we agreed on json/yaml. The possibilities were
either reading it from stdin or file. I don't really care that much either
way, but would probably feel a bit better about having a cli-param to pass
the filename there.
The formulas already provide a way to 'query' structured data via the
dot-format, so we could do with as much as passing some variable like
'task_data' that would contain the parsed json/yaml.
What do you think?
Joza
7 years, 2 months
Switching Beaker from SAML to Kerberos?
by Dan Callaghan
Now that we have Kerberos for Fedora infrastructure, I would like to
switch beaker.qa.fedoraproject.org to use mod_auth_kerb (Kerberos)
instead of mod_auth_mellon (SAML).
This will also give us working authentication for the bkr CLI, which
helps with automated job submission.
Any objections to this?
If not, I'll update the Ansible role and make the change on stage so we
can see how it goes.
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat
7 years, 2 months
making test suites work the same way
by Kamil Paral
I spent a bit of time fixing minor issues in our test suite and makefiles and would like to do the following further changes across all our taskotron projects:
1. run the test suite while inside virtualenv with simple `pytest` command
2. run the test suite outside of virtualenv with `make test` or `doit test` and recommend this approach in readme
3. use a separate virtualenv when running under `make test`, without --system-site-packages if possible, and ensure up-to-date deps are always installed, to eliminate any differences that can occur on different setups
4. configure pytest to print out coverage by default, so that it shows up for both `pytest` and `make test`
Any concerns or different suggestions?
7 years, 2 months
Lift type-restriction on ibtaskotron's cli + resultsdb directive
by Josef Skladanka
Hey Gang,
this is bugging me for quite a while now, and although I know why we put
the restrictions there back then, I'm not sure the benefits still outweigh
the problems.
Especially now, when we'll probably be getting some traction, I'd like to
propose removing the type-check completely. On top of that, we could have
some "known" types (koji_build, bodhi_update, compose, ...), and implement
a "spellcheck" - like a Hamming or Levenshtein distance - to catch typos,
and warn the user.
All the Taskotron jobs are given the type programatically now anyway, so
the worry-for-typos is now IMO a bit lessened, and actual human users would
be warned in the logs.
(lib)Taskotron is pretty agnostic to what the people are doing with it, and
this seems to be a lefover arbitrary limit, that may have sense, but should
probably be implemented in an other part of the stack (like trigger) that
the users may be (in the future) directly interacting with.
Thoughts?
Joza
7 years, 2 months