Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-18430] Create CLI-based app to speed reproduction of bugs

GitHub Issuen/a
TypeNew Feature
PriorityHigh
StatusOpen
ResolutionUnresolved
Affected Version/sn/a
Fix Version/sn/a
ComponentsTooling
Labelsn/a
ReporterIngo Muschenetz
AssigneePraveen Innamuri
Created2015-01-22T18:32:17.000+0000
Updated2015-01-27T18:34:14.000+0000

Description

We need the following CLI-based application. It would be a slim layer on top of the existing titanium CLI and assist with rapidly building an application based on a set of example code. When support/users submit code, they generally place a snippet of code into the description of a ticket. This code is _generally_ a replacement for app.js. In order to test this, users create a new titanium application, paste in the code from the ticket in place of app.js and then run the application. This would formalize a system whereby a user could point the CLI to a particular ticket, it would read in the code attached, and then create a new application based on that. Ultimately, this could tie into one of our automation systems whereby the harness app created is able to read some of the additional metadata as required by https://github.com/appcelerator/titanium_mobile_tests_internal/tree/master/QETemplate/Automated/QE%20Automator.

Node.js-based module installable via NPM

Uses the current titanium CLI version to perform its actions

Takes command-line arguments to select:

URL endpoint for code. If given a TIMOB or TC number, could construct the proper URL automatically

Allows authentication for private tickets

Selection of alloy or classic application

Selection of mobile platform, SDK version, etc. If the selected SDK version is not installed, it should do so for the user

The user would select the proper options, the CLI would download any necessary resources/requirements, create the application, build it, and run it (on device or simulator, as required)

If possible, the reproduction environment should be encoded in such a way in JIRA (or the CLI can parse it) such that it can figure out what versions to download and try automatically.

Example templates:

