Hi,

I noticed that on `git push` I get the following message when I have
"shell: true" in a build manifest:

    remote: Notice: removing 'shell: true' from build manifest

After searching for a bit I found this [1] which says that it's been
disabled for auto builds because it's a debugging feature. Which I agree
it is.

Is there any chance of adding an option similar to `-o skip-ci` which
would disable stripping the "shell: true"? I would find it useful when
working on build manifests to get shell access after a push even when it
doesn't fail to be able to check that it's doing the right thing (I'm
sure others would too).

My current workaround is to add a task like this into the manifest after
the point that I want to confirm/sanity check/experiment with:

    tasks:
      - do-stuff: |
          # does things

      - fail: |
          false

      - more-stuff: |
          # does more things

- Oskari

[1]: https://todo.sr.ht/~sircmpwn/git.sr.ht/339

It's disabled because submitting unattended shell: true jobs will cause
the build image to run for its full maximum duration of 4 hours, which
is 4 hours of build time no one else can use that build slot for.

I'd recommend using hut(1) to submit your manifest after a push if you
want to grab a shell with it.

On Wed, Apr 12, 2023 at 10:36:38 +0200, Drew DeVault wrote:
> It's disabled because submitting unattended shell: true jobs will cause
> the build image to run for its full maximum duration of 4 hours, which
> is 4 hours of build time no one else can use that build slot for.
> 

Ah yeah, I didn't think of that. I had, perhaps wrongly, assumed that "I
want a shell" implies "I will use the shell". But I can see how
something like quickly rerunning your last `git` command might end up
with lots of (unintentionally) idling jobs.

> I'd recommend using hut(1) to submit your manifest after a push if you
> want to grab a shell with it.

Coolio, thanks for pointing me to that tool. I'll have to check it out.

- Oskari