@przemoc Hi, I found this thread since you mentioned Shippable… I’m a co-founder :)
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. Please reach out to me at manisha@shippable.com and I can point you to a couple of examples of how to do this.
We’re also working on a UI based config which will be launched in a few weeks.
I already left similar question to the one I asked here on your page via Conversations box. It was a few days ago and apparently no one was around, so I was asked to provide my e-mail to get an answer later, but I haven’t got any yet. I suggest removing that kind of chat box if you don’t intend to support it.
Good to hear that there is some flexibility in Shippable, because I couldn’t find such information in your docs. It would be great if you could share details here. Or is there any specific reason you cannot write about it publicly?
For public repos such build job logs, that statuses link to, must be
always accessible. They are useless otherwise.
(For private repos they have to be accessible too, but not necessarily
publicly to anyone for obvious reasons.)
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!
@przemoc 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. Most customers want the config yml in the same repository since that keeps source code and build pipeline in the same place.
The workflow our customer success team suggested is an alternative workflow since you had different requirements and wanted to separate config from source code.
Anyway, since our customer success team is helping you over email, let’s take it there.
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 am not sure you have even forked the sample and tried it one time to see if it meets your needs. You should obviously find the best alternative that works for your scenario and needs, but some politeness in the process is always well appreciated.
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.
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.
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.
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.
Can you make logs from pipeline jobs for public repositories publicly visible?
We’re looking into this issue and will have more information soon. After talking to the team, we need to rationalize how the runSh job type should behave in this situation. As mentioned earlier, the CI job already does this but that doesn’t address your needs.
Can you make URLs to logs from pipeline jobs less cryptic and human-readable?
They are already human readable. The reason the link in Ambarish’s example said ‘basicnode_ci’ and not ‘basicnode’ is because that’s how he named the job that contained the CI commands. If he had named it basicnode, it would have been showed up that way in the URL.
The runSh job is an Assembly Line job which is not automatically associated with a source code repository, which is why you also have to specify a gitRepo resource as an Input to the job. This is the main reason why I call it ‘not mainstream ci’, since the runSh job was designed to separate repositories from configured jobs.
As an example, you could potentially configure builds for 10 different projects in a single shippable.yml, along with provisioning jobs, deployment jobs, etc and configure a complete end to end workflow for your application.
I hope that clarifies why the build link cannot be tied to a separate project and is simply the job name.
Thank you for your answers, it clarifies some stuff. I really like the flexibility that you provide. I may still consider Shippable for use in the future. Hopefully the matter of publicly visible links for runSh job matters will be fixed by then.
@przemoc The only reason I reached out is because you mentioned us in the comment.
Since you’ve taken the trouble of explaining your stance, let me explain mine:
I saw that we could satisfy your scenario, and still believe we can. I was proposing a workflow that I wanted you to look at to see if it had what you needed. It’s perfectly ok if you see something that doesn’t work and choose to move on, but as long as we’re communicating, I expect it to be polite.
Every time you found something that you either didn’t agree with or in the case of 404 was a bug, your responses were not very polite…. for example, instead of saying: I want builds for public projects to be visible to everyone, or, Why am I getting a 404?, your response seemed to be similar to this : I get a 404!! Even basic services do this and without it it’s all useless, etc etc.
These type of statements do not give me confidence that you’re trying to understand why something works a certain way or to point out a bug… it sounds pretty hostile and condescending when in all actuality, we have these features working perfectly for the mainline scenario and were happy to investigate and try to address anything you needed even in the proposed workflow.
Your message above is a great example of why I am frustrated. Now you’re accusing me of hiding things or not being upfront. Our customer success process is through a github repository or over email. I cannot come here and keep responding to every comment you post here when the exact same conversation is also happening over email. If your goal was to keep folks updated, you could have completed our conversation over email and posted a recap here at the end of it. Do you really want me to conduct customer success activities here? That’s not a reasonable request and I’ll challenge you to find any SaaS companies that even went to the extent we did.
Another great example of your responses when Ambarish forgot to copy me on one email. You could have just copied me again and moved on. Instead your first instinct is to assume he either doesn’t understand or did it on purpose :
“If she asked you to remove her, then it’s fine, but if not, then you
shouldn’t do that, as it’s bad practice.”
“
Another example:
“404 means PAGE NOT FOUND (I hope you know that common knowledge).”
Your statements were pretty condescending to Ambarish and while I understand you were frustrated, he is too good an engineer to be talked to this way. I felt compelled to stand up for him.
At the end of the day, we got off on the wrong foot. This is the first time, in 4 years of running the service, where I have felt compelled to stand up for my team and just say that communication needs to remain polite and respectful. I am happy to continue the conversation over a call or over email, but I won’t be visiting this board to litigate this further.
Good luck and I hope you find a service that fits your needs.
Yesterday, before I sent my comment in response your other comment, where you wrote answers to my questions, I replied here. It was a longer comment (not as long as last time, thought), where I was addressing your points. But it’s not here, not sure what went wrong, and I don’t have the willpower to recreate it. I’ll only recreate what I wrote at the very end of it.
I apologize for all the words I’ve written that you think were rude, inappropriate, or condescending. I’ll apologize Ambarish personally tomorrow.
@przemoc Hi, I found this thread since you mentioned Shippable… I’m a co-founder :)
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. Please reach out to me at manisha@shippable.com and I can point you to a couple of examples of how to do this.
We’re also working on a UI based config which will be launched in a few weeks.
I already left similar question to the one I asked here on your page via Conversations box. It was a few days ago and apparently no one was around, so I was asked to provide my e-mail to get an answer later, but I haven’t got any yet. I suggest removing that kind of chat box if you don’t intend to support it.
Good to hear that there is some flexibility in Shippable, because I couldn’t find such information in your docs. It would be great if you could share details here. Or is there any specific reason you cannot write about it publicly?
Sorry for the late follow-up from our side to your question on chat. I believe you’re now in touch with our customer success team.
To clarify:
No problem, @manishas!
Indeed, I am in touch with one of your colleagues. And so far I am a bit disappointed.
Let’s visit:
There are lacking statuses, even in the latest one commit! And links from those available are wrong, as I get 404!
I archived it just in case:
For public repos such build job logs, that statuses link to, must be always accessible. They are useless otherwise. (For private repos they have to be accessible too, but not necessarily publicly to anyone for obvious reasons.)
The issue with broken links to build logs was apparently addressed by Shippable.
So I archived what we have right now in the sample project:
Links are different now, but as older ones gave me 404, new one gives me 404 too.
Previously they looked like this:
so pretty clear.
Now they look like this:
https://app.shippable.com/subscriptions/58b5dd45ddd8e8070045dab1/pipelines/builds/5a30c1fccf141c0700bf6cbe/consoles
which is HUGE UX regression in naming department.
Why so cryptic links for public repos? They should be human-readable.
But most importantly they should be simply working, and be accessible for anyone if it’s public repository.
I’m honestly amazed that service’s basic features seemingly aren’t working properly.
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!
@przemoc 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. Most customers want the config yml in the same repository since that keeps source code and build pipeline in the same place.
The workflow our customer success team suggested is an alternative workflow since you had different requirements and wanted to separate config from source code.
Anyway, since our customer success team is helping you over email, let’s take it there.
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 am not sure you have even forked the sample and tried it one time to see if it meets your needs. You should obviously find the best alternative that works for your scenario and needs, but some politeness in the process is always well appreciated.
Let me respond here to both of your comments in one.
Reply to 1st comment
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:
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:
So why there was no information that build logs won’t be publicly visible from the very beginning?
I hoped so, but after reading your next paragraph, I couldn’t remain silent.
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:
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’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!
And regarding this very particular mail strictly, there are questions that immediately pop out after reading it:
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 clearly stated that I didn’t fork it and I also explained why.
I was polite, but I don’t deny I got irritated at one point.
Reply to 2nd comment:
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.
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 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.
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:
Then my reply would be simply:
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.
The runSh job is an Assembly Line job which is not automatically associated with a source code repository, which is why you also have to specify a gitRepo resource as an Input to the job. This is the main reason why I call it ‘not mainstream ci’, since the runSh job was designed to separate repositories from configured jobs.
As an example, you could potentially configure builds for 10 different projects in a single shippable.yml, along with provisioning jobs, deployment jobs, etc and configure a complete end to end workflow for your application.
I hope that clarifies why the build link cannot be tied to a separate project and is simply the job name.
Thank you for your answers, it clarifies some stuff. I really like the flexibility that you provide. I may still consider Shippable for use in the future. Hopefully the matter of publicly visible links for runSh job matters will be fixed by then.
@przemoc The only reason I reached out is because you mentioned us in the comment.
Since you’ve taken the trouble of explaining your stance, let me explain mine:
Your statements were pretty condescending to Ambarish and while I understand you were frustrated, he is too good an engineer to be talked to this way. I felt compelled to stand up for him.
At the end of the day, we got off on the wrong foot. This is the first time, in 4 years of running the service, where I have felt compelled to stand up for my team and just say that communication needs to remain polite and respectful. I am happy to continue the conversation over a call or over email, but I won’t be visiting this board to litigate this further.
Good luck and I hope you find a service that fits your needs.
Yesterday, before I sent my comment in response your other comment, where you wrote answers to my questions, I replied here. It was a longer comment (not as long as last time, thought), where I was addressing your points. But it’s not here, not sure what went wrong, and I don’t have the willpower to recreate it. I’ll only recreate what I wrote at the very end of it.
I apologize for all the words I’ve written that you think were rude, inappropriate, or condescending. I’ll apologize Ambarish personally tomorrow.