In #4163 (closed) we deprecated Windows Batch cmd for the shell executor. Remove anything related to the cmd script generation. If the user-defined something else other then bash or powershell we should show an error message to the user.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
From my point of view CMD / Batch shouldn't be removed until Bash is fully (and natively, see WSL) supported on windows (see #1515 (closed)), or at least is able to do so via WSL(1/2)
Why? Because Bash is a lot more similar to Batch than Batch is to Powershell.
Having only Powershell available on windows is more than crippling. (Yes I refuse to switch to Powershell, if I had to move somewhere I'd move to Bash, which has the possibility to run on all platforms by now.)
One also has to consider that even a custom executor can't be used to directly emulate Batch support. (unless you follow yet another workaround in the docs by substituting Powershell: Start-Process "cmd.exe" "/c C:\Path\file.bat")
Removal can happen anytime, but restoring a feature once removed for any kind of reason is a lot harder. (And I know a few that are considering to not upgrade Gitlab further past the removal of CMD, which isn't something that anyone here would want)
I completely agree with @neico. Removing cmd does not make any sense from a user's perspective. Some experimentation with the Powershell executor showed me that it does not work properly and/or has surprising behavior. All the issues I could find about it are not actually resolved (eg closed but not fixed) or they are 'moved' with this useless gitlab bot message that doesn't actually tell anyone where it was moved to.
Even assuming powershell works correctly there will be a ridiculous effort to port all repositories' gitlab-ci files and it will be very difficult to verify that all potential failures behave the same etc. Those CI files grew organically over years and from my perspective you are removing a well-functioning feature from Gitlab without a good reason.
Removing Powershell does not make any sense from a user's perspective.
I believe you meant to say CMD here, otherwise the rest of your statement hardly makes sense.
they are 'moved' with this useless gitlab bot message that doesn't actually tell anyone where it was moved to.
That's because the bot only notifies of the change, the actual link is on top at the closed label where it has a (moved) link set
But yes, I find it pretty strange that any concern in this regard is just silently ignored, the related MR doesn't have one person mentioning it as a possible blocker.
To me, this NOT looks like a good idea as well. The reasons you have, are rather your difficulties, but not something which makes concerns of your users. Who in a sane, would want to use that PowerCrap, for their scripts unless this is a live-or-death question? Why not Python, a far more popular alternative, which you may embed in your Runner distribution, if you absolutely must drop support for CMD shell?
This is a change that has come upon us quickly. Nobody in our company have moved to powershell yet, across a variety of distinct projects. I agree batch file support has its quirks, but it is also universal on Windows.
We will likely have to stick to an older runner and hope that it neither breaks nor are we forced to upgrade due to incompatibilities.
In the announcement it says:
""
When a user registers a new runner shell executor it will now default to powershell.
""
Does it mean that existing gitlab-runners will work as before ?
What happens after gitlab-runner upgrade ? will it work still?
That is correct. The deprecation warning was added to the documentation in the %11.11 release, in the shell section.
The scripts can still be made to work by invoking CMD from Powershell, e.g. Start-Process "cmd.exe" "/c C:\Path\file.bat", but CMD is no longer supported out-of-the-box. Please see all the activity related to this work in #4163 (closed).
I really think You'd better made cmd in maintenance mode, just to avoid disruptive effects on old, dormant and tomorrow not reproducible pipelines.
cmd have bugs? Fair, we already know how to avoid them
cmd will not work in a new environment? Fair, new stuff can use powershell
Please, if you'd like to have enterprise customers, please, understand the problem of releasing a non backward compatible product update.
Forcing your customers to follow the product release cycle, not only for new features but also for any feature deprecation (fair) or removal (bad) is quite a scary future to me.
Yeah I'm again asking my organization to file more support tickets to prevent this from happening. The currently recommended 'workaround' to use Start-Process is a complete joke and defeats the whole purpose of a .gitlab-ci.yml file with build steps. Might as well use Jenkins or some other CI system in that case.
I honestly cannot believe the response is 'yeah we said in 11.11 that it would be deprecated'. I simply cannot believe none of your paying customers are protesting...
@pedropombeiro See additional context below from Matteo. For this type of backward compatibility use case, do you think the approach of invoking CMD from Powershell would be simple to implement?
Just to give you some insight about our position, I introduce here a bit about our business (Cad for the leather industry).
In this industry, we offer some desktop products, with 2+ years maintenance, and machines with a longer support period. Once we release a version, we usually keep that branch in maintenance mode, with atomic back-ports of bug fixes.
If a client has a problem on a machine, purchased 3 years ago (in 2016 we migrated from SVN the first projects), and we find a firmware bug, we'd like to run the same exact pipeline that we used to run the first time.
If the code committed has become broken without touching it, you can understand this adds an unexpected complication to a process that was supposed to be easy.
And this happens with a very bad timing, we are in hurry for the fix, for the release and the CI does not work, not because of an error, no, by design!
TL;DR: each non backwards compatible change adds a vote in favor of moving to a different platform, and we very like GitLab!
And I really think the problems will arise, but given the low visibility this change is having compared to how disruptive it can be, you will hear about it only once spread, with angry customers with failed hot-fix releases.
First of all, thank you all for voicing the concern we really appreciate the feedback.
We've decided that we will NOT be removing Windows Batch, we are adding it back in !2112 (merged) with a few caveats that we are still discussing:
PowerShell is going to be the default shell, even if shell is not defined. Users will have to specify shell = "cmd" if they want to use Windows batch. This is still being discussed in !2112 (comment 344915775)
That sounds like a decent plan, except for no bug fixes.
If the team isn't working on it directly anymore, that's fine.
But what about if the community wants to get something fixed (maybe something critical popped up, which needs to be fixed), wouldn't it be ok to allow community MR's to be merged in at least?