As I said before, this is not the forum to discuss every single email we are exchanging offline.

If you try our mainline CI workflow, the links are human readable and publicly accessible. For example, here is a link to one of my projects : https://app.shippable.com/github/manishas/basic-node/runs/16/1/console

I want to again stress that your requirement isn’t a mainstream requirement. UI based config is clunky, un-versioned, and usually considered inferior. YAML based config is becoming the defacto standard, and even traditional tools like Jenkins are moving towards ci config as code.

I was trying to find a creative way make our platform work for your scenario, but maybe your needs are too specific. Good luck with your search!

Let me respond here to both of your comments in one.

Reply to 1st comment

you’re right that build results for public projects should be public. That is EXACTLY the behavior when you put the shippable.yml at the root of your repo.

So why the behavior isn’t the same when I put the file in other repo? In your first comment on my thread here you wrote:

You can configure builds on Shippable without putting a shippable.yml at the root of the repository you want to build. While the config is still yml-based, it can live in a separate repository pretty easily.

So can it live in a separate repository pretty easily or not? Apparently not, because it’s no longer functioning that well. Now I read that:

The workflow our customer success team suggested is an alternative workflow since you had different requirements and wanted to separate config from source code.

So why there was no information that build logs won’t be publicly visible from the very beginning?

Anyway, since our customer success team is helping you over email, let’s take it there.

I hoped so, but after reading your next paragraph, I couldn’t remain silent.

Overall, I am very disappointed in your communication style. Our customer success lead Ambarish specifically put together a sample for you and has been very responsive in clarifying all questions and issues, including the ones you raise above.

I appreciate that some sample was prepared specifically for me to show that what I wanted is possible with Shippable, but in fact it was not working, not even close. When you give someone sample you make sure it works. That’s the whole point of the sample. But let’s look back and see if what you wrote really holds value.

2 days ago, ~1.5h after getting first mail with the sample from customer success team (which was written to me in response to my question asked via conversation box few days before that), I replied that build links return 404.

The issue was completely skipped in response from Ambarish (which he sent 3 hours later).

Next day I replied mentioning another issue (which I didn’t catch before, because I was using smartphone when I was answering the first time, and mobile view on GitHub is limited): there are no commit statuses next to recent commits. And I repeated that I’m getting 404 errors when I try to see build logs from the commit statuses that are present.

First paragraph of response from Ambarish gave me some hope: “The links to the statuses are broken indeed! We are fixing this bug ASAP. “ 3.5h later there was a follow up message: “We have addressed the issue with the broken link. I had missed the showBuildStatus: true attribute on the gitRepo resource. The commit status links are correct now. You can fork the repo and try it out.”

Now I thought that maybe my first impression with the sample was wrong and Shippable actually seem to care after all. That’s nice. So I rechecked the repo. Finally there was a commit status next to the latest commit. I hovered over the tick icon and first thing I noticed was horrible and cryptic URL that I mentioned in my other comment already. So I clicked it. And guess what? 404.

So I replied mentioning that I am still getting 404 error when trying to visit build log. I also complained about needlessly cryptic URL for public repo, as they should be human-readable, and I reiterated: “But most importantly they should be simply working, and be accessible for anyone if it’s public repository.” Lastly, addressing forking invitation I simply stated: “There is no point in me forking the repo, if you cannot show that Shippable works even for some simple sample project.” That may sounded harsh indeed, but how can you react when someone tries to convince you that something works while it doesn’t really. Having build logs and looking into them are basic features in that kind of service for public repositories. At that time I was honestly amazed that they seemingly aren’t working properly.

In response Ambarish sent me “let me explain the whole story with the timeline”-mail. It sort of explained why commit statuses for older commits had wrong URLs. He ended mail saying that they will fix how URLs to build logs look like and make them more concise and gave me example: https://app.shippable.com/github/ambarish2012/jobs/basicnode_ci/builds/5a30c1fccf141c0700bf6cbe/console

There was one thing that was sorely lacking in his mail. The matter of 404 error I was still getting for build log for latest commit (e4fa8ae) was not even mentioned!

I got really irritated (who wouldn’t be at that point?). In the reply I wrote some of my paragraphs looked like this:

> 3. I then specified  showBuildStatus and the status links started getting
> posted correctly.

If they're posted correctly now, why they're not working?

404 means PAGE NOT FOUND (I hope you know that common knowledge).
And I get 404 for clicking the status icon next to your latest commit (e4fa8ae).
I even provided page archives so it would be clear.

    http://archive.is/RXXgC - commits page
    http://archive.is/JjV6I - "build log" that redirects to 404

Have you checked it?

If the link to build log doesn't work, then it's useless as I wrote earlier.

> https://app.shippable.com/github/ambarish2012/jobs/basicnode_ci/builds/5a30c1fccf141c0700bf6cbe/console.

That will be an improvement, definitely. But why basicnode_ci?
It's true that's where config is placed, but you're building
basicnode, so it should be reflected in the URL.

At the end I'll repeat what I wrote earlier.

Please fix the links to build logs.

Even bad looking link is better than good looking, which returns 404.
So far all links are bad.

I'm on the verge of becoming indifferent at this point, because I'm
mentioning about broken links to build logs from a few mails back and
they are all still broken, including the latest ones supposedly
generated after fixing configuration. I don't know why you are unable
to fix it for that long time. It's core feature, isn't it?

Surely that wasn’t an exemplary mail of politeness, but I was barely keeping my composure in check considering how communication looked so far.

Today I finally got response:

I perfectly understand what a 404 is :). The reason the link is a 404
for you is because you are not a member of my organization in GitHub.
Basically, I have created a simple pipeline to build my repository and
to see my pipeline, you need to be a member of my organization.