Note that the title is used as the relative path from the root. For image resources, it would be interesting to see if we could pull from the attachments. Viewing the source of the generated HTML, it would be challenging to pull the code directly from that (it's ended in a bunch of table rows). It may be better to use the JIRA API and grab the source of the description and parse that directly.

Classic

// this sets the background color of the master UIView (when there are no windows/tab groups on it)
Titanium.UI.setBackgroundColor('#000');

// create tab group
var tabGroup = Titanium.UI.createTabGroup();


//
// create base UI tab and root window
//
var win1 = Titanium.UI.createWindow({  
    title:'Tab 1',
    backgroundColor:'#fff'
});
var tab1 = Titanium.UI.createTab({  
    icon:'KS_nav_views.png',
    title:'Tab 1',
    window:win1
});

var label1 = Titanium.UI.createLabel({
	color:'#999',
	text:'I am Window 1',
	font:{fontSize:20,fontFamily:'Helvetica Neue'},
	textAlign:'center',
	width:'auto'
});

win1.add(label1);

//
//  add tabs
//
tabGroup.addTab(tab1);  

// open tab group
tabGroup.open();

Alloy:

var createListDataItems = function() {
	
	var depositList = [{
		faultyLabel:		"Mazda Miata",
		otherViewLabel2:	"$1000.00"
	},{
		faultyLabel:		"Lotus Elise",
		otherViewLabel2:	"$1000.00"
	}];
	
	var items = _.map(depositList, function(element) {
		Ti.API.debug('element.accountName:'  + element.accountName);

		var item = {
		 	 properties : {
		 	 	searchableText: element.accountName,
		 	 	height: 75,
		 	 },
		 	 template: "faultyTemplate",
			 faultyLabel: {text: element.faultyLabel, backgroundColor:"magenta"},
			 otherViewLabel2: {text: element.otherViewLabel2},
		};
		return item;
	});	
	return items;
};
$.section.setItems(createListDataItems());

$.index.open();
<Alloy>
	<Window class="container">
		<ListView id="list">
			<Templates>
				<ItemTemplate name="faultyTemplate">
					<View id="outerView" touchEnabled="false">
					 	<Label id="faultyLabel" bindId="faultyLabel" touchEnabled="false"/>
						<View id="otherView" touchEnabled="false">
							<Label id="otherViewLabel1" touchEnabled="false"/>
							<Label id="otherViewLabel2" bindId="otherViewLabel2" class="rowDetailValue" touchEnabled="false"/>
						</View>
					</View>
				</ItemTemplate>
			</Templates>
			<ListSection id="section"></ListSection>
		</ListView>
	</Window>
</Alloy>
".container": {
	backgroundColor:"white"
},
"#outerView": {
	left: 0,
	right: 0,
	height: Ti.UI.SIZE,
	layout: "vertical"	
}

"#faultyLabel": {
	left: 12,
	text: "dummy text",
	backgroundColor: "yellow",
	right: 12,
	height: 16,
	color: "black",
	font: {
			fontSize: 16,
			fontFamily: "Helvetica",
			fontWeight: "bold"
	}
}

"#otherView": {
	left: 0,
	right: 0,
	height: 20,
}

"#otherViewLabel1": {
	left: 12,
	width: 150,
	text: "Opening Available",
	height: 20,
}

"#otherViewLabel2": {
	right: 0,
	width: 150,
	textAlign: "right",
	height: 20,
}

Comments

  1. Tim Poulsen 2015-01-22

    This is a great idea. * Variation in code sample styles that we get currently -- which means we need to force users to adopt a style, or the triage person to clean up. Are there customization options in Jira such that we could provide a template or entry-wizard? * We get updated code included in comments -- which means it will be the assigned developer's responsibility to update the Description or otherwise flag a specific comment as the relevant sample to use as new samples are added to a ticket. Maybe the triage person would create and attach an app based on the description, which would override the description? * Multiple samples (sometimes we get working &non-working examples) -- how do we tell them apart (which code block goes with which sample), do we use them all or just the first/last? * Attached sample apps -- how do we differentiate between attached apps vs. other types of files (logs, screenshots, etc.) Is there a corresponding app that helps users generate these sample apps? Some sort of "export" tool that would take an app and create the Jira markup necessary to paste into a ticket?
  2. Praveen Innamuri 2015-01-22

    This is a very useful feature. I understand that the assignee of the ticket might need to do bodyshop work of making sure that the code snippets are available (with proper title) in the ticket description or comments or in attachments. I wish there is a separate section for _code snippets_ to manage the sample code from the users, or multiple code-snippets, or different types of files such as logs, screenshots, attached snippets.
  3. Ingo Muschenetz 2015-01-22

    [~skypanther] I find the updated samples in comments to be particularly problematic for QE and dev, since you have to read through everything. I would like to encourage a process whereby you really only need to read the description of the ticket for everything you need to know. The comments just provide additional context. I wonder if a tool like this would encourage people to follow that process.
  4. Praveen Innamuri 2015-01-23

    Also, we can attach the new sample test app back into the JIRA ticket, that is created through the new CLI ?
  5. Tim Statler 2015-01-23

    +1 to these comments: bq. Are there customization options in Jira such that we could provide a template or entry-wizard? bq. I wish there is a separate section for code snippets to manage the sample code from the users I agree there needs to a way to identify runnable sample apps vs. code snippets and the rest (as useful as the rest all may be). A new Jira field would help with that. Perhaps it could take either a single app.js file (Classic), or a collection of index.js/.tss/.xml files (Alloy)? Or, for less work on our part, could we just ask /require developers to attach a complete Ti/Alloy project ZIP as a test case?
  6. Ingo Muschenetz 2015-01-23

    I would prefer that we encourage (if not force) developers to come up with the smallest, simplest complete application that demonstrates the problem. I also find it very useful if the code is directly in the description as it often can be enough for an experienced developer to understand the problem right there. I would worry that having .zip files of the complete application would have a lot of extraneous files that complicate the issue.
  7. Tim Poulsen 2015-01-24

    [~ingo] As a proof of concept, I threw together https://github.com/skypanther/jirasample Something like that could be packaged with the CLI or Studio for "one-button" generation of Jira-ready pasteable code.
  8. Tim Statler 2015-01-27

    [~skypanther], I like the tool. Would it be possible to paste the output to the clipboard? Then it would be a quick command+v into the (presumably) open Jira ticket window.
  9. Tim Poulsen 2015-01-27

    [~tstatler] Great idea. I've updated the tool. By default, output is copied to the clipboard. I haven't yet tested on Windows, though.

JSON Source