Build page broken on mobile browsers

[niallo]

In mobile Safari on iOS 7 (iPad) there are numerous issues:

• Can't change builds with the "Past Builds" list. Touch events seem to be ignored.

Additionally in portrait mode:

• Sizing of console is broken - it is not a scrollable element, but instead a single large element which sizes to fit all content without a scrollbar.
• General text sizing and fitting issues.
• Top nav bar has white space above it

In landscape mode the page looks much more like it does on desktop but:

• Sizing of console output still slightly too tall
• Display of build times is cut off

[jnovack]

This is a fundamental css nightmare that should result in a refactor to bootstrap 3. Thoughts?

[jaredly]

Yeah, definitely bootstrap 3. Peter made an effort a while ago but may have gotten side tracked On Feb 2, 2014 9:06 AM, "Justin J. Novack" notifications@github.com wrote:

This is a fundamental css nightmare that should result in a refactor to bootstrap 3. Thoughts?

Reply to this email directly or view it on GitHubhttps://github.com/Strider-CD/strider/issues/290#issuecomment-33903882 .

[jnovack]

There are SO many changes between BS2 and BS3, it might be easier for a rip and replace.

I have a bootstrap3 branch (locally) that I'm in the process of reverting to generic BS3 (and FontAwesome v4) classes. Once that is finished, I hope to be merged upstream to a bootstrap3 branch, and then suggest we re-style with the strider theme/look and feel.

[niallo]

Awesome work on this @jnovack! Can't wait to see the final result in master.

[jnovack]

Thank you. Don't judge it yet. I am attacking things in random fashion as I'm just browsing through all the pages. I'd say I'm less than 30% done. I will try to remain as faithful as possible to the v2 look and feel.

I am concerned about this page, the build/job page. There seems to be an amalgamation of builds and projects, I think there is too much info on this page. This is a page listing the builds for a particular project as well as the detail of the last build. Project -> Detail of builds on project.

I do not feel the concept of the "commit" on this page. Are there plans to introduce a commit layer? Project -> Commits -> Details of builds on that commit.

[niallo]

Just to clarify the data model. Strider doesn't have a concept of builds. It has a concept of jobs. Jobs are linked to projects (which are a VCS concept) and commits (and optionally other metadata too).

[jnovack]

I understand all I'm doing is comparing to wercker. And if that's not the original intent of the project, it's ok. I just find concepts in strider conflict with my workflow and just trying to understand the reasoning behind them.

[niallo]

I've never used Wercker and it's definitely not our intention to clone it (nor any other existing product). The goal of Strider is to be a highly extensible, easy-to-use, lightweight, open source CD platform.

Can you go into some deeper explanation of your workflow and how Strider concepts conflict with it? That would help us understand the issues. I don't quite know what you mean by "introduce a commit layer" for example.

[jaredly]

@jnovack as it stands, strider is rather decoupled from the idea of version control. If you wanted to, you could create a provider plugin that doesn't under VC at all, and therefore has no concept of a commit. What strider knows about are jobs. Because VC is awesome, one common job type is "commit". Other job types are "pull-request", and "manual". As such, introducing a "commit layer" would mean changing the model and in some ways limiting extensiblity. That said, I'm open to arguments in favor of the change.

[jnovack]

At least give it a shot, it is the gold standard of CDs. You might get some good ideas.

By lack of commits, I mean organization by commits. I don't care that a job has passed or failed, I care which commit has been deployed. I don't care that I (or my devs) ran 10 jobs on the same commit until it (the settings) passed, I just care that the last job on THAT commit passed and my settings are now right and I can deploy it.

In my mind, the organization of my dashboard is many projects, each project shows me my commit tree (annotated to show which commit has been pushed to which deploy target). Upon drilling to a commit, I can see the details of the last build or past builds (of that commit) and interact appropriately (e.g. See the build details, etc).

Currently, Strider focuses on a list of jobs on a project. This is perfect for a lightly complicated project just to get it out to a single target.

I would want a list of jobs -on a commit-. But moreso a list of commits on a project. I have 8 different targets that I may want on different commits (to test something). I would like to click on commit 111111 (which should be showing green because the last build of it passed) and click Deploy to Target X. I would like to click commit 222222 (on branch Y) and deploy to target Z.

