I just archieved my first app, but in the version number it get (1) after, even though the version number is changed every time I archieve? Is it the build number? Should I leave that blank?
The 1 in parentheses is the build number
Related
I have an SQL assignment for UNI due in a couple days. I played around with SQL settings using the 'set' command and I have messed up the output of queries (see screenshots, link below).
The output seems to be writing to a fixed line length, instead of using the full length of the terminal console. I am using tmux in iterm v3.2 but also have the same issue on the native MAC OSX terminal.
Is there a way to reset these settings to default? Or somehow make it work for me? I just want the lines to be displayed to the right side of the screen, until it needs to be wrapped.
Let me know if this is a dupe.
Got it!
This is controlled by the pagesize environment variable.
For the screenshot I had pagesize set to 14. Which means print 14 lines, with a blank line for the 14th line, before printing the rest of the output.
I changed the pagesize value to 200, this should be enough for what I need.
set pagesize n
help set
Working with Gated/CI build definition (vNext) in TFS2017, the revision number is not increased correctly. Each build has the same Rev number even the changes are checked-in properly.
I get the revision number from $Env:BUILD_BUILDNUMBER via powershell at the beginning of the build process and it always returns the same number.
Make sure you are using the $(Rev:.r) token in the Build number format setting.
Build number format:
Use $(Rev:.r) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
If you want to show prefix zeros in the number, you can add additional
'r' characters. For example, specify $(rev:.rr) if you want the Rev
number to begin with 01, 02, and so on.
Also make sure the build number was not updated with the permanent number or string. (There is a possibility that used a script to customize your build process that updated the build number)
UPDATE1:
Please note that if the Major build number is changed in Build number format, then the revision number will not be changed. The Revision number only incremented when the Major part is not changed.
BTW, the token $(rev:.rr) should be used such as a variable, so the build number format should be something like : Test DEV CI_Rev.$(rev:.rr) in your scenario.
UPDATE2:
In your scenario you updated the build number with the assembly info every time. So, if the assembly info is different every time, then the revision number will no be changed, that's the expected behavior.
Curious to know what's the maximum number a Jenkins build number (BUILD_NUMBER) can get? I tried to find online but couldn't find this info.
Is it infinite or has some limit (being INT or INT64 or some other type)?
PS:
I'm NOT looking for how to reset it back to #1 or #N using the following plugin or set it value to a given name (using Set build name plugin).
https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin
To find it's limit, using Next Build Number plugin - when I set the build to "65,535", it still worked in getting me 65536 successfully and I kept increasing this value to 999999999 (9 times), and it still worked i.e. the next build ran which was 1000000000 and reaped a valid Jenkins build# for few other runs/builds.
When I tried to set the next build number as: 9999999999 (10 times), Jenkins plugin barfed with an error mesg (which shows the next build number I set was not an INTEGER i.e. not in the range):
A problem occurred while processing the request. Please check our bug tracker to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. The users list might be also useful in understanding what has happened.
Stack trace
javax.servlet.ServletException: Build number must be an integer
at org.jvnet.hudson.plugins.nextbuildnumber.NextBuildNumberAction.doSubmit(NextBuildNumberAction.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Found Jenkins BUILD_NUMBER is a SIGNED Integer data type and INT signed limits are:
int 2 or 4 bytes -32,768 to 32,767 or -2,147,483,648 to 2,147,483,647
Thus, the last value that a Jenkins job can be set or built is: 2147483647 (4 bytes here). Setting anything above this number will generate the expected INT limit error.
Noticed the following issue as well, with SET NEXT BUILD NUMBER plugin:
If I set the next build number between -2147483648 or 2147483647 (positive), this plugin it works in both cases i.e. giving Negative or a positive Number and setting it doesn't error out. BUT, if you have already reached at build# 2147483647 (under Job history), then even setting the build# to 1 did NOT generate the next build as 1 or 2 . or 3 and so on.
As the BUILD_NUMBER is SIGNED (-N to +N in the above range) and for ex: setting -22 works for setting the next build# using the plugin, it didn't give me build# -21 or build# 21 in my case.
What's happening is, while providing a negative/lower value than the last/previous build# then this plugin is taking that value within the limit BUT not actually doing anything / giving me the expected BUILD#. When I'm clicking on Build Now / every time you hit Build Now and if you click on "Set Next Build Number" to check the value, I noticed that the number listed in the box was auto-decrementing by the number of times I hit "Build Now" (this happens only when you have reached the limit) and negative/lower value has no effect for the next build number (as per the plugin docs).
I tested this by creating a new test_job (discarded old builds by retaining only 1 build):
clicked on Build Now, got Build# 1.
Set next build number to 100.
Clicked Build Now, got Build# 100, Clicked Build now, Got build# 101.
Set Build number to 11 this time.
Clicked Build Now, but instead of giving me build# 12, Jenkins gave me build# 102 (PS: that's the intended behavior by this plugin as per it's documentation as setting next build number to a lower number N will not do anything).
CXCallDirectoryPhoneNumber not support 0 at beginning
eg.
Add 0 in front of the number becomes 8-binary number,
But my phone number has 0 in front of it.
If my phone number is 010-12345678,
8612345678 is not matched,
8601012345678 is not matched,
01012345678 is not matched.
Some tips for someone who might still struggle on this... In short, if you number is 010-12345678, then 8612345678 should be the choice. Formats like "+8612345678" as a string worked for me too.
Just ran into the similar issue, and found out the reason why Call Directory extension sometimes "does not work" is simply not because of your phone number format. iOS will actually cache your phone numbers which are set when the extension is ran previously, i.e. it will not update your blocking or the identification phone numbers each time you change your source code and restart you app extension as you expected.
One way to invalidate the iOS cache is to toggle your app's option in Settings -> Phone -> Call Blocking & Identification (and maybe restart your app as well).
Per documentation, deleting is supported only if where clause has time. That works fine. But, if I want to narrow down by time and another clause, it errors out..is that supported yet?
ie. delete from datapoints where time>now()-1h and code='12345'
The relevant documentation: http://influxdb.com/docs/v0.8/api/query_language.html#deleting-data-or-dropping-series
The DELETE syntax for individual points is only valid in 0.8 and prior versions. All development is on the 0.9 version and no work is being done to fix any 0.8 issues. Therefore the current functionality of DELETE FROM is final for all 0.8.x versions.