GitLab CI: a build status for commit remains in progress in Bitbucket

[Denis Konovalyenko]

The "Builds" column status remains "In Progress" if the first job updates the status with "In Progress" value, but another job sets the "Success" one.

For instance, if you navigate to commits in Bitbucket and click on one of "In Progress" build status icon, then there might be present the following information:

In Progress
ci/gitlab-ci/verification
The build is running!
19 hours ago

Success
ci/gitlab-ci/success
The build passed!
19 hours ago

There is a need to find a proper way of stating the build status (maybe just stick to "success" or "failure").

[Denis Konovalyenko]

Imply the same solution for all projects which are integrating with GitLab.

[Mihai Nita]

I think I've fixed it, see https://bitbucket.org/okapiframework/okapi/commits/797ded4fb4afd2a1c62c86f95b81eebfca4c0e3d (ignore the slim change, only the ci/gitlab/build-status modification)

Didn't do it in xliff-toolkit because I was thinking to make all the tweaks in one place, then sync them all together (as part of the task to make them more consistent)

[Denis Konovalyenko]

@nmihai_2000 , thanks for looking into this!

I have thought about a slightly different solution - the ability to align multiple Bitbucket's builds with GitLab's jobs. Hope, will finish my experiments today and create a new pull request (will add you as a reviewer).

I am updating this message to show the possible screenshots when the second job is configured to fail.

Before failing (the build status in Bitbucket is "in progress"):

After failing (the build status in Bitbucket is "failed"):

If all jobs have been finished successfully (from another run):

[Mihai Nita]

To change description you will have to change BITBUCKET_DESCRIPTION, which is also ignored, right? BITBUCKET_KEY="ci/gitlab-ci/${BUILD_KEY:-$CI_JOB_NAME}"

I was reluctant to change that script, because it comes directly from GitLab. But it was clearly wrong. So now, that we had to change it, please feel free to "tinker" with it as needed :-)

---

the ability to align multiple Bitbucket's builds with GitLab's jobs

I'm a bit split about that :-) In one way it might be nice to have them "magically sync" On the other way feels a bit "dirty" using GitLab to update BitBucket :-)

On thing that Codeship was doing was download the scripts from "a central place" (git repo, ftp, whatever) Thant's a bit "clunky" too...

Maybe leave it "as is" for now. And will see how we do this. And we have an issue for that already, Issue #24, "Refactor profiles in the way to unify with other projects"

[Denis Konovalyenko]

@nmihai_2000 , thanks for commenting!

I was about to create a new pull request when saw your message here. Maybe, it would be better to try out the solution first, and if it does not work nicely, switch to the single build strategy. Could you please take a look at the pull request?

[Mihai Nita]

Where are the screenshots coming from? Bitbucket? How do you get to that info?

They look pretty nice and clear, I like them (mostly :-) But the second one is confusing: verification passed, deployment is still running, and then who failed? The pipeline? Why? If the deployment failed, then I would expect to see that red and failed, not running.

[Denis Konovalyenko]

@nmihai_2000 , the screenshots were from Bitbucket. That were two cases with the intentionally failing the snapshot job (you can see the related pipelines in GitLab here).

Agree, the second one looks a bit odd. This is the consequence of the inability (?) of knowing either the failing job name in the scope of an "on_failure" job or the status of a job in its "after_script" section. So, the "failure" job can only know about its pipeline, which ID and the direct link to it are provided in this case (to simplify the navigation to the UI of the CI system).

[Denis Konovalyenko]

@nmihai_2000, as of now, it is going to be consistent.

This is the result of the updated pull request (when there were 2 jobs and the 2nd one was intentionally failed):

Will make the final commit soon.

[Denis Konovalyenko]

The pull request #11 has been merged.