I have 8 different targets that I may want to deploy at separate times. (This is issue two I have, there is current no way to set up different targets to be deployed or configured differently, but that's for another ticket :) ).

(Wrote this before jaredlys response)

Sent from one of my iPads

On Feb 3, 2014, at 6:57 PM, niallo notifications@github.com wrote:

I've never used Wercker and it's definitely not our intention to clone it (nor any other existing product). The goal of Strider is to be a highly extensible, easy-to-use, lightweight, open source CD platform.

Can you go into some deeper explanation of your workflow and how Strider concepts conflicts with it? That would help us understand the issues. I don't quite know what you mean by "introduce a commit layer" for example.

Reply to this email directly or view it on GitHubhttps://github.com/Strider-CD/strider/issues/290#issuecomment-34015890 .

[jaredly]

Interesting. You're right, strider's not at all in a position to handle that kind of complex workflow at the moment. You said "I don't care that a job has passed or failed, I care which commit has been deployed". To my mind, the question "Is our codebase broken" is one of the chief questions you ask your CI system. Right? And Strider wants to do both integration and deployment.

[niallo]

Strider supports per-branch configuration. Each Git branch can have it's own deploy target. Maybe we could have a more commit-centric view of jobs which might help.

[jnovack]

the question "Is our codebase broken" is one of the chief questions you ask your CI system.

I think I see my differences now. I require more Deploy Management, rather than (in addition to) Continuous Deployment. For a few of my targets, I always want them to be on HEAD on master if green. In that instance, boom!, Strider can do that (and is doing that, I have that set up locally).

I don't want you to think I'm trying to take anything away from Strider. I'm certainly not panning it in any way.

There will be, the inevitable commit that passes tests, but is fundamentally, or logically broken (often due to a lack of tests, or inability to make a test for a change). In that instance, it will be green, and should it by some reason make it to master, my natural instinct would be to go to the CD, find the last-(for-realz)-known-good-commit, and re-deploy the stable version. In that case, I'd say "Strider, save me!" and Strider would say "Sorry, you have to back to your git branch and revert master to the last good commit, then I'd have to retest it, hopefully that won't take long, and then we can redeploy it! Otherwise, I can't help you."

Strider supports per-branch configuration. Each Git branch can have it's own deploy target.

git checkout target_x
git merge master
git checkout target_y
git merge stage

could turn into a nightmare. Your deployment strategy would be in your git repo. And please, for flying spaghetti monster's sake, hope nobody accidentally pushed a wrong merge to a target.

Is this an edge case? Am I out in left field?

The DM model supports the CI/CD inherently (set up a target, set deploy on green), whereas the current model doesn't (naturally) support DM.

[jaredly]

That makes a lot of sense. So I see two issues here:

1. "strider, save me!" will be fixed by having a "DEPLOY_ONLY" job type, right? You can go back to one of the jobs in strider, and say "redeploy".
2. One situation that I've seen that I think relatively common: For each new commit
3. deploy to a test server, run some integration tests.
4. if that works, deploy to a staging server, have QA do some manual stuff.
5. if that checks out, deploy to production

Is that the situation you're describing?

On Tue, Feb 4, 2014 at 4:26 AM, Justin J. Novack notifications@github.comwrote:

the question "Is our codebase broken" is one of the chief questions you ask your CI system.

I think I see my differences now. I require more Deploy Management, rather than (in addition to) Continuous Deployment. For a few of my targets, I always want them to be on HEAD on master if green. In that instance, boom!, Strider can do that (and is doing that, I have that set up locally).

I don't want you to think I'm trying to take anything away from Strider. I'm certainly not panning it in any way.

There will be, the inevitable commit that passes tests, but is fundamentally, or logically broken (often due to a lack of tests, or inability to make a test for a change). In that instance, it will be green, and should it by some reason make it to master, my natural instinct would be to go to the CD, find the last-(for-realz)-known-good-commit, and re-deploy the stable version. In that case, I'd say _"Strider, save me!"and Strider would say "Sorry, you have to back to your git branch and revert master to the last good commit, then I'd have to retest it, hopefully that won't take long, and then we can redeploy it! Otherwise, I can't help you."_

Strider supports per-branch configuration. Each Git branch can have it's own deploy target.

git checkout target_x git merge master git checkout target_y git merge stage

could turn into a nightmare. Your deployment strategy would be in your git repo. And please, for flying spaghetti monster's sake, hope nobody accidentally pushed a wrong merge to a target.

Is this an edge case? Am I out in left field?

The DM model supports the CI/CD inherently, whereas the current model doesn't support DM.

Reply to this email directly or view it on GitHubhttps://github.com/Strider-CD/strider/issues/290#issuecomment-34050793 .

[jnovack]

First, at this point, I understand I am just bikeshedding, so, we can cut this trivial discussion at any time.

I guess where I'm going with this, is a separation of the minutia/debug output of the running job from the deployment status (of the commits/targets).

Going to the strider/namespace/project page right now is jarring as it throws you directly into strider/namespace/project/job/job_id page. The page could be thinned out by listing commits (link to all jobs on a commit), last test status (link to job/job_id of the last job, does anyone care about the last-1 test status of a certain commit at quick glance?), and deployed to (see: target integration).

1. "strider, save me!" will be fixed by having a "DEPLOY_ONLY" job type, right? You can go back to one of the jobs in strider, and say "redeploy".

This where I would want to naturally go back to a COMMIT, not to a JOB. "I forget, is job number 23897354 the right job for the commit?" I understand jobs run on commits, they shouldn't just be as prevalent to the user. You hopefully only have one or two jobs per commit (test, deploy), I would think they should be "less" visible to the user (thus prompting my commit stance). "Oh, this commit is green? Great, deploy it"

That's my mental model of using strider, I can mock it up if you think it would be beneficial to beat the dead horse more.

[jaredly]

I'm totally open to that. The current model was based on the assumption that the first thing you want to know when you look at a project was "how did the last build go", which, as you have pointed out, doesn't scale in its current form to multiple branches & build targets. So I'd love to see the way you envision the main project page.

[microadam]

likewise! I have been following this discussion with interest and would love to see how you envisage this working

[jnovack]

I'll mock a screenshot flow sometime before the weekend ends (for bootstrap 3 css, but not live in the branch). If that the reception is positive, we can dive into how the routes and (if the) back-end change and flesh out the details. I love your enthusiasm!

[niallo]

Excited to see this too!

[AlexAndrascu]

This is getting interesting!

[jnovack]

Is this ok for side-nav? (Default style applied, minimal code change). (PS, you can always find my latest work on my fork if you don't want to wait for me to create a PR.) :)

[jaredly]

yeah looks great

On Wed, Feb 5, 2014 at 7:37 PM, Justin J. Novack notifications@github.comwrote:

Is this ok for side-nav? (Default style applied, minimal code change).

[image: screenshot 2014-02-05 20 57 04]https://f.cloud.github.com/assets/387006/2094964/8f350cf2-8ed7-11e3-8efc-d41dd5c2c924.png

Reply to this email directly or view it on GitHubhttps://github.com/Strider-CD/strider/issues/290#issuecomment-34286731 .