Cirrus-ci-docs: Deleting or archiving failed tests

[cjdb]

Would it be possible for Cirrus to support deleting or at least archiving failed tests, specifically those that are failed because of bad Cirrus config scripts?

Motivation

Because I can't test my .cirrus.yml script locally, I can sometimes spend many commits trying to remotely debug. While I don't mind doing this, it would be nice if I could somehow nuke those from my log of failed builds, as they make up a large portion of my failed builds 🙁

Proposal 1

I often rebase my branch so that my Cirrus-related commits are reduced to one commit, so if it'd be nice to add a something like a [cirrus-config] tag to my commit message that could be used to indicate "hey, this commit might disappear, let's look for it in the next commit and remove the build log if it isn't present".

Proposal 2

Have an archive button that lets one archive or delete failed builds. I suspect this is the easier route, and makes it possible to hide config tests that are sitting in the logs right now.

Other

If you're concerned that this feature might be abused to pretend that a project is perfect, then perhaps it could be extended so that this tag works if .cirrus.yml is the only modified file. (This is probably orthogonal to the functionality anyway).

[AlexWayfer]

Because I can't test my .cirrus.yml script locally, I can sometimes spend many commits trying to remotely debug. While I don't mind doing this, it would be nice if I could somehow nuke those from my log of failed builds, as they make up a large portion of my failed builds slightly_frowning_face

You described the reason, not the goal.

[cjdb]

Because I can't test my .cirrus.yml script locally, I can sometimes spend many commits trying to > remotely debug. While I don't mind doing this, it would be nice if I could somehow nuke those from my log of failed builds, as they make up a large portion of my failed builds slightly_frowning_face

You described the reason, not the goal.

That's my motivation for asking for this feature (I've now added the 'motivation' heading to make this clearer). If I understand you correctly, the goal you're looking for can be found in the first paragraph: I'd like to remove particular failed builds from my logs.

[AlexWayfer]

No. It's look like XY Problem for me.

You don't want to see failed by config builds. But why? Do they interfere? Hurt the eyes? Compromise?

[cjdb]

No. It's look like XY Problem for me.

You are correct: this is an example of the XY problem. (Thank you for bringing this term to my attention).

I'd really appreciate a tool that locally validates my .cirrus.yml script, including evaluating all components of my script, so that I get local notification of when I have a malformed script. In other words, I'd like to be able to spin up an instance of Cirrus locally so that when I push my build script, it works on the first commit. Repeatedly pushing my .cirrus.yml is time consuming, especially when I receive exactly one diagnostic at a time. A simple YAML parser doesn't seem to be suffice: I need to know how Cirrus interprets my script, and if my Bash commands are well-formed with respect to the respective configurations.

You don't want to see failed by config builds. But why? Do they interfere? Hurt the eyes? Compromise?

As articulated above, I would ideally have no pushes to remote until my script is working as desired. I'd like to use CI to preserve and document my project's correctness on all supported platforms, but am also having to use it as a meta-auto-debugger at present.

When I finish a debugging a program in my terminal, I can run clear; reset; to wipe my screen clean. When I am in an IDE, I simply terminate the program, which usually closes anything else that's associated with it. I haven't been able to find a way for to remove the debugging noise from the Cirrus CI logs.

[AlexWayfer]

I think, online Config Lint tool is better, than deleting failed jobs…

[fkorotkov]

@cjdb, thank you for the suggestion! There is actually an internal design proposal of Cirrus CLI which should meet your needs. I've created an issue with a TLDR of the proposal: https://github.com/cirruslabs/cirrus-ci-docs/issues/108. The plan is to have the CLI earlier next year.

I think with the CLI described above deleting of such "bad" builds will be obsolete.

BTW did you know that you can append a branch name to repository link to get only builds for a particular branch. Very useful for checking health of the default branch. Here is an example: https://cirrus-ci.com/github/cirruslabs/cirrus-ci-web/master

[cjdb]

I think with the CLI described above deleting of such "bad" builds will be obsolete.

Thank you! I agree. With #108, I think this issue is closable.

BTW did you know that you can append a branch name to repository link to get only builds for a particular branch. Very useful for checking health of the default branch. Here is an example: https://cirrus-ci.com/github/cirruslabs/cirrus-ci-web/master

I wasn't aware of this: I'll take a look into that ASAP.