We can get into the details why you need to be a member of my
organization to view my pipelines as well if you like.

I’m baffled. Why we’re talking about some organizations all of a sudden? You were building public repo, right?

So things are apparently much more complex in Shippable than supposed to be and that were presented at the beginning. Well, it could be fine. But!

• Why not being straight from the beginning?
• Why no mention that I won’t be able to see build logs from sample application from the very start?
• And why no explanation what is the reason that you can view build log of public repo if its config is in the repo, but not if the config is in separate repo?

And regarding this very particular mail strictly, there are questions that immediately pop out after reading it:

• Why proper answer to my 404 error reports was avoided for so long?
• Why details of why you need to be a member of organization to view pipeline weren’t shared within this mail?

Does anyone reading my comment still believes that customer success team was “very responsive in clarifying all questions and issues, including the ones you raise above”?

I simply cannot agree with it. At the beginning I thought there is a genuine will to help me via showing how Shippable is capable of doing what I want. But with each further mail it seemed like it’s getting dragged for some reason (not in a strictly time-manner, but rather in a way how crucial information was (not) shared and how some of my issues were constantly skipped) and my main problem wasn’t addressed until the very last mail, and in fact only partially, as I am apparently supposed to ask one more time to be explained why it is like it is… And I mentioned so many times in my mails that build logs for public project must be available to anyone that it’s more than obvious that I would like to finally know these damn details, i.e. how is this sample application so different from “Most customers want the config yml in the same repository” case, that it cannot provide public build logs?

I started providing reports about Shippable in my thread here, because I hoped it would end up with success story - look, they reached me out and showed it can be done with Shippable. So everyone reading the thread in future would know that Shippable cares about their customers and delivers, even to non-paying ones wanting to build open-source projects there. But my hope was premature.

You say you are very disappointed in my communication style? I’m very disappointed that you sugar-coat how great communication looked from Shippable side.

I am not sure you have even forked the sample and tried it one time to see if it meets your needs.

I clearly stated that I didn’t fork it and I also explained why.

You should obviously find the best alternative that works for your scenario and needs, but some politeness in the process is always well appreciated.

I was polite, but I don’t deny I got irritated at one point.

Reply to 2nd comment:

As I said before, this is not the forum to discuss every single email we are exchanging offline.

That wasn’t my intention. I do believe, though, that open-source software and services for OSS need to be transparent and open, that’s what makes them best. You showed up in my thread stating that Shippable is up to my needs, so it was only natural that I’ll report back if it really is. I was only reporting here the issues I was facing so far.

But after seeing your 2 comments today, I decided I’ll share more details, to make the story more complete.

If you try our mainline CI workflow, the links are human readable and publicly accessible. For example, here is a link to one of my projects : https://app.shippable.com/github/manishas/basic-node/runs/16/1/console

But I was trying what customer success team prepared for me and that was supposed to match my needs. Talking about your mainline CI workflow here is a diversion.

I want to again stress that your requirement isn’t a mainstream requirement. UI based config is clunky, un-versioned, and usually considered inferior. YAML based config is becoming the defacto standard, and even traditional tools like Jenkins are moving towards ci config as code.

I understand that wanting to have configuration outside of main repo that is meant to be built is not a mainstream requirement. Otherwise I wouldn’t post this very question on lobste.rs regarding services that are able to do that.

And I have no clue why are you now talking about UI-based config. It’s another diversion from you. I prefer text-based configuration hands down, and YAML is fine for that. Have I criticized YAML configuration here or in any mail with Ambarish? I did not.

I just want the build preparation config for CI service to live outside of main repo, and if that may require using web UI (which actually doesn’t exclude use of YAML there and possibility of being versioned, right?), then I can still consider it despite my fully-text-based config preference.

I was trying to find a creative way make our platform work for your scenario, but maybe your needs are too specific. Good luck with your search!

Maybe my needs aren’t as specific as you paint and your platform would work for my scenario, but maybe you failed to communicate it properly, simply sell me on Shippable.

Maybe I should have accepted your proposal to mail you directly back then, because you seem to know the platform better, but back then I already left a question a few days earlier via your official site conversation box, so I believed I should go the standard way and wait for the reply, to have experience closer to standard prospective customer (who doesn’t know co-founder’s e-mail). I think it’s more fair that way. You were CCed by customer success team from the first mail anyway, so I guess that my experience was supposedly already meant to be better than most others can expect.

Not even once until today was stated, that supporting config out of the main repo is such a completely different workflow for Shippable, which has its own quirks like lack of publicly visible build logs, even for public repositories. I still don’t know why it is like that. Is it by design? What’s the rationale behind it? Maybe it could be fixed?

The whole discussion would go completely different if in the first mail from Shippable had proper sample, i.e. all needed information were included:

• link to the sample main repo with correct commit statuses,
• link to sample ci repo with correct config from the beginning,
• extremely important paragraph(s) explaining that to achieve such setup very different workflow (than in case of typical config-in-main-repo) has to be used, because typical run jobs work like this… [explanation], but we need here more advanced pipeline jobs (if I inferred correctly from what I read today from you and Ambarish), which work like this… [explanation], which leads us to the problem, that logs for them, that are linked from commit statuses, aren’t publicly visible, because… [explanation].

Then my reply would be simply:

• Can you make logs from pipeline jobs for public repositories publicly visible?
• Can you make URLs to logs from pipeline jobs less cryptic and human-readable?

Unfortunately it didn’t go that well.

I still don’t know answers to many of my questions. My curiosity slightly wants me to continue the mail conversation with Ambarish in hope that eventually they would be answered. My sanity, based on past experience and today @manishas’s comments, objects, though.

Are your scripts available somewhere? Does a write-up of your method exist? I’d be a huge fan of using that.