Error with version 8.2.1
Troubleshooting
- [X] I've searched discuss.bitrise.io for possible solutions.
- Which version of the step is effected? 8.2.1
- Is the issue reproducible with the latest version? YES
- Does the issue happen sporadically, or every time? EVERY TIME
- Is the issue reproducible locally by following our local debug guide? NOT APPLICABLE
Useful information
Issue description
Hello, I'm still analysing further but it seems that when my workflows started using the latest 8.2.1 version earlier today (auto-update), ALL of them started failing.
I've rolled back to 8.0.1 and it's working fine. Note: using bitbucket self-hosted.
Hope this helps! Cheers, Francisco
Bitrise info
- Build URL: https://app.bitrise.io/build/41c38d56-10f5-4941-8c9c-1dc2ea392eb5
- Bitrise Support enabled: YES
- Log:
Working tree is dirty, cleaning before checkout: $ git "clean" "-fd" ... $ git "reset" "--hard" "HEAD" fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git[ ...] -- [ ...]' Failed to reset repository: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [ ...] -- [ ...]' $ git "fetch" "--jobs=10" "--no-tags" "origin" "refs/heads/develop" fatal: refusing to work with credential missing host field
Steps to reproduce
- ...
- ...
Additional info as I think I determined the cause for the problem:
- As we are using self hosted bitbucket, prior to cloning the repo we configure authentication with netrc and download all the required crts and keys.
- This is causing the repo not to be clean and failing the check introduced in this new 8.2.1 version
- After determining it's not clean, git clean -fd deletes everything
- Authentication fails when doing the hard reset as there is no GIT_HTTP_USERNAME and GIT_HTTP_PASSWORD configured (which doesn't seem to be possible to edit and select existing secrets that already have these credentials).
Is this expected? Should we change the way we do authentication to use the experimental support introduced in 8.1.0?
Update: if I try to use the experimenta authentication (and removed other steps prior to this), the clean check passes but then authentication doesn't work:
$ git "fetch" "--jobs=10" "--depth=1" "--no-tags" "origin" "refs/heads/develop"
fatal: unable to access ... LibreSSL SSL_read: error:1404C45C:SSL routines:ST_OK:reason(1116), errno 0
Oh, you are right @fcar12, the root cause is that the working directory has a new file added prior to running the git clone step (and the file is needed for the git clone to work).
Would it be possible to download the required files to another dir, for example the home dir? This way, the working directory ($BITRISE_SOURCE_DIR) would remain clean.
@ofalvai, writing the files to the home dir instead does work (although it requires further changes in the workflows, to other steps that also require the same files for updating git status).
However, we could avoid this (having extra steps and files, which would also be good) if the authentication support for private http repositories was working correctly (see comment above). Should I file a ticket for that or as it is experimental, you are already aware of this and it should be working correctly in a future release?
Hello there, I'm a bot. On behalf of the community I thank you for opening this issue.
To help our human contributors focus on the most relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 90 days, so I marked it as stale.
The community would appreciate if you could check if the issue still persists. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me".
If no comment left within 21 days, this issue will be closed.
I'll close this issue as it doesn't seem to be relevant anymore. We believe an old issue probably has a bunch of context that's no longer relevant, therefore, if the problem still persists, please open a new issue.