Automated builds, buildbot, AtmelStudio7, LinkId=659046 error

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to do unattended automated Buildbot builds using AtmelStudio on a Windows 10 Pro, 64bit.

Buildbot is running as a service as the user "master".

"master" has account type "Administrator"

 

When I am remote desktop'd into the Buildbot machine as "Administrator", everything is great, builds are successful.

(Note this is a *different* user from the one running Buildbot!)

 

When I am NOT remote desktop'd into the machine, AtmelStudio fails with:

AtmelStudio has detected a configuration issue. To correct this, please restart as Administrator. For more information please visit: http://go.microsoft.com/fwlink/?...

 

I have tried the instructions there to re-register DLLs.

I have tried "master" as both a normal and an Administrator account.

I have tried copying ALL environment variables from a regular cmd shell into buildbot's shell.

I have googled to no end.

 

I am running out of things to try.

 

 

Has anyone else seen this behavior?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you talking about C/C++ builds? At the end of the day they are GNU Make builds so why does AS7 have to be involved at all? Once it has created the Makefile you can just invoke make to execute it with no further involvement from AS7

 

Personally I'd just set up a Hudson/Jenkins or something in a VM build machine. Might not even use Windows but the Linux builds of the GCC tools.

Last Edited: Tue. Aug 15, 2017 - 04:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to be able to build from scratch, unattended.

The makefiles are generated by AtmelStudio, yes?  How can I generate them if I can't run Atmel Studio?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

In order to set up (or modify) the project at all you're doing that using Atmel Studio interactively, yes? And you do a test-build at that stage, yes?

 

That's when you "nick" the makefile. 

 

I.e. once for every project setup or modification. (Not for every time you run your automated builds.)

 

EDIT: The "nicking" of the makefile might even be done by a post-build step? (Not at a Atmel Studio machine right now so can't test this.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Tue. Aug 15, 2017 - 06:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awozniak wrote:
I have to be able to build from scratch, unattended. The makefiles are generated by AtmelStudio, yes? How can I generate them if I can't run Atmel Studio?

I really see two questions here.

 

The second part, running Studio fails -- I can't really help with that. 

 

Now tell more about the first part -- "build from scratch, unattended".  I'm trying to envision scenarios where "unattended build" is important.  As [generally] a programming team of one for the last decade or two, I guess if it is a team project with sources and related in a repository, then it would be nice to do a build upon command.

 

Another scenario might be where serial number or IP address or license code or similar is "buried" into each unit, so a clean build is desired before programming into the unit.

 

In the above scenarios, I wouldn't expect the build procedure to vary, unless the project was re-configured for some reason.  Adding a source file; a change in compile or link flags; or similar.  If indeed using the project facilities within Studio, then one "attended" build creates the makefile which can then be used for subsequent "unattended" builds.  I'd think I'd want to run the new configuration at least once and check for proper results.  The makefile is still there in the project directory, isn't it?  It is in my Studio7 apps.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Currently, the Makefile is autogenerated from the .atsln by AtmelStudio.

It's a build artifact, not a primary source.

Suggesting I use it is like suggesting I put the *.o files under revision control and use those.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Builds are automated.

They are done automatically when anything is pushed to our source code repository.

Developers get emails if things break.

 

This is all very normal for a production environment.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awozniak wrote:

Currently, the Makefile is autogenerated from the .atsln by AtmelStudio.

It's a build artifact, not a primary source.

Suggesting I use it is like suggesting I put the *.o files under revision control and use those.

Yup, but that might be the best we can come up with. I did a few tests yesterday evening, trying to run Studio builds in "batch mode". All attempts ended up with Studio either crashing or reporting the solution file could not be found (despite the path given being correct). I have a feeling that running Atmel Studio has never been tested (or even intended to be) runing in "batch mode". 

 

The help seems to be the generic help for Visual Studio Integrated Shell, not adoped to the specific Atmel Studio implementation. Might be an indication on Atmel Studio not implementing batch runs. 

 

If Studio cant run batched, and you can't live with the generated makefile then a hand made makefile seems to be the only alternative left, and that's not better. You then have to maintain both Studio projects and makefiles.. 

 

For a definitive answer on Studios abilities, contact Atmel/Microchip support! 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

awozniak wrote:

Currently, the Makefile is autogenerated from the .atsln by AtmelStudio.

It's a build artifact, not a primary source.

Suggesting I use it is like suggesting I put the *.o files under revision control and use those.

Yup, but that might be the best we can come up with. I did a few tests yesterday evening, trying to run Studio builds in "batch mode". All attempts ended up with Studio either crashing or reporting the solution file could not be found (despite the path given being correct). I have a feeling that running Atmel Studio has never been tested (or even intended to be) runing in "batch mode". 

 

The help seems to be the generic help for Visual Studio Integrated Shell, not adoped to the specific Atmel Studio implementation. Might be an indication on Atmel Studio not implementing batch runs. 

 

If Studio cant run batched, and you can't live with the generated makefile then a hand made makefile seems to be the only alternative left, and that's not better. You then have to maintain both Studio projects and makefiles.. 

 

For a definitive answer on Studios abilities, contact Atmel/Microchip support! 

 

Hello JohanEkdahl

were you able to find a solution?

I also cannot execute Atmel Studio command line builds on either Windows Server 2016 and 2019, always ending up with same error message as you (except when a remote session is opened on the machine)...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I don't understand your requirement. If you develop in AS7 then each time you build manually through the UI then all it really does is create a "Makefile" in either the Debug or release directory and then "make -f name_of_Makefile"to do the building. So what then stops you just doing "make -f name_of_Makefile" yourself if you want to do a command line build?

D:\test\test\Debug>make -f Makefile clean all
rm -rf  main.o
rm -rf  main.d
rm -rf "test.elf" "test.a" "test.hex" "test.lss" "test.eep" "test.map" "test.srec" "test.usersignatures"
Building file: .././main.c
Invoking: AVR8/GNU C Compiler : 5.4.0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\include"  -Os -fpack-struct -fshort-enums -mrelax -g2 -Wall -pedantic -mmcu=atmega8 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\gcc\dev\atmega8" -c -std=gnu99 -H -fverbose-asm -save-temps -MD -MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" ".././main.c"
. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\io.h
.. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\sfr_defs.h
... c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\inttypes.h
.... c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\lib\gcc\avr\5.4.0\include\stdint.h
..... c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\stdint.h
.. C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\include/avr/iom8.h
.. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\portpins.h
.. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\common.h
.. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\version.h
.. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\fuse.h
.. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\lock.h
Finished building: .././main.c
Building target: test.elf
Invoking: AVR8/GNU Linker : 5.4.0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-g++.exe" -o test.elf  main.o   -Wl,-Map="test.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mrelax -mmcu=atmega8 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\gcc\dev\atmega8" -Wl,-print-gc-sections -Wl,-section-start=.fram=0x10000000
Finished building target: test.elf
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "test.elf" "test.hex"
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "test.elf" "test.eep" || exit 0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "test.elf" > "test.lss"
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "test.elf" "test.srec"
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "test.elf"
   text    data     bss     dec     hex filename
     70       0       0      70      46 test.elf

Of course you can also just do:

D:\test>atmelstudio test.atsln /out output.txt /clean debug

D:\test>dir test\Debug
 Volume in drive D is DATA
 Volume Serial Number is 1CF4-86D6

 Directory of D:\test\test\Debug

31/10/2019  10:28    <DIR>          .
31/10/2019  10:28    <DIR>          ..
23/07/2019  08:20           107,801 debug.txt
31/10/2019  10:13             6,343 main.i
22/10/2019  15:40            89,577 main.ii
31/10/2019  10:13             7,224 main.s
17/10/2019  08:54             4,242 main.source.s
22/10/2019  15:41               240 makedep.mk
31/10/2019  10:28             3,876 Makefile
13/11/2018  13:24             6,076 SNSBootloader.bin
05/09/2019  14:15               168 test.bin
               9 File(s)        225,547 bytes

D:\test>atmelstudio test.atsln /out output.txt /build debug

D:\test>dir test\Debug
 Volume in drive D is DATA
 Volume Serial Number is 1CF4-86D6

 Directory of D:\test\test\Debug

31/10/2019  10:28    <DIR>          .
31/10/2019  10:28    <DIR>          ..
23/07/2019  08:20           107,801 debug.txt
31/10/2019  10:28             2,322 main.d
31/10/2019  10:28             6,343 main.i
22/10/2019  15:40            89,577 main.ii
31/10/2019  10:28             2,632 main.o
31/10/2019  10:28             7,224 main.s
17/10/2019  08:54             4,242 main.source.s
22/10/2019  15:41               240 makedep.mk
31/10/2019  10:28             3,876 Makefile
13/11/2018  13:24             6,076 SNSBootloader.bin
05/09/2019  14:15               168 test.bin
31/10/2019  10:28                13 test.eep
31/10/2019  10:28             6,500 test.elf
31/10/2019  10:28               218 test.hex
31/10/2019  10:28             3,381 test.lss
31/10/2019  10:28            14,480 test.map
31/10/2019  10:28               242 test.srec
              17 File(s)        255,335 bytes

D:\test>type output.txt
------ Clean started: Project: test, Configuration: Debug AVR ------
                Shell Utils Path C:\program files (x86)\atmel\studio\7.0\shellUtils
                C:\program files (x86)\atmel\studio\7.0\shellUtils\make.exe clean
========== Clean: 1 succeeded, 0 failed, 0 skipped ==========

------ Build started: Project: test, Configuration: Debug AVR ------
                Shell Utils Path C:\program files (x86)\atmel\studio\7.0\shellUtils
                C:\program files (x86)\atmel\studio\7.0\shellUtils\make.exe all --jobs 8 --output-sync
                . c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\io.h
                .. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\sfr_defs.h
                ... c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\inttypes.h
                .... c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\lib\gcc\avr\5.4.0\include\stdint.h
                ..... c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\stdint.h
                .. C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.3.300\include/avr/iom8.h
                .. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\portpins.h
                .. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\common.h
                .. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\version.h
                .. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\fuse.h
                .. c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\lock.h
                                Program Memory Usage    :       70 bytes   0.9 % Full
                                Data Memory Usage               :       0 bytes   0.0 % Full
                                Warning: Memory Usage estimation may not be accurate if there are sections other than .text sections in ELF file
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

So after clean there were 9 files in the output directory and after build there were then 17.

 

While it seems you can use /out to direct the build activity to a text file that is the only evidence you get of anything happening - it does not seem able to direct the build output to the console to see it happening. That's even true if there's a build error. created a deliberate error then tried to build but nothing is shown at the console that anything is wrong and yet the output.txt contains:

 

D:\test\test\main.c(3,2): error: #error "deliberate error"
                 #error "deliberate error"
                  ^
                make: *** [main.o] Error 1
D:\test\test\Debug\Makefile(76,1): error: recipe for target 'main.o' failed
Done building project "test.cproj" -- FAILED.

Build FAILED.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello

 

requirement is the following, from a Windows VM:

git clone <repo_url>

"%ATMEL_INSTALLATION_PATH%\AtmelStudio.exe" myproj.cproj /rebuild release /out build_output.txt

 

Similar to your second proposal, except here AtmelStudio is crashing when doing builds through Jenkins (jenkins is a java process running as a service with a dedicated Active Directory account) with following error message in build_output.txt:

AtmelStudio has detected a configuration issue. To correct this, please restart as Administrator. For more information please visit: http://go.microsoft.com/fwlink/?...

 

  1. Above atmelstudio command line build is crashing when used in Jenkins context, without any opened Remote Desktop session on the VM
  2. Above atmelstudio command line build is working fine, also in Jenkins context, when i have sideway a Remote Desktop session opened on the VM!

 

I will reach microChip support to get some insights, it seems tighly linked to Visual 2015 Shell dependency...

Last Edited: Thu. Oct 31, 2019 - 12:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Worked for me at a "normal" Windows command prompt though it's true I started that with Tools-Command Prompt in AS7 itself simply because that ensures all the right PATH entries are made.

 

Sounds to me from your error like the atmelstudio.exe is not being run in quite the right environment. 

 

What you could do is start a Command Prompt form AS7. Verify that it does build there OK. Then look at "set" output and see how that environment differs from that in the Jenkins container.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Worked for me at a "normal" Windows command prompt though it's true I started that with Tools-Command Prompt in AS7 itself simply because that ensures all the right PATH entries are made.

Sounds to me from your error like the atmelstudio.exe is not being run in quite the right environment. 

What you could do is start a Command Prompt form AS7. Verify that it does build there OK. Then look at "set" output and see how that environment differs from that in the Jenkins container.

 

Thanks i will give it a try.

But from my numerous testings, it always works from command line within a "normal" user session.

It just won't work when triggered from a Windows Service (and only when no user session is opened) frown

 

Interesting thing is that results are also not the same depending on the Windows version:

  • Windows Server 2012 R2 6.3 --> OK
  • Windows Server 2016 1607 --> KO
  • Windows Server 2019 1809 --> KO
  • Windows 10 Pro 1803 --> KO

 

When searching on Google, there are recurrent results related to Visual 2015 dependency (https://stackoverflow.com/questions/41870361/visual-studio-sometimes-detects-configuration-issue-on-jenkins-ci-server)

Last Edited: Thu. Oct 31, 2019 - 02:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not that it proves very much but in my day job we are running msbuild a lot in Jenkins sessions with no apparent issues. This is kind of the same. So sometimes it works OK!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We run Studio in Jenkins also, but seems like we're only using Server 2012R2 for this...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
We run Studio in Jenkins also, but seems like we're only using Server 2012R2 for this...

 

Lucky you!

 

I think msbuild is a real build system, way more suitable for automation and much more reliable.

 

By comparison, when building using atmelstudio.exe executable, it is similar as building using Visual Studio devenv.exe, and it has proven to be less efficient/stable for automation purpose.

 

 

Just for information, it is possible to use CMake and the Atmel Gnu Arm toolchain, it works fine.

But project i'm currently targeting want (for now) to stick with AtmelStudio command line builds...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Totally lost here. What is an "automated build"? Why would anybody need such a thing?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Automated regression testing is one of the best practices.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's standard practice on BIG projects (with BIG teams), where  a complete build can take a significant time - so not practical for each developer to be doing individually.

 

And, as  gchapman says, this can be combined with automated checking, testing, etc, ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

https://en.wikipedia.org/wiki/Continuous_integration#Automate_the_build

 

sorry for double post, cannot delete this one...

Last Edited: Thu. Oct 31, 2019 - 06:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Totally lost here. What is an "automated build"? Why would anybody need such a thing?

 

Jim

 

https://en.wikipedia.org/wiki/Continuous_integration#Automate_the_build

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would be interesting to hear your particular use case in the context of AVR and Atmel Studio ?

 

As the Wikipedia article says,

Continuous Integration is not necessarily valuable if the scope of the project is small 

which is generally the case for small microcontrollers - like AVR ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In a nutshell, several of our projects are built against many toolchains to address business requests (Atmel, IAR, Gnu ARM, Green Hills, ...)

 

A developer will not install all those toolchains on its machine, usually only the project preferred one.

 

When he starts developing its feature on a "feature branch", he will open a Github Pull Request, which will trigger for each commit a Jenkins Build of *all* the project targets.

This allows to detect issues/regressions fast without the burden to rebuild all project variant on developer side, while avoiding to break "master/product" branches.

 

I think it is quite common setup, and we are perfectly fine using Atmel Gnu ARM toolchain with CMake.

 

But this specific project is for now reluctant to move to CMake, and discussed issue just pop-up lately when i put in place a new Windows Server 2016 build machine...

 

Edit: from my experience, the ROI with CI is huge on any project type, and having a golden reference build environment will always help to troubleshoot the "but it builds fine on my machine" situation:D

 

Second Edit: just noticed this topic was into AVR part of the forum. We use Atmel Studio for ARM targets. But i think it is more of a tool issue.

Last Edited: Thu. Oct 31, 2019 - 06:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

asimov81 wrote:
I think it is quite common setup

Not really in AVR projects.

 

just noticed this topic was into AVR part of the forum

Indeed - hence the audience not really familiar with such things.

 

 We use Atmel Studio for ARM targets.

Yes, it would be far more common there - though probably still not much cor Cortex-M4 and smaller ?

 

But i think it is more of a tool issue.

The problem is a problem with the tool.

 

The reason the problem isn't widely seen is, as Johan suggested, probably because the intended audience of this tool is not generally going to be using it in this way.

 

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks awneil for those comments.

Would you recommend that i "moove" this discussion into the Atmel Studio ARM part of the forum?

Anyway, i have opened a case with microchip support, i hope they will be able to help. And if it is the case, i'll provide feedback here

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think only a Moderator can move things?

 

Maybe just post a brief note over there, and invite people to contribute here?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Totally lost here. What is an "automated build"? Why would anybody need such a thing?

I work in an Agile environment and Constant Integration (CI) is the very core of what we do.

 

On any project there may be anything from about 20 to 500 engineers all working on bits of a common code tree. While everything is modular, so work tends to be isolated to small areas, some changes are universal and a single file changed at the core could affect (ie break things) for everyone. Even a typing error that crashes the build could be disastrous. Imagine 499 engineers sitting, twiddling their thumbs while one persons screw up is found and fixed.

 

What's more, "agile" means pushing small incremental changes every few days (typical scrum periods are 2 weeks so never longer than that). So in a busy period there could be 400+ individual pieces if work pushed onto the tree in any day. Any of those has the potential to screw everything for everyone. So every time a change set is pushed into Gerrit it triggers one a large number of parallel machines (actually virtual machines in the cloud) to pull the code tree and maybe make about 20 to 50 builds that represent all the build combinations. If anyone of those has even a single build error then Gerrit rejects the change set and it can't be merged to master (also every change set has  to reviewed by at least one other engineer to verify it makes sense as far as a fellow human being is concerned ).

 

As well as just building the code, every function in every file in every module must also have unit tests that run each function with test data and verify the output is as expected. Jenkins also builds then runs all the unit tests and verifies results so if any change, anywhere in the code changes the behaviour of the code then the change is rejected as well.

 

Finally some builds also run "smoke tests" where more than individual functions but entire modules and systems are run/simulated and correct operation is checked. Again, if any of that fails the change is rejected. This is all protection to ensure that no idiot making a mistake in what they are doing can bring the entire thing crashing down. If 499 engineers sit idle it could cost about $50,000 per hour.

 

What none of this caters for is when the CI system itself fails so that Gerrit or Jenkins or the static code analyzers (yeah, that too!) or the virtual web services or the IT network fail then you have a whole load of very bored engineers on your hands. (At least there is Freaks for this!)

 

You may think a small AVR project has no relevance to this but say even just 3 of the 500 engineers are working on an AVR within the project and the main device stops working even if the AVR fails to do what's expected then really all 500 are as dependent on that as anything else so the AVR code would be checked in Jenkins too.

 

Of course the closer to the hardware you get the more difficult the mocking in unit and simulated system tests becomes.

Last Edited: Fri. Nov 1, 2019 - 09:27 